I recently bought a Seagate FreeAgent Go 500GB external USB drive. It comes formatted in NTFS, and worked fine on my desktop running Slackware 12.1/KDE3.5. I think I caused a problem with the NTFS on the drive when I connected it to an older laptop running a 2.6.21 kernel. These drives have some firmware quirks that make them go into a sleep mode on kernels before about 2.6.24 I think. The next time I connected the drive to my desktop it wouldn't mount due to a corruption of NTFS. I had to reboot into Windows XP to run chkdsk on it to fix it. That worked, but I really don't want to rely on Windows to keep a backup medium reliable.

After all that I decided I'd rather just have a Linux filesystem on it so I repartitioned it with cfdisk and made an ext3 fs with mke2fs -j. That's when I discovered a lot of unexpected behavior with ext3-formatted removable media. There's questions all over the web about permissions and mount points, and a lot of workarounds. The short version is that vfat and ntfs usb drives tend to do this (assuming HAL/DBUS/udev/KDE, user in plugdev group):

1) A mountpoint is created in /media with the label of the drive. I have Corsair USB flash drives that mount to /media/CORSAIR1, for instance.
2) The drive is mounted <user>.root (i.e. owner is current user) and no r/w permission problems.

Ext3 formatted drives tend to do this:

1) The drive is mounted to /media/disk.
2) Owner is root.root, and if it was connected by a non-root user, no write permissions are given.

Using some of the workarounds I found digging in various distributions forums, I've done the following:

Create a label 'freeagent' for the drive:
I right-clicked on the KDE desktop icon for the drive and went to the Mounting tab. I gave it a mountpoint of /media/freeagent. The following lines were added to ~/.kde/share/config/mediamanagerrc:
I then right-clicked the icon and selected 'Mount'. As root, I did:
The ownership of the mountpoint by my non-root user is retained after unmounting and remounting, and after reboots. However, I get a mount error (similar to the first error shown here ) in a KDE dialog the first time I try to mount it after a reboot. Retrying the mount always works the second time. Once it's mounted, the drive's contents are fully accessible by my non-root user.

Okay, so I've got a workaround that feels hackish and wrong. What I really want to know (and what is not answered in all the web traffic about this issue) is what sets this behavior in the first place. From what I understand, it's caused by a combination of udev rules and HAL policies, but what I've found on my system doesn't seem to fully explain it. If anyone knows how to modify these defaults, I'm curious to know.

In /etc/udev/rules.d/60-persistent-storage.rules:
These lines seem to be responsible for creating the /dev/disk nodes for removable usb-storage media. Nothing there seems to be a problem - my ext3 formatted drive shows up under the /dev/disk/by-* tree with the proper ids, labels and UUIDs, etc.

The most interesting thing I've found is in /usr/share/hal/fdi/policy/10osvendor/20-storage-methods.fdi:

This was the only reference I could find in the udev rules and HAL policies that sets up different behavior for ext3 vs. ntfs formatted drives. I don't understand how these options create the behavior I described above though, or how (or if it's even wise) to modify the HAL policies to just make an ext3-formatted drive act like the vfat and ntfs drives we're all used to.

The purpose of this post was to document what I've found so far on using ext3 with USB drives. If my workaround helps, so be it. However, I'm hoping to start some discussion on what's really going on behind the curtain and if it would work better to have similar behavior for USB drives no matter what the filesystem is. I can understand why a Linux filesystem that understands file permissions would behave differently than ntfs or vfat, but on a USB drive I don't think most people really want to worry about that.

References:
http://www.linuxquestions.org/questi...-drive-771517/
http://www.linuxquestions.org/questi...32ntfs-767717/

Personally, I just: 1.) create/partition the usb drive as jfs, but should be same for ext3. 2.) as root make a directory in the new drive called "user-writable" and chown it to uid 1000 and gid 100 , which is typically the first 'user' created on a box. or just pick some uid:gid pair that you want. 3.) make that dir writable by group 100 (optional if you dont want it) and voila. You see your users cannot write in the '/' of media/disk (if your USB was named disk automagically by hal) But if you put a folder there for them to write to, well they can go all hog wild in that 'user-writeable' folder It's quick, and no messing with udev.

always works for me. Of course I change the uid according to the user uid.

Thanks for the suggestions guys, although those are still what I'd consider workarounds. I would like to know the mechanism that sets the mounting behavior automatically rather than have to play with permissions after it's mounted.

Old_Fogie, your suggestion does bring up something I hadn't considered. Using an ext3 filesystem makes the drive act more like an expansion disk of the system's root filesystem rather than a removable Windows drive. It's like adding a separate internal hard drive, formatted to ext3 and mounted at /home. You wouldn't want the entire drive (or /home directory) to be r/w by every user - each one gets a /home/user directory with their own permissions. I'm thinking of the USB drive more as a "foreign" filesystem, but using ext3 just makes it an extension of the rest of the native system with all the usual permission rules.

