automount and autofs

ArticleCategory:

AuthorImage:

TranslationInfo:

AboutTheAuthor:

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 ;-)

Abstract:

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

ArticleIllustration:

ArticleBody:

Introduction

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.

Description

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.

autofs

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 :

start :

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);

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.

automount

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).

Configuration

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

yp:mnt.map

-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

ftp.kernel.org:/pub/linux

cdrom

-fstype=iso9660,ro

:/dev/cdrom

floppy

-fstype=auto

:/dev/fd0

windoz

-fstype=vfat

:/dev/hda1

The absolute path to a file is then :
/mount-point/key/path/file

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 :

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 :

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

Conclusion

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.