Automounting card readers and USB keys using autofs
Posted by chris on Mon 25 Apr 2005 at 12:57
Following on to the previous article on Card Readers and USB keys using udev we can go one step further and get automounting working.
Most of the information here is taken from http://www.greenfly.org/tips/autofs.html but is modified to match the information from the udev article. The naming conventions of the config files etc are taken from the greenfly article - which includes many more things you can do with autofs :)
Getting autofs
Again - on sarge or sid it should be as simple as
apt-get install autofs
We want to replace the following /etc/fstab settings
/dev/card_sd1 /media/sd vfat rw,user,noauto 0 0 /dev/card_cf1 /media/cf vfat rw,user,noauto 0 0 /dev/card_sm1 /media/sm vfat rw,user,noauto 0 0 /dev/card_ms1 /media/ms vfat rw,user,noauto 0 0 /dev/mobiledisk /media/mobiledisk vfat rw,user,noauto 0 0
Step 1 - configure autofs
Edit /etc/auto.master - add the line
/var/autofs/removable /etc/auto.removable --timeout=2
This means that autofs will watch the /var/autofs/removable directory, using the configure file /etc/auto.removable and with a 2 second timeout for disconnection (how long to wait before you can pull the device).
Step 2 - configure auto.removable
Remember from the udev article and the fstab listed above that we are interested in the /dev/card_xx devices, plus the /dev/mobiledisk USB key. So - in /etc/auto.removable (new file) add
card_cf -fstype=vfat,rw,gid=100,umask=002 :/dev/card_cf1 card_sm -fstype=vfat,rw,gid=100,umask=002 :/dev/card_sm1 card_ms -fstype=vfat,rw,gid=100,umask=002 :/dev/card_ms1 card_sd -fstype=vfat,rw,gid=100,umask=002 :/dev/card_sd1 mobiledisk -fstype=vfat,rw,gid=100,umask=002 :/dev/mobiledisk
Step 3 - restart autofs and test
/etc/init.d/autofs restart
Stick a card in one of the slots (say the sd card) - and try
ls /var/autofs/removable/card_sd/
You should get the directory listing of the card - for my Nikon I get
dcim/ misc/ nikon001.dsc*
Step 4 - Linking in to the system
In the udev article we used the /media directory for mount points. Remove any cf, sd, ms, sm or mobiledisk directories and replace them with symlinks
ln -s /var/autofs/removable/card_cf cf ln -s /var/autofs/removable/card_sd sd ln -s /var/autofs/removable/card_ms ms ln -s /var/autofs/removable/card_sm sm ln -s /var/autofs/removable/mobiledisk mobiledisk
Now you should be able to e.g.
ls -l /media/sd/
and see the cards contents. 2 seconds later it's safe to pull the card/key from the machine.
Notes on the mount options
Using the gid of 100 and a umask of 002 sets the device to rwxrwxr-x root.users. You can add a uid=1000 (or whatever your uid is to set it so that only your user can access the cards contents. You may want to set noexec or similar - especially if keeping root.users
Once again - thanks to greenfly.org for the background info here - I would recommend folk to take a look at http://www.greenfly.org/tips/autofs.html for further ideas :)
Hopefully someone out there can fill in the last part of the puzzle for you.
[ Parent | Reply to this comment ]
pmount settings need to be altered in configuration files (in Debian, the package is installed by default with normal user access turned off for security reasons - read the docs)
In the case of two identical drives, the device will be mounted on /media using the filesystem label, which can be changed or added using tune2fs or equivalent for other fs, as long as there is no reference to it in /etc/fstab.
under desktop preferences => removable drives and media there is a tab where you can check/uncheck automount, browse, etc.
So: plug in the drive and and icon appears on the desktop, and a browser opens if you want.
Drawbacks: The suid bit is not set under pmount, so write access is denied to the normal user by default. The program does not allow for safely unmounting the fs prior to unplugging, so the user has to remember to right ckick the icon and select unmount prior to unplugging.
Hope this helps on that one.
[ Parent | Reply to this comment ]
Project utopia (iirc) does _not_ use autofs, but I might be mistaking
[ Parent | Reply to this comment ]
Maybe /etc/hotplug.d/usb, and then run autofs off a /dev/mapper/blah event? Make life a lot easier.
Any input?
[ Parent | Reply to this comment ]
It would be nice to extend this so that ls /smb/servername/mount does the expected thing. This would be similar to what you'd need to do - both script and mount.
Have to say that hotplug is still a black-box for me - it's on the list of "things to play with".
[ Parent | Reply to this comment ]
-fstype=smbfs \
/share1 ://server/share1
/share2 ://server/share2
So - scripting in autofs is scripting to generate the config details.
What are you using for the encryption? I've used loop-aes - and you can then add the loop=/dev/loop1,encryption=AES128 options to the autofs config the same way as any other mount options - but - how to enter the password that loop-aes prompts for I'm not sure.
I do know that passwords can be difficult. I've used lufs to mount over ssh (with ssh keys) but we use ssh-agent and that needs a password. No idea how to send it in :(
[ Parent | Reply to this comment ]
This allows me to use a keyfile in place of a password for the partition or device initialisation off an encrypted root, with single command. Can use AES with essid and a sha256 seed...
Check here: http://www.saout.de/tikiwiki/tiki-index.php?page=HomePage
Works good on an encrypted root, home, and swap (though the 2.6.11.7 kernel tends to thrash a bit in the cryptoswap - be warned)
I'm thinking more along the lines of running this, which will give the system a mapping for the device in dev/mapper/blah and then mount and unmount through autofs when the mapping is there (dev/mapper/blah shows up).
Briefly, /dev/mapper/blah ain't there until it's told to be by the cryptsetup command. After it's there, you can format it using mkfs (or whatever), mount it, and use it normally. Only gotta format once. Shutdown. Reboot. To get the device back, run the exact same cryptsetup command that you used to create the device, and it's there ready to mount. If you don't run that exact same command, the system sees nothing but random data on the device - excellent question for the bad guys to ponder ;) Cryptsetup has methods for automounting static devices on boot, but I don't think anybody's published a method for hotplugging a harddrive yet.
So, back to the question: How do I run the script that runs cryptsetup on a hotplugged harddisk prior to automounting?
I'll need to remember that scsi USB drives take a little time to settle before being fully identified as such...
Cheers
[ Parent | Reply to this comment ]
Got an almost today...
Will publish results under seperate article, and the perls or bashes (leaning towards a perl, but I still think it may take just a simple bash) when it's done.
Ciao
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
Goal: a laptop with 140 gig or thereabouts encrypted storage, 80 gig of which hotpluggable ;)
[ Parent | Reply to this comment ]
Coincidentally, the July issue of Linux-magazine www.linux-magazine.co.uk has an article on doing just this and describes the setup of hotplug to recognize a particular USB device and run an arbitrary user script.
This is now working very well for me.
In outline, you add a entries to a xxx.usermap in /etc/hotplug/usb which name a script (in the same directory) to be run when a USB device is inserted.
Hope this helps
Pete
[ Parent | Reply to this comment ]
In order to avoid opening the hotplug box, I just hacked up this autofs script. It meets my needs so someone else may find it of use too. It will automount an encrypted block device at /dev/sdb using whatever name you choose. The key files with a corresponding name in /etc is used to decrypt the device.
I have a set of removable hard drives that are used for backup (RDX QuikStor). With the following configuration I can insert a cartridge and the backup software (Bacula) can just mount it, making the encryption transparent to it.
The mapping for the 'cd' key also appears in this script. That's there because I'm mounting this at /media and hijacking the original, static /etc/auto.media. In /etc/auto.master:
/media /etc/auto.mediaIn /etc/auto.media:
#!/bin/bash # This is the path beneath this map's root that autofs is looking for key="$1" # A static mapping for the key 'cd' # This is what /etc/auto.media used to do statically if [ "$key" == "cd" ]; then echo -fstype=iso9660,ro,nosuid,nodev / :/dev/cdrom exit 0 fi # The cryptsetup tool from the package of the same name CRYPTSETUP=/sbin/cryptsetup # This is the raw device that we will mount mount_device=/dev/sdb # This is the encryption key file key_file=/etc/quikstor.key # Options to pass to the cryptsetup tool luks_opts="--key-file $key_file" # Mount options for the encrypted fileystem mount_opts="-fstype=xfs,defaults" # The mapped block device crypt_device=/dev/mapper/$key # Give up if there is no key or setup tool [ -r $key_file ] || exit 0 [ -x $CRYPTSETUP ] || exit 0 # If there is an encrypted device mapped in already, it must be from a # previous mount. It may be out-of-date so remove it now. [ -b $crypt_device ] && $CRYPTSETUP remove $key # Give up if the raw device doesn't have a LUKS header $CRYPTSETUP isLuks $mount_device || exit 0 # Open the encrypted block device $CRYPTSETUP luksOpen $mount_device $key $luks_opts >& /dev/null || exit 1 # If we ended up with a block device, echo a mount line for autofs to use if [ -b $crypt_device ]; then echo $mount_opts / $crypt_device fi
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
At least,for now,this isn't easier nor better.I had my system recogniseing and automounting my ipaq,ipod,camera,IrDA,media reader,usb ext. harddrives,and bluetooth.Now ipod works and my reader is recognised but nothing mounts except ipod.Hopefully someone will make a better usb-storage script to work with udev,autofs,and hal and what not.
What was the reason for the switch over to udev anyway?I miss /mnt/ already,I hate /media!!;)
[ Parent | Reply to this comment ]
I am having one little problem. Maybe I missed a configuration detail, or something else. But am finding this note in /var/log/daemon.log:
/var/log/daemon.log:Feb 9 21:20:01 localhost automount[9131]: lookup(yp): map
auto.removable: Local domain name not set
Where the heck would it like my local domain name set? I am not running yp, nor do I really want to, this is a desktop box...
Rob
[ Parent | Reply to this comment ]
I think I'll need to see the contents of /etc/auto.master and /etc/auto.removable files.
I found the following on a mailing list (in fact - the openldap list):
"By default, a map which doesn't have its type specified is treated as either a file-based map (if there's a file in /etc with the map's name) or as a NIS map, regardless of where the master map entry was stored."
which suggests that the master file isn't finding a file map and so thinks it may be a NIS map.
[ Parent | Reply to this comment ]
$ cat /etc/auto.master
#
# $Id: auto.master,v 1.4 2005/01/04 14:36:54 raven Exp $
#
# Sample auto.master file
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# For details of the format look at autofs(5).
#/misc /etc/auto.misc --timeout=60
#/smb /etc/auto.smb
#/misc /etc/auto.misc
#/net /etc/auto.net
/var/autofs/removable /etc/auto.removable --timeout=2
$ cat /etc/auto.removeable
card_cf -fstype=vfat,rw,gid=100,umask=002 :/dev/card_cf1
card_sm -fstype=vfat,rw,gid=100,umask=002 :/dev/card_sm1
card_ms -fstype=vfat,rw,gid=100,umask=002 :/dev/card_ms1
card_sd -fstype=vfat,rw,gid=100,umask=002 :/dev/card_sd1
flashdrive -fstype=vfat,rw,gid=100,umask=002 :/dev/flashdrive
There it is, almost identical to yours. Glad to have you respond, I am getting no answers anywhere else.
Rob
[ Parent | Reply to this comment ]
/var/autofs/removable /etc/auto.removable --timeout=2
cat /etc/auto.removeable
Look at the spelling of removable in those two lines.
[ Parent | Reply to this comment ]
Rob
[ Parent | Reply to this comment ]
add one line to your great article after:
"Stick a card in one of the slots (say the sd card) - and try
ls /var/autofs/removable/sd/"
If you just type ls /var/autofs/removable/ and keep hitting TABulator (like me:), you don't get any device, you have to type that device to the end.
Quote from greenfly.org page "Notice that the cdrom directory didn't exist in /var/autofs/removable until I actually tried to access it. Then it only existed until it timed out, which, with my configuration, is 2 seconds, and then it umounted."
or maybe im just too slow :)
[ Parent | Reply to this comment ]
daemonoptions='--ghost'
Restart autofs, and your directories will always be there, but not mounted until you access them.
[ Parent | Reply to this comment ]
After reading both this article and the "article on Card Readers and USB keys using udev" I got the device to automount. I have a question about the first part of this article. Toward the top it states "We want to replace the following /etc/fstab settings" and gives a grey box with a list of stuff from the fstab. These were carried over from the previous article about Card Readers. Am I supposed to remove the lines from the fstab or keep them in there? I put them in there from the previous article. The line I actually added says:
/dev/external_hd1 /media/dragon vfat rw,user,noauto 0 0
All of this is being learned to be able to automount a camera for reading the pictures in it on my daughter's Debian machine.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
Great article but I cannot get it to work, which I don't understand.
The only line I have in auto.master is:
/var/autofs/removable /etc/auto.removable --timeout=2
And the only line I have in auto.removable is:
usbdrive -fstype=vfat,uid=1002,gid=1002,umask=002 :/dev/sda1
I put this in to use with a usb drive, based upon the greenfly article, and the settings I took from your page didn't work.
However, when I try:
ls /var/autofs/removable/usbdrive I don't get an error but nothing is returned!
Would you have any idea why this would occur? I should mention that I am doing this on a intelmac, but don't know if this should make a difference. autofs installed fine.
cheers, nathan
[ Parent | Reply to this comment ]
I thus change my ato.removable live to:
usbdrive -fstype=vfat,rw,gid=100,umask=002 :/dev/sdb1
and it worked.
This article obviously followed on from the previous one in which the devices (and their tags?) were identified, something that wasn't covered. I guess that's the danger of trying to copy commands without fully understanding them. I still don't understand how drives are given names by the system or whether they remain stable.
One observation I did make was that this system did work nicely when examining files on the usb disk, and opening files in openoffice. However, when I open a file from the usbdrive in openoffice it is read only and when I try to save a new file on the usbdrive I get an error saying the folder does not exist. I guess this has something to do with permissions to write to the disk, but haven't been able to work that one out yet.
[ Parent | Reply to this comment ]
I was able to get automounting working, sort of, so came here to research it. I've had my system setup to use the LABEL=.... feature in /etc/fstab, for the USB devices, but wanted to get away from having to run the mount command manually or through an icon, every time I wanted access.
The main difference between my setup and yours is that I figured I could use the same label based reference to make it work regardless of the actual /dev node.
So, I have lines like this:
xdcard -fstype=vfat,umask=002,gid=usb :/dev/disk/by-label/FUJIXDCARD
The last item is a symlink to whatever node is actually created.
But, there's a problem. The xdcard item worked only about 30% of the time, while the one for my Archos PMA400 worked 100%, and the others all failed, period. After much futzing around, I plugged in the current node for the xdcard (/dev/sdc1) and tried that. This worked, and continues to work, no problems of any sort.
This implies a problem in autofs with symlinks. I thought this should be a bug, but as my experience with this part of GNU/Linux is limited, I thought I'd pass it by you and others in this discussion, and see if there is agreement on that. And, to find out if there's a way to make the symlink stuff work.
I know I could go back to the udev setup and create my own names, but this seems like it should work, in any case.
Bob
[ Parent | Reply to this comment ]
It looks like the automount files in /etc are format sensitive. I believe I discovered this when I used cat on the content of one and realized it contained tabs. I have my editor set to replace tabs with white space, which is normally OK and very nice when writing programs.
When I replaced my 'space' field separators with tabs, everything worked, even using the symlinks created in /usr/disk/by-label..
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
Thanks again!
[ Parent | Reply to this comment ]