Paul Stear <[email protected]> posted [email protected], excerpted below, on Mon, 09 Mar 2009 09:12:49 +0000:
> Thanks for the replies, sorry I haven't been back in touch for a few > days. If I click Properties and select the Permissions tab the User is > -me(my user name), Group is root. On the access Permissions part the > Owner is set to "Can View Contents". > If I change this to "Can View & Modify Content" and click "OK" I get an > error message "Could not change permissions for /media/lomega HDD". I am > on kde3.10. > Their must be a way of defining default permissions for anything plugged > into the usb port. There is, but the old way, manual mounting and fstab configuration, while well documented doesn't always play well with hal and automounting, and the newer hal based automounting isn't as well documented -- or at least isn't as well understood by us old *ix types who tend to be a bit suspicious of automounting in the first place. Note that it's also possible to use udev to arrange custom device creation based on what's inserted. This at least has a reasonable level of documentation associated with it, and can be used to, for instance, always give your MP3 player or camera a stable device file regardless of whether other thumb drives and etc are inserted before it (thus changing the default device name) or not. Hal or fstab could then use that in their config to allow different mounting options (or indeed whether to mount by default or not) for different thumb drives and/or other USB mass storage devices. Here, I use a Label= entry in my fstab to determine how my mp3 player is loaded. Of course, it's vfat not ntfs, but the same idea should be usable with ntfs, I think (each of the below is all one line in fstab, two here for posting, uxx and gxx are of course numeric substitutions): ## Dev/Part/LBL MntPnt Type MntOpt D F LABEL=Siren /m/siren vfat user,sync,uid=uxx,gid=gxx,noatime,nonumtail,noauto 0 0 As for hal... Naturally I have fstab entries for my dvd-writers as well. They work decently in most cases, but there was a hal related bug triggered by k3b at one point. After writing the image, k3b would eject and re-suck (heh, what else would it be called, it's not re-insert since it's pulling it in, not me pushing) the tray with the burned disk on it, then verify the image. Except that when it re-sucked the tray, hal interfered, trying to automount in /media as it was now a burned image, and k3b couldn't access the disk in ordered to verify the image. Various patches worked for some folks but broke it for others, until someone mentioned turning OFF the k3b option to eject after burning that /used/ to be necessary. That seemed to work. The point is, during all this I discovered that despite the fstab mount entry to mount in /mnt/dvd, hal was ignoring fstab and doing its own thing, trying to mount on /media/dvdname or some such. Thus the bit above about hal and its automount sometimes conflicting with the traditional fstab config. If you end up with a similar hal/fstab and possibly udev involving conflict, one thing you can do is simply tell the popup to do nothing, and then issue the mount option manually (and of course you can create a menu option to invoke a script to do that as appropriate). By issuing the mount option manually (or setting up an invokable script to do it for you), you can set your options to mount it the way you want, either on the mount commandline or in fstab. Surely there's a way to configure hal to do the same thing, but I don't know it, and am old school enough to be a bit suspicious of its automounting anyway, especially when it ignores the clearly established policy in fstab(!!), so I've not bothered looking more deeply into it. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
