Gnomad Permission Problem

I have an old Creative Nomad Jukebox Zen Xtra, and I installed Gnomad2. When I plug the usb cord in the Zen lights up.

Using the Gnomad2 rescan menu, I get the error message Usb_open: Permission denied.

How can I correct this?

Well since nobody else has stepped up yet. Chances are good that you don’t have write permissions on the usb device file. Try running the program as root. If it works then you need to fix your user access to the resource. The device file is going to be in the /dev directory and be something like /dev/usb?? Not sure here. If you can pin point it then check the permissions on it "ls -l /dev/usb* or whatever the device file is check to see who the owner and group ownership belongs to. You want to be either the owner or a group member of that file, or change the ownership with "chown <user>:<group> <filename> " or “chmod 660 <filename>” while as root. This is kind of a blunt instrument method but the simplest - and possibly the most dangerous from a security standpoint. Another way to attack it is with setuid root or appropriate user to the program you are running so that if you have permission to run the program you have carte blanch to the resources it needs. This is general info and you’ll need to read up in the man pages and make sure you understand what you are doing. I’m new to the current Linux world but not to Unix’s in general. I leave it to others here for more detailed information.


I logged in as root, and the device works with Gnomad as it is supposed to work.

Yesterday I had seen an older thread on the forum about fixing this for Suse 11.1. I have 11.3.

Following the instructions in the older thread, I went to lib>udev>rules.d>50-udev-default.rules, while still logged in as root.

I scrolled down to the section # libusb device nodes

There was only one line in that section. I changed the Mode=“0664” to Mode=“0666”

I saved the file, and checked to see if the device still worked with Gnomad, and it did. I logged out as root, and logged in as myself, and it still worked. Looks like this problem is solved.

Well, this is what I mean about not being up to date. Same issues but different management. This is exactly the kind of thing I’m trying to get up to speed on myself. I know the mechanisms but the layers of control are getting deeper. Thanks for the info :slight_smile:


tjwells wrote:
> I logged in as root, and . . .

do not, do not, do not log into KDE/Gnome/etc as root…instead, see to learn how to always log
into KDE/Gnome/etc as yourself and “become root” in that session to do
whatever administrative tasks you need to perform…

for example: in this case you could have (while logged in as yourself,
launched Kwrite with root powers and edited the same rules, this way:

  • hold down left Alt and press F2
  • in the popup type

kdesu kwrite /lib/udev/rules.d/50-udev-default.rules

  • type in root pass when asked
  • scroll down to <etc>

more (from an older post of mine): you should never log into
KDE/Gnome/XFCE or any other *nix-like graphical user interface desktop
environment as root…

doing so 1) opens you up to several different security problems, 2)
too many too easy ways to damage your system no matter how careful
your actions (example: just browsing in your home directory while
logged into KDE/Gnome/etc as root can lock you out later as yourself
due to permissions damage), 3) and, anyway logging into KDE/etc as
root is never required to do any and all administrative duties…

so, always log in as yourself, and “become root” by using a root
powered application (like YaST, File Manager Superuser Mode) or using
“su -”, sudo, kdesu, or gnomesu in a terminal to launch whatever tool
is needed (like Kwrite to edit a config file)…read more on all that

CAVEAT: [posted via NNTP w/openSUSE 10.3]

What if there were no hypothetical questions?

I’ve never tried to log into a graphical environment as root (no need) but can’t imagine not doing so for administrative command line activities. Sure you can use sudo for every command but what a pain. If you understand the consequences of your actions while root then you CAN do it safely. It just requires an understanding of the permissions structures. I’ve been administering HPUX for years without a problem and sometimes it’s a quick way to find out if you’ve got permission or path issues or something else going on. Linux is different - a bit - but the underlying principals are the same.


greyangel wrote:
> I’ve never tried to log into a graphical environment as root

but, i’d bet tjwells did…you told him to “Try running the
program as root.” and in his lack of experience and understanding did
as told him the only way he knew how…

it is real important when helping here to realize that many of the
folks have a few years windows experience (with no CLI knowledge at
all) and some few hours of Linux experience…and, to them “run as
root” means (like it did in Win) log out, and log back in a
Administrator…but we call it root…


CAVEAT: [posted via NNTP w/openSUSE 10.3]

What if there were no hypothetical questions?