automount and autofs


System Administration


[picture of Frederic]


original in fr. Frédéric Raynal

fr to en Philippe Trbich and Emmanuel Bonnel


Frédéric Raynal is preparing a computer science thesis in the INRIA. He loves reading (from Tolkien to Balzac) and listening to music (from Mozart to Philip Glass and from Led Zeppelin to Massive Attack or to Björk and Boris Vian, but carefully avoiding rap, techno and some other noise ;-)


automount and autofs are powerful tools and ease file systems management. They allow all the users of a same machine to mount different file systems automatically the very moment they are needed.





Dependent on the physical support (hard disks, floppies, cdrom, ...) and/or the operating system, the process of writing of data (not its meaning) is different : this is what we call file system (I hope experts and purists will forgive me for the short cuts ;-) The /etc/fstab file holds the hard mount points to be installed at boot time. Each point corresponds to a place and to a file system (for example, one of your hard disk partitions). Later on, if you want to access other points, only root can use the mount (unless the special option "user" is provided in /etc/fstab) command. As root, you must specify the mount point, what you want to mount and possibly, the file system and some options. A common user not having, (fortunately ;-) the same rights, won't be able to access all the data.

Mount and fstab man pages give a more accurate and complete description of these commands and concepts.

Both (automount, autofs) allow the administrator to configure all file systems a machine can access, the same way he would using mount. The user can then access these systems in a fully transparent manner, without worrying about how the kernel will answer his request.


The pair (automount, autofs) can be seen as the client/server model used in networking. A server is running, waiting for a request. When a request comes, the server autoduplicates, one part answering the request and the other one waiting for new requests.

Here, autofs plays the role of the waiting server and automount the one of the "duplicated server". The requests are hold in configuration files.


Usually, autofs is launched at boot time and is closed at shutdown (or reboot) time. However, the administrator is able to start or stop it "manually".

autofs can have 4 different options :

  1. start :
  2.  as its name says, starts the proccess. When starting, autofs looks for "maps" (maps specifying mount points) in the configuration file /etc/auto.master. Then it starts automount for every mount point. Next, autofs looks for NIS maps (we won't say more about yellow pages in this article);
  3. stop :  stops autofs and all automounts ;
  4. status :  displays the present configuration and all running automounts ;
  5. reload :  rereads the auto.master map and kills the no more appearing automounts and starts those for new mount points. Note that changes made in the maps are taken into account at next startup. On the other hand, the changes made in auto.master imply an autofs restart.

In short, autofs is nothing else but a script consulting auto.master before starting the automounts associated to each described mount point.


automout works from an initial mount point (the one found by autofs to start automount) and from a new map describing the features of this initial mount point. The map associated to the automount will hold all required information for mounting the file system automatically (hence the name ;-). This automatic mount is done as soon as someone tries to accesses something in the directory tree starting from the mount point.

Next, the file systems are automatically "unmount" after an inactive period (the default time out is 5 minutes).


The configuration is done with the help of 2 files. The auto.master file, holding the mount points, and a mount point file providing the system options for this specific mount point.

/etc/auto.master file

Here, we describe the maps using Sun format. The other format (hesiod) can't handle the syntax described below.

/etc/auto.master is the autofs's main file. Each line describes a mount point and refers to the file containing the file system's descriptions having to be mounted from that point. A last field allows to pass options to the mount to be started.

The line syntax is  :
mount-point map-for-the-associated-automount [ -mount-options-separated-by-comma ]

Example :

/home /etc/auto.home
/misc /etc/auto.misc --timeout 60
/mnt -intr,nosuid,nodev

This configures 3 mount points, /home, /misc and /mnt. To access files in /misc, automount will read the file /etc/auto.misc to find the mount options and the key associated to the file system.
The last 2 lines hold options. They are described in the mount man page and are standardized. As shown in the last line of the example, autofs and automount are fully compatible with yellow pages maps (NIS and others).

Automount's maps

The syntax of this file is almost the same as the auto.master one (it's normal since it's a map too ;-) :
key [ -mount-options-separated-by-comma ] place

The key represents an identifier for the file system under the mount point . The place is the true physical location.

Let's go back to the previous example with an /etc/auto.misc file :

kernel -ro,soft,intr
cdrom -fstype=iso9660,ro :/dev/cdrom
floppy -fstype=auto :/dev/fd0
windoz -fstype=vfat :/dev/hda1

The absolute path to a file is then :

Then to read my windows config.sys, I just have to execute "cat /misc/windoz/config.sys" and it accesses the /dev/hda1 device.

We can note that the first line of the file refers to an NFS exported directory (just to show the flexible use of automount and autofs ;-)

Last details

First, we must note that when we try to reach a file in one of the maps, the path completion is not working as usual. To avoid typing the full path, we often use the TAB key automatic completion. If the map is not loaded, the key doesn't work. Going back to the previous example, if I want to access the same config.sys and I do :
%1 > cat /misc/ <TAB >
I will only get a disappointment "beep" since it will find nothing to complete (don't mistake it with the happy "beep" issued when there are several choices - to distinguish them, you have to type a <CTRL+D> and you can see all the available completions appearing, if they are some).

As a matter of fact, this behavior is quite normal. Obviously, when you try to use completion, the directory's content is scanned, then you watch what matches the provided symbols. In that case, the /misc directory is empty since the goal is to mount the file system only when accessing it. On the other hand, you can't use completion until the mount point is automatically cancelled (i.e. when no more resource is required from this file system and the time out is over).

Let's have a look at the result of a mount before and after the access to a map, considering the previous /etc/auto.master, with a single mount :

/dev/hda6 on / type ext2 (rw)
none on /proc type proc (rw)
/dev/hda9 on /home type ext2 (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
automount(pid362) on /home type autofs (rw,fd=5,pgrp=362,minproto=2,maxproto=3)
automount(pid364) on /misc type autofs (rw,fd=5,pgrp=364,minproto=2,maxproto=3)
automount(pid366) on /mnt type autofs (rw,fd=5,pgrp=366,minproto=2,maxproto=3)

We notice that there is a daemon (deamon - roughly a system process) for each mount point. Furthermore, each associated "type" is "autofs". After having viewed my /misc/windoz/config.sys, here is the result of the mount :

/dev/hda6 on / type ext2 (rw)
none on /proc type proc (rw)
/dev/hda9 on /home type ext2 (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
automount(pid362) on /home type autofs (rw,fd=5,pgrp=362,minproto=2,maxproto=3)
automount(pid364) on /misc type autofs (rw,fd=5,pgrp=364,minproto=2,maxproto=3)
automount(pid366) on /mnt type autofs (rw,fd=5,pgrp=366,minproto=2,maxproto=3)
/dev/hda1 on /misc/windoz type vfat (rw)

The last line holds what we expected :) If we wait 60 seconds without accessing this mount point, it will disappear at next mount.


On a personal computer running Linux and, for example, Windows, automount and autofs are rather useless, except to avoid a frequent root login (what is, in fact, not so bad). Enough to define a map for the FAT and FAT32 partitions and so accessing data.

In the case of a network, the flexibility is even greater since, combined with yellow pages (we will study them in another serie of articles) and NFS among others, we can access everywhere without worrying about where we physically are.

A great benefit of automount is that a failing server will only affect those clients that currently use this specific file server. This can reduce the down time in big companies (with perhaps 10 or more nfs servers) significantly.