Automount mini-Howto don@sabotage.org v0.2, 7 September 1998 This file describes the autofs automounter, how to configure it, and points out some problems to avoid. ______________________________________________________________________ Table of Contents 1. Introduction 1.1 Automount - what and why 1.2 Types of automounting 2. Installation 3. Configuration 4. That long wait to unmount 5. Questions 5.1 I don't see /auto/floppy, or whatever mountpoint I'm looking for. 5.2 How do I see what's mounted? 5.3 I put in a win95 disk ("vfat") and it autodetected it as only a regular FAT disk. 5.4 My filesystem 5.5 Who do I thank for autofs? ______________________________________________________________________ 1. Introduction 1.1. Automount - what and why Automouting is the process where mounting (and unmounting) of certain filesystems is done automatically by a daemon. If the filesystem is unmounted, and a user attempts to access it, it will be automatically (re)mounted. This is especially useful in large networked environments and for crossmounting filesystems between a few machines (especially ones which are not always online). It may also be very useful for removable devices, or a few other uses, such as easy switching between a forced-on ascii conversion mount of a dos filesystem and a forced- off ascii conversion mount of the same dos fs. 1.2. Types of automounting There are two types of automounters in linux; AMD and autofs. AMD is the automount daemon, and supposedly works like the SunOS AMD. It is implemented in user space, meaning it's not part of the kernel. Autofs is a newer system assisted by the kernel, meaning that the kernel's filesystem code knows where the automount mount points are on an otherwise normal underlying fs, and the automount program takes it from there. Only autofs will be described in this mini-howto. 2. Installation Because autofs is implemented in kernel-space, your kernel must have support compiled in. In 2.0.xx it is an experimental option, but appears to be quite stable. In 2.1.xx (and presumably 2.2.xx) it is not experimental. The automount program and its configuration files are also necessary; using the rpms (from the usual places) is a great way to go. The automount program should be started by an rc script under the /etc/rc.d/init.d directory. The rpm installs this, but you will need to make sure it gets started, either by linking it from your rc?.d directory, using Redhat's control-panel, or on another distribution by getting the thing started anyway you care to. Don't look too hard at what the rc script does; if you're reading this howto you probably don't want to know. 3. Configuration Installing the RPM's is fun, but here's the part you might not be sure about if you haven't done this before. There are two files in /etc, one called auto.master and one called auto.misc. My auto.master looks like this: /auto /etc/auto.misc --timeout 60 The first entry is not the mount point. It's where the set of mount points (found in the second entry) are going to be. The third option says that the mounted filesystems can try to unmount themselves 60 seconds after use. They can't unmount if being used, of course. Auto.misc is a "map file". Multiple map files can be defined in auto.master. My auto.misc looks like this: kernel -ro,soft,intr ftp.kernel.org:/pub/linux cd -fstype=iso9660,ro :/dev/cdrom zip -fstype=auto :/dev/hdd4 floppy -fstype=vfat :/dev/fd0 The first column (the "key") is the mount point. In this case it would be /auto/floppy or whatever. The middle set are the options; read the mount manpage for details on this. And the last column specifies where the fs comes from. The "kernel" entry is supposed to be an NFS mount. The : on all the other lines means its a local device. 4. That long wait to unmount Some of you may be eyeing that 60 second timeout and thinking, that's a long time to wait to eject a floppy.. Maybe I'll just sync the disks and pop it out unmounted and nobody will notice. Let me suggest saner alternatives. First of all, you can change the timeout. But that could be a little inefficient; telling the system to unmount stuff after only 15 seconds or whatever. There is actually a way to ask the automount program to umount. If you send (with the program kill) the signal SIGUSR1 to the automount process, it will unmount everything it can. But before people start making unmount buttons on their window managers, there's a little problem. The automount process is run by root, and it will only accept signals from root. Half of the reason you're probably doing automounting is so you can mount an unmount *without* being root. It would be easy to make a suid-root C program which does the dirty deed, which is the suggested way of solving the problem if users aren't expected to behave themselves. If the users can be trusted somewhat, a compromise is possible with the program sudo. By installing sudo with the following line: ALL ALL=NOPASSWD:/bin/kill -SIGUSR1 [0-9]* you have made it possible for *anyone* on the system to send a SIGUSR1 signal to *any* process. This will have various effects on programs; it will recycle afterstep window manager, but kill xemacs. So if your users can be trusted to only send the process id of the automount daemon (as found by pidof, for example) then this single command can unmount things. That would be done with something like this: /usr/bin/sudo /bin/kill -SIGUSR1 `/sbin/pidof automount` 5. Questions 5.1. I don't see /auto/floppy, or whatever mountpoint I'm looking for. If automount is setup properly, whatever mount point you're looking for will be there if you try and use it. If you're browsing the directory with a graphical tool, you may need to type in the name manually. Unfortunately not being able to choose from the available invisible mount points is probably the major drawback of autofs. If it really bugs you, edit the configuration files. (Hint, they end in .c for "configuration") 5.2. How do I see what's mounted? The df command. mount with no options will do the same, plus show the options its mounted with. 5.3. FAT disk. I put in a win95 disk ("vfat") and it autodetected it as only a regular This is not a problem with automount. As of this writing, the "auto" fs type does not attempt a vfat mount before it successfully mounts an msdos filesystem. VFAT is the Win95 and WinNT long filenames crammed into a FAT/MSDOS filesystem. This means that you can't mount vfat unless you give up the ability to autodetect all other fs's. Hopefully it will be fixed soon. In the mean time, feel free to create multiple mount points. 5.4. My filesystem /grumblesmurf is mounted and kill -SIGUSR1 won't unmount it. It's being used by something. Root probably can't manually unmount it either. If you're the one who caused it to be mounted (i.e. it can't be someone else using it) look around for a shell that might be in that directory. If there are none, look for something else (particularly something that might have gone though that directory like a directory browser) that might have left an invisible foot in the door so to speak. 5.5. Who do I thank for autofs? Not me. I didn't have anything to do with it. I just wanted to bring everyone's attention to what a great job had been done with autofs, and how easy it is to use. Compared to the original perpetrators of AMD (Hint, they sell an overpriced unice with prehistoric versions of free tools) the autofs is very well documented and the implementors have my sincere thanks.