I may try undoing some of the workarounds I tried and see if I can get rid of that annoying initial mount error. I hadn't wanted to try setting individual directory permissions in case the UIDs of my main user aren't the same among my two or three Linux boxes. I've had that problem with Samba shares before.

Spelled, yes exactly. It's just extending the usual perms for users on the external drive. If I made a folder for each user, then it'd be just like the 'home' in linux.

but if you really want to address it thru udev, then look at what rworkman wrote up at slackwiki:

http://slackwiki.org/Udev

Sorry guys for butting in again, but I need to correct my previous post otherwise I won't sleep.

Actually for some reason,

does NOT always work. Yet most of the time this does work for ext3 and so on:

I don't think it's udev that's setting the behavior. My understanding of udev rules is that they are used to create consistent user-defined /dev nodes. That doesn't seem to be the problem. The device is mounting to /dev/sd* like my other USB storage devices do, and just like it did when it was ntfs.

I think the behavior I'm seeing is a combination of HAL and the auto-mount handling of KDE. It's not the /dev node that's different, it's the creation of the mountpoint in /media that is. I had to force KDE to make /media/freeagent, where HAL+KDE seem to do that automagically for vfat and ntfs formatted drives.

The basic question is what makes an ext3 drive mount to /media/disk and not to /media/<fslabel>?

Unix filesystems (ext*, jfs, xfs, ...) don't (and shouldn't) get their ownership and permissions changed simply by mounting them. If you want the ownership/permissions to be different, then you change them, and the changes persist across unplug/replugs, of course.

1 members found this post helpful.

I found a few other discussions about HAL policies since my last post. Robby, what you just said is essentially why the uid=, gid=, and umask= options are included for ntfs, but not for ext3. To answer one of my original questions, it would not be wise just to add those options into the ext3 section of the hal policies file.

My error was thinking that the behavior of any removable USB drive should be consistent regardless of filesystem. Putting a linux filesystem on a USB drive creates additional considerations that vfat/ntfs don't have because they don't recognize permissions.

Out of curiosity, where are the ownership and permissions for the mountpoint stored? On the desktop, or in the filesystem of the removable USB drive?

I'm also still wondering why HAL/KDE mount an ext3 drive to /media/disk instead of /media/<label> by default. I don't understand why a linux filesystem would inherently require that to be different than the vfat/ntfs behavior.

Re the uid/gui/umask options, they're not even valid for unix filesystems - so you can use them if you'd like, but they'll just generate an error and the device won't get mounted at all. :-)

I'm not familiar with kde's mounting code, but I am somewhat familiar with xfce's (exo) code, so I'll try to walk through what it does for you. If you're somewhat familiar with C, then have a look at exo-mount/exo-mount-hal.c in exo's source directory for a more complete (and probably more correct) explanation :-)

First, determine the filesystem type (vfat, ntfs, ext3, jfs, ...), and in the case of ntfs, see if an alternate filesystem type is defined (hal 0.5.12+ allows to specify an alternate handler for ntfs filesystems, e.g. ntfs-3g).

It then checks for valid mount options for that particular filesystem type; you can see these using lshal(1) and searching for the device. You can also edit them if needed by installing a custom fdi file, but that shouldn't ever be necessary, and even if you edit them, you'd still have to find a way to have the mount utility pass them to the mounting code [1].

It then substitutes your real uid and gid using getuid(2) and getgid(2) and the charset as utf8 unless you've overridden via an environment variable. Then the config file specified in [1] is checked for any additional 'automatic' options, and if present, they're filled in as needed.

It then tries to get an intended mountpoint for the device, first by checking the filesystem label, and if one is not present, it uses the "type" of device (this is where the "/media/disk" mountpoint comes from, I suspect).

Finally,the volume is mounted via dbus calls to the hal daemon. That's obviously oversimplified, but you get the idea.

[1] Newer xfce (which isn't even in -current yet) has an exo implementation that allows this via a config file.

3 members found this post helpful.

Awesome. Thanks for the explanation - just the level of detail I was looking for. I didn't think to check mount's man page, but that's got the explanation of all the options that are valid for each filesystem. The uid/gid/umask options appear to be a means of giving unix-style permission control to Windows filesystems that don't have them. They aren't valid for ext3 because, well, it doesn't need them.

I do remember that the drive was mounted to /media/disk before I gave it a label. I did several changes at once after that (labelled the fs, labelled the icon and specified the mountpoint in KDE) so I wasn't sure what did it.

The lesson here is that the behavior is inherent to the differences between the Windows filesystems and a Linux filesystem. It initially appeared to be something to do with the udev/HAL/dbus/KDE chain that makes auto-mounting work, but now I don't think it's necessary or correct to modify this behavior.

A final tweak - I changed the mount point in the KDE properties from /media/freeagent to just /media/. The annoying mount error on the first mount after a reboot seems to be gone now.

rworkman wrote:

Robby, can you point me to something that explains how to do this? Thanks, Mike.

Use the chown and chmod commands.

Thanks, I thought I had to write a udev rule, which I tried, but for some reason it did not work. chown did work. Mike.