Automounter Madness

The world of automounters is a confusing one. For one thing, a single automounter wasn't enough, so there are two of them for Linux, called 'amd' and 'autofs'. While it's easy to say 'well, just pick one and go on your way', many environments have demands that will require both, and both serve different purposes and have different strengths and weaknesses. The automounter world is not so cut and dry. In this article, I'll give a light overview of what amd and autofs look like, what their respective purposes are in life, and go over some of the common configuration options for each. Later, I'll spice things up by including use cases where one will work better than the other and more advanced features available to you as an administrator.


Why Use an Automounter Anyway?

Automounters can be a real pain in the neck. Admins don't like things that are a pain in the neck, so one should be able to gather that if we're putting up with these things, they must be pretty darn useful - and they are. For one thing, automounters can get their mounting information from centralized 'maps', which can be flat files, or even NIS maps or sections of an LDAP directory. This is far easier than editing 300 /etc/fstab files for different static NFS mounts.

In addition, mounting a directory with an automounter means that it is automagically mounted and unmounted as needed. A static NFS mount is usually mounted at boot time, or done manually after boot, and only unmounted during your 'netfs' service shutdown, or by hand using the 'umount' command. The difference is apparent during a failure: if the remote file server becomes unavailable, an automounter will time out, unmount the directory, and move on, whereas a static NFS mount will hang until the server comes back.

There are other configuration options that automounters can take that make them a more desirable tool for administrators. We'll talk about some of them once we've laid a proper foundation for more advanced topics.

Amd or Autofs? What's the Difference?

Probably the biggest difference between amd and autofs is where their code lives. Amd is the 'userland automounter'. It works like a lot of other networked applications using RPC (Remote Procedure Call). The good news is that this should make the application's inner workings easier to understand for those who use other RPC-enabled applications. The bad news is that the RPC calls go to the kernel, where file system code lives. Every time it makes a file system call to the kernel, it incurs a context switch, where the duties involved in carrying out an operation pass from the user space to the kernel space. This is a somewhat costly proposition for something that could potentially be doing a hundred or more operations per second.

Autofs, by contrast is an 'in-kernel' automounter. It also uses maps to figure out what its job is, and the userland interface for this is the automount(8) utility. Generally, in a working environment, my experience has been that it's rare to have to actually resort to using 'automount'. Still, it's a good tool to know about, 'just in case'.

On top of the performance boost associated with being in kernel space, autofs also enables administrators to perform mounts 'in place'. This means that directories are mounted under the mount points used directly by the users. This closely mirrors how administrators of static NFS environments would expect things to work. Amd does not perform mounts this way, and by design, it cannot perform in-place mounts. Really. Don't try it at home. Bad things will happen.

While it's probably quite easy to look at this comparison and make your mind up right now about which one is 'better', remember that this term is completely meaningless outside the context of a production environment. Each one has benefits in certain situations. As a production, enterprise administrator, you really need to have a knowledge of as many mounting methods as possible.

For now, let's focus on a typical config file from each daemon, which will allow us to discuss some of their respective features in a bit more detail.

Autofs Configuration

The master configuration file for autofs is /etc/auto.master. Here's a (relatively small) typical sample config:

/.autofs file:/etc/ --timeout 300
/mnt file:/etc/auto.mnt --timeout 60
/n/fs yp:automap --timeout 300

This file consists of three fields; the first being a mount point on the local filesystem. This means when you do an 'ls -a /' on a machine whose autofs used this config file, you should see an /.autofs directory, a /mnt directory and a /n directory (under which is the 'fs' directory specified in '/n/fs'). The second field is of the format <maptype:maplocation>, and specifies the map that will handle the mounting of directories under the mount point for that entry. So, to see what will be mounted under mount point /.autofs, you'll have to look at the file /etc/, which is the map for that mount point.

You'll notice the /n/fs entry is slightly different in that it specifies 'yp:automap' in the map field. We also have the keyword 'file:' in front of the other map field entries, even though 'file' is the default, just to be safe (actually, in RH 7.3, autofs threw loads of errors until the keywords were put there). The 'yp' keyword tells the automounter to look up the map using NIS.

Let's have a quick look at the '' and 'auto.mnt' files referenced in the master config file. We'll look at 'auto.mnt' first:

cdrom -fstype=iso9660,ro :/dev/cdrom
floppy -fstype=vfat :/dev/fd0
isoz -ro,hard,intr isoserv:/cd-images

The above 'auto.mnt' file specifies mount points managed by autofs. All of these directories will be mounted as subdirectories of the '/mnt' directory, as implied by the '/mnt' entry in the auto.master file referenced earlier. The flags here are probably self explanatory, but just to make sure everyone's on the same page, the '-fstype' has to be a valid filesystem type on your system, and match that of what you actually try to mount (ie, you can't put 'ufs' in for the cdrom device and expect your audio cd's to work). The last field is of the form <host:filesystem>. If the 'host' part is blank, 'localhost' is assumed. From that, you can see that we have set up two local devices to be automounted (floppy and cdrom), and a remote filesystem, which we'll access using, for example 'cd /mnt/isoz', and will be mounted from the '/cd-images' directory on the machine called 'isoserv'. Don't forget, we know all of these directories will be under '/mnt' on the local machine because this is the 'auto.mnt' map, which, according to 'auto.master', is the authoritative map for all things automounted under '/mnt'!

As you've probably noticed, you can string along other mount options in the middle field of these config files. These options come from the standard list of mount options, which you can find in the mount(8) man page, and probably other documents as well. If you understand this, you should be able to apply the same exact logic to the '' map. The only difference between these files (and any others listed in auto.master) is the local mount point they are in charge of.

Amd Configuration

Amd gets its main configuration information from a file modeled after the Samba configuration file, and it's called /etc/amd.conf. This file contains global settings for the daemon, and, like autofs, delegates the configuration of different local mount points to seperate map files. Here's a rather typical example of an amd.conf file - ripped to shreds to explain the options in a little more detail:

[ global ] # Global settings: these affect how the base daemon runs

normalize_hostnames = no # If set to 'yes', amd will use fully qualified hostnames when contacting remote hosts.

print_pid = yes # print process id number to file indicated by 'pid_file' param. below.

pid_file = /var/run/

restart_mounts = yes # causes amd to create a data structure for each file server in /etc/mtab, speeding mount times for new mounts.

auto_dir = /.automount # this is the actual directory under which filesystems are mounted.

log_file = syslog # Instead of logging to a file, amd sends messages to the local syslog daemon.

log_options = all # tells amd to log every message. Other options are 'debug', 'warn', etc. This can be a comma-delimited list.

plock = no # this tells the linux kernel to treat amd like a normal, userland app. Set to 'yes', amd generally runs faster, since the kernel will reserve memory for amd, and text and data pages will be locked using the 'mlock' system call. The downside is, of course, you are permanently reserving memory for amd, making it unavailable for other 'stuff'.

print_version = no # Prints the amd version to the terminal at startup and runs as normal.

map_type = file

search_path = /etc # this is the directory where amd expects to find its maps.

browsable_dirs = yes # this means that amd will show *active* directories in 'ls' output. Note that others may be mounted in the background!

show_statfs_entries = no # this passes some useful information to the 'statfs' call used to produce 'df' output. Note that it is NOT accurate in the context of 'df' output. It doesn't return percent used or 1k blocks - it returns instead the number of entries in a map, and the number of those entries that are active. df then uses those two numbers to calculate the '% used' number, which in the case of amd is really the '% of map entries that are active'.

fully_qualified_hosts = no # tells amd whether to use FQHN's during RPC authentication. Note the difference between this and 'normalize_hostnames' above, which is used only in the act of mounting remote filesystems and doesn't address authentication.

cache_duration = 300 # tells amd how long (in seconds) to keep filesystem to volume mapping details in memory.


[ /net ] # the directory users will use for the mount point.

map_name = # The map that will define what users can get to under the '/net' directory.

map_type = file # The type of map that is. </clue>

There are a few things that need discussing here. One is the notion of the 'auto_dir', which is unique to amd, and illustrates the earlier point about amd not supporting 'in-place' mounts. What happens is that when amd starts up, it will mount anything it is told, under the directory specified by 'auto_dir' in the amd.conf file. From there, as an administrator, you would make symlinks into this directory from the target points in the filesystem. So if a directory called '/u' is mounted, then '/u' on your local filesystem would actually be a symlink to '/.automount/u'.

Let's have a look at the '' file, which, according to amd.conf, contains configuration information for things mounted by amd under the '/net' directory on the local system. It contains only two entries:

/defaults fs:=${autodir}/${rhost}/root/${rfs};opts:=rsize=8192,wsize=8192

* rhost:=${key};type:=host;rfs:=/

The above '' is a file that contains the parameters of the '/net' mount point. This is a fairly simple map, with just a '/defaults' entry and one wildcard entry denoted by the '*'. The defaults entry is one that is usually configured by default with most distributions of amd, and simply contains the path to the temp directory for the automounted directories. This can be a bit difficult to parse. The '${autodir}' variable is defined by the 'auto_dir' line in amd.conf. The '${rhost}' variable defaults to the local hostname. This is followed by '/root', which is a placeholder for '/', and the '${rfs}' variable, which defaults to the amd '${path}' variable, the default value of which is ${map}/${key}. You can look at this as the path element being looked up by the user under the directory managed by this map. The default value for ${map} is the directory this map represents, or, in this case '/net'. In case I haven't made that crystal clear, know that if the directory we're trying to reach is '/net/mybox/home/jonesy', then the above 'defaults' entry would translate to a path under the /.automount directory, and amd would return a symlink back to the user under '/net' which would be transparently used to reach whatever the user is looking for.

The '*' wildcard entry says to mount all directories exported by whatever machine the user specifies ( ${rhost} ), which becomes the ${key}. This allows a user to log onto a machine in a local workgroup-style configuration, and get access to any shares available on any host by simply typing 'cd /net/<host>/<remote dir>'. If that directory is exported by the host specified, it will be automounted and made available for the user who requested it.

In Closing

In this whirlwind introduction, I've introduced the basics of automounter configuration under Linux. This is really just the tip of the iceberg where their usage is concerned. These config files have a ton of options available for them, allowing you to employ some logic in them, to allow your automounters to be 'smarter' about how they do their work. While this article lays a very preliminary foundation, future works will explore more advanced and often-times unused functionality been built into the daemons in more recent versions.