original in fr. Frédéric Raynal
fr to en Philippe Trbich and Emmanuel Bonnel
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 :
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).
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).
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
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 ;-)
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 :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.