Other mountpoints than /media and devices more than once mounted.

Stef Bon stef at bononline.nl
Wed May 6 13:52:52 PDT 2009


Hello,

I've been working on an construction which mounts networkresources (like 
Samba shares and FTP hosts ) and local devices like USB sticks in the 
homedirectory of the user which is logged in. It looks like:


$HOME/Connections/Devices/...USB sticks here....
                  Network/FTP/... ftp hosts here ...
                          Windows Network/ 
...Workgroups.../...servers.../...shares...




The browseable tree is managed with autofs, and activated through 
scripts, which are run by ConsoleKit.

It looks a lot like:

http://www.gentoo-wiki.info/Autofs#UDEV_with_autofs

but in this howto devices are also mounted at /media.

And a more detailed description about only network:

http://linux.bononline.nl/linux/automountsmbshares/index.php

It works very good with remote and local resources. With remote 
resources there are no problems, but not with
local devices like USB sticks.

Problems are caused by HAL, which always mounts devices at /media.
I can workaround this by adding a line to /etc/fstab, when a device is 
added. This causes hal to skip it's default behaviour. The mountpoint 
for the device is exact the same as the automounter does. In this case:


$HOME/Connections/Devices/$LABEL



Now this works, but this is not like it should. First, the fstab should 
always be left alone.

But futher, this does not work with more than one users, which is also 
not good.

Now, today I discovered the new DeviceKit. Does this mounting behaviour 
at /media remains the same,
or is it possible to mount a device at more than one place? For example:

the same device is mounted at two places:

$HOME1/Connections/Device/Example Disk

for user1 and

$HOME2/Connectiosn/Device/Example Disk

for user2.

For user1 only the first mountpath should be communicated with the 
desktopenvironment, for user2
only the second. And what about inactive sessions?

Looking forward to your reaction,

Stef Bon


More information about the devkit-devel mailing list