# No suitable automounting solution for Linux?

## LuckySandal

Here are the various automounting options available on Linux. I will discuss them all, and point out why they are insufficient. I will not include legacy options such as supermount, submount, fstab-sync, etc.

gnome-volume-manger / KDE media manager

These two options can be dismissed out of hand, because they are tied to specific desktop environments. What happens if you are running two different desktop environments in separate virtual consoles? Which automounter mounts the media, and do they conflict? What if you happen to be working from the command prompt, without a running desktop environment? Furthermore, both of these systems utilise pmount/pumount, meaning that the media must be unmounted by the same user who mounted it.

Another little piece of frustration: for some devices, such as ipods, it is not enough to simply unmount, they have to be unregistered using /usr/bin/eject. Unfortunately, there is no program called peject, so unless you are in the priviledged "disk" group (and allowing ordinary users into that group would be DANGEROUS), you are not allowed to remove your ipod.

Single-user ivman

The problems affecting single-user ivman are exactly the same as gnome-volume-manager and KDE media manager.

System-wide ivman

The only problem with this option is that there is no way to umount the media unless you are ivman or root. I know, I know, the Wiki says you should add a file under /usr/share/hal/fdi/95userpolicy/ to set the hal property storage.policy.default.mount_option.users to true. This is wrong on so many levels. First of all, the Wiki doesn't even give the right path, it would be /usr/share/hal/fdi/policy/95userpolicy/. If that were a good idea in the first place. But I don't know what sort of neophyte with a two-year degree in system admistration would tell a user to manually modify anything under /usr. If that person had had even the most superficial knowledge of Linux administration, they would have known that user configuration data is stored under /etc, not /usr. Therefore, the correct path would have to be /etc/hal/fdi/policy/95userpolicy. But I digress. The even more embarrassing fact about this little piece of "advice" given in the Wiki is that the "users" is not a mount option. It is a placeholder used in an /etc/fstab entry to tell the mount command that any user is allowed to unmount the device associated with that entry. Unfortunately, ivman does not create fstab entries, so this little trick was only relevant in the old days of legacy fstab-sync.

 Conclusion

What then remains? Maybe if the Linux kernel were modified to actually support a "users" mount option that would allow unpriviledged unmounting to occur, sensible auto(un)mounting would be possible. Or maybe just allow pmount to optionally mount devices under its uid (as opposed to the calling uid) and pumount to allow any user to unmount them.  If this were achieved, then Linux could finally catch up to where commercial desktop operating systems were 10 years ago!

----------

## bollucks

 *LuckySandal wrote:*   

> Maybe if the Linux kernel were modified to actually support a "users" mount option that would allow unpriviledged unmounting to occur, sensible auto(un)mounting would be possible.

 

Linux has only had this user option for fstab for, oh, 14 years now.

----------

## LuckySandal

 *Quote:*   

> Linux has only had this user option for fstab for, oh, 14 years now.

 

You obviously didn't read my original post very carefully. I quote myself:

 *Quote:*   

> The even more embarrassing fact about this little piece of "advice" given in the Wiki is that the "users" is not a mount option. It is a placeholder used in an /etc/fstab entry to tell the mount command that any user is allowed to unmount the device associated with that entry. Unfortunately, ivman does not create fstab entries, so this little trick was only relevant in the old days of legacy fstab-sync.

 

Yes, you have been able to place the "users" option in fstab. But, automounting does not use fstab. "users" has never been a mount option as far as I know. For instance, if specified on the command line, e.g. mount -o users /dev/sda2 /media/TravelDrive it has no meaning. It is only meaningful inside an fstab entry. I'm saying it should be made meaningful to the kernel, so you can unmount devices mounted with -o users without having an fstab entry.

----------

## bollucks

My bad. For the record it shits me too.

----------

## Mad Merlin

I've been using supermount-ng for awhile now and am quite pleased with them. For quite awhile, the -ck branch carried the ported patches, but this stopped around 2.6.13, since then I found someone else who had ported the patches to newer kernel versions. I'm currently using 2.6.14. I hope someone comes up with a suitable solution to this problem. Supermount is pretty old and apparently very hacky and ugly, but it works. I'm not particularly excited about manually mounting or any of the "new" solutions to this problem that I've seen, so hopefully someone comes up with something better in the mean time.

----------

## massysett

LuckySandal--

 *Quote:*   

> Here are the various automounting options available on Linux. I will discuss them all, and point out why they are insufficient. I will not include legacy options such as supermount, submount, fstab-sync, etc.

 

fstab-sync is not an "automounting option." fstab-sync does not mount anything. It merely edits your /etc/fstab in response to HAL events. And yes, it uses HAL, which is relatively new, meaning that fstab-sync is not a "legacy option" either.

If the wiki is wrong on ivman, why not edit it? It's an interesting thing you say about putting the file in /etc/ rather than in /usr/. So I tried it and restarted my hal daemon. It didn't work.

 *Quote:*   

> automounting does not use fstab

 

Hunh? ivman certainly uses it. Try man ivman: "Ivman  requires  correct  entries in /etc/fstab(5) in order to mount volumes."

 *Quote:*   

> If this were achieved, then Linux could finally catch up to where commercial desktop operating systems were 10 years ago!

 

We're all volunteers here; informed criticism can help, but random uninformed sniping helps no one...

----------

## blueSceaDa

This is also one of my problems, the stuff described in the wiki isn't correct..

ivman just mounts as user=ivman .. and I can't unmount it... annoying for usb-storage. CD/DVD's get unmounted by pressing the button on the drive though.

----------

## blueSceaDa

Got some solution that works for me (don't know where I found it..):

just normally let ivman run, don't change anything:

emerge ivman

rc-update add ivman default

as a user, I also run ivman (just "ivman" as command) a second time (I put ivman in the .kde/Autostart folder (you need to put .desktop files  there))

now everything works, I can unmount everything as my user... I don't know if the root ivman daemon really has to run for this.. it just was mentioned on some site, and it works for me..

I wish everybody luck with it!   :Wink: 

----------

## adsmith

so.... what's wrong with ol' autofs?

----------

## blueSceaDa

 *adsmith wrote:*   

> so.... what's wrong with ol' autofs?

 

.. getting sure everything is really written on your usb mass storage device   :Wink: 

----------

## adsmith

How so?  

I find that autofs with with sync set (so operations don't finish until data is actually written) and an auto-unmount time of 1 second (so it unmounts essentially immediately upon not being accessed) is really great.  You'd really have to TRY to pull out the device before it's ready.

----------

## blueSceaDa

What do you mean with try? You never know if some app is accessing it ... and sync isnt so good for flash storage afaik (if you put stuff on it, and remove etc.)

and no problem with ivman, it works for me  :Wink:  It mounts, and in kde I can use the storage applet for kicker to "safely remove" (unmount) it..

----------

