[gentoo-amd64] Re: Mount iomegs 1tb external HD

[Duncan]

Paul Stear <gentoo@××××××××××××.com> posted
200903090912.51323.gentoo@××××××××××××.com, 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