Automount: The Nickel Tour

I figure it's about time I posted an article on automount. I blogged briefly about it before, but didn't actually bother to put in any details. However, when I was playing with Kubuntu under VMWare the other day, I noticed that they don't use automount by default. When you plug in a USB device into the system, it gets detected by hotplug or D-Bus, or whatever, and the system mounts it and puts an icon on your desktop. That's all well and good, but that's not nearly as useful as being able to just close the file manager and yank out the drive when you're done. I guess that means that if I'm considering Kubuntu, I'd better chronicle my automount battle (what little I remember of it, anyway) so that I can refer to it later.

Since it's been a while and I don't really recall all the details, I'm going to skip over some of them. In other words, this is not going to be a step by step guide. Instead, I'll just cover the basics of configuration and then some "gotchas" that I encountered. It's more a quick run-down for the experienced user than a tutorial for newbies.

If your distribution doesn't already ship with automount enabled by default, you're in for a long night. In order to boost performance, automount requires that the kernel support AutoFS. This can be either built in or in a module, but you have to have it. Needless to say, there's a chance that this will involve rebuilding your kernel.

And while I'm on the subject of rebuilding the kernel, I should probably mention that you're going to want a 2.6 kernel. Yes, it's true that automount works in earlier kernels, but udev doesn't, and without udev you can't reliably use automount for USB storage devices, which completely defeats the entire purpose. (Automount needs static device names, and without udev, the system cannot guarantee that the same USB storage device will always get the same device file.) So if you're running an earlier kernel, you might as well upgrade now, since you have to do some compiling anyway.

Once you have an autofs module built, you'll need to verify that the automount package is installed. No need to worry about compiling on this one - you distribution will almost definitely have an automount package, although it might not be on the installation disk. You should also verify that you're using udev and that you have sysfs enabled.

A note of interest for Slackware users: last I checked, Slackware doesn't have an automount script in the /etc/rc.d/ directory. I don't know why, but they don't. I ended up copying the sample script from the autofs documentation (under /usr/doc/autofs-version) and modifying it to suit my needs. You can probably find one on the web someplace as well. Oh, heck, just look at mine.

Anyway, now that everything is installed, the first order of business is to configure udev. I don't know of any GUI for this, but it's really not that hard. Just open up /etc/udev/rules.d/udev.rules in your favorite text editor and start typing. Adding a line for a single device is quite easy. The line for my Lexar JumpDrive looks like this:
BUS="usb", SYSFS{serial}="L252280108120", NAME="%k", SYMLINK="jumpdrive32", GROUP="disk", MODE="0660"
This rule means that when the system finds a device on the USB bus with the given serial number, it will create a symlink to the device file with the name "jumpdrive32". Of course, you can use information other than the serial number - the choice is up to you. You can gather information on a device using the udevinfo command, for example:
udevinfo -a -p /sys/block/uba
If you're so inclined, you can also look up some of the information in KDE's info center.

Once you're all done, restart udev using whatever command is appropriate to your system - on Slackware, it's /etc/rc.d/rc.udev restart. To test it out, grab the USB thumb drive of your choice and stick it in a port. If udev is set up correctly, you should be able to do something like ls -l /dev/jumpdrive32 (or whatever symlink name you specified) and see something like this:
lrwxrwxrwx 1 root root 4 Jun 24 22:55 /dev/jumpdrive32 -> ubc1
If your output looks good, you're ready to move on. If you get a file not found error, something is wrong and you should head to the support forum or IRC channel of your choice for assistance.

Once you have the device symlinks configured the way you like, configuring automount is pretty easy. First, you'll want to make a file in /etc for each type of device automount will handle. I have three: auto.removable, auto.optical, and auto.network. These files are in a simple one record per line format. Here's an example line from my auto.removable:
pendrive -fstype=vfat,sync,user,umask=0000 :/dev/jumpdrive32
It's simply a directory name, followed by the various mount options, and host:path (for network filesystems) or :device file. Note that you will have to set up a different file for each "class" of device you want to automount, because the unmount timeout is set on a per-file basis.

After the individual auto.* files, you need to create /etc/auto.master. This is the main automount configuration file and determines which auto.* file to consult when you access a particular directory. The format for this one looks like this:
/var/autofs/removable /etc/auto.removable --timeout=2
The first field is the base mount directory for that file. This is the directory under which the devices will be mounted. (Note: if the path you picked doesn't exist, you'll need to create it.) The second is the auto.* file that you just created, and the third gives the number of seconds from the time the mount point is no longer used until it is unmounted. For my USB devices, I use two seconds because they're fast to mount and unmount. It also helps if you use the "sync" option in the mount arguments, as this will write all data added to the drive immediately, so that you don't have to worry about the system trying to sync the disk when you want the drive to unmount. For network devices or optical drives, which can take longer to mount, you might want to specify a longer timeout. I use 30 seconds for CD and DVD drives and 10 minutes for network shares.

If you have /etc/auto.master in place, you're ready to start automount. I won't tell you exactly how to do that because the exact command will vary from one distribution to another. If all goes well and you don't get any errors, it's time for a test. Stick you thumb drive in a USB socket and do an ls on the directory for that drive. For my example, I would run
ls -l /var/autofs/removable/pendrive
and, if everything is working, see the contents of my JumpDrive.

Note that the directory in the example is the name for that device (the first field in the auto.removable example) added on to the base directory in auto.master. If you changed the directory in auto.master to, say, /mnt/, then the path would be /mnt/pendrive. You should also note that if you simply do an ls on /var/autofs/removable, you won't see anything. That's because automount doesn't mount the filesystem until you access it directly. Therefore, the mount point for it doesn't even exist until you try to access it.

That's it in a nutshell. I usually make a few symlinks to the mount points in /media or wherever, just to make command line access a little easier. It's also nice to make desktop shortcuts to them. In KDE, I do this by using the "Create New->Link to Location (URL)" option in the desktop context menu to make a shortcut to the mount point or the symlik to the mount point. You can't really use the "Link to Device" because that works with the system mount points defined in /etc/fstab, and you don't want KDE trying to mount the device because that would defeat the purpose of using automount. The down side of that is that then the icon won't tell you if the device is mounted or not. However, that's not really important, since the entire point of automount is that you don't have to care if the device is already mounted. If it's not mounted, then automount will fix that, and if automount can't mount the filesystem, then KDE wouldn't have been able to either, so it doesn't make any difference.

You can reply to this entry by leaving a comment below. You can follow comments on this entry by subscribing to the RSS feed.

Comments #

    Show windows with content

    Is it not possible to have a filemanager popup with the content of the USB device - if it is a hard drive or memory stick ??

    Show content

    Yes, that can be done, but that's a different article altogether. I wrote a summary of how to do this with just udev here:
    http://www.skepticats.com/linlog/content/udevautorun/

    If you use GNOME, I understand you can do this with the GNOME volume manager. If you distribution comes with HAL and D-BUS, you can also use IVMan for this.

    udev in recent kernels

    hi
    with recent kernels hotplug is vanished replaced by udev; i am not able to find /etc/dev.d, anymore; i have to use an autorun when an usb pen is automounted like http://linlog.skepticats.com/content/udevautorun/ explain.
    But, at the moment, i am not able to find a place where put bash script to be executed.
    Any advice would unvaluable

    Use udev rules

    These days, you can do the same sort of thing with udev rules. You would create/edit a file in your /etc/udev/rules.d directory that specifies the device and the script you want to run.

    You can see an example rule in this entry:
    http://linlog.skepticats.com/entries/2007/11/Fixing_Sansa_attributes.php
    In that case, the rule has 4 parts:
    1) The kernel device - here a USB mass storage node like sda0.
    2) The action - "add" for inserting the device.
    3) Some attributes - in this case the model string, to distinguish it from other USB devices.
    4) The RUN action, which just executes a program, in this case passing it the kernel device name as a parameter.

    Hopefully that should get you started. The only hard part if figuring out the exact attributes you need to identify a particular device.

Add your comments #

A comment body is required. No HTML code allowed. URLs starting with http:// or ftp:// will be automatically converted to hyperlinks.