Objective
Learn how to take advantage of the autofs daemon to automount devices and remote shares.
Requirements
- Root privileges to install autofs package and edit configuration files
Difficulty
EASY
Introduction
Manually mounting and unmounting devices such as external USB drives or remote NFS or Samba shares can be tedious tasks to perform when administering a machine. The autofs daemon can help us automatically mounting a filesystem when needed and umounting it after a specified period of time. In this tutorial we will see the basic concept related to the automounter, and how to configure it.
Autofs installation
The first thing to do, it’s to install the autofs package. It is available in the official CentOS7 and Rhel7 repositories, therefore we just have to use the yum package manager to obtain it:
$ sudo yum install autofs
Next step is to start the autofs daemon, and enable it at boot:
$ sudo systemctl enable --now autofs
The autofs daemon configuration
The autofs daemon is configured by manipulating some files, each with its own specific purpose. What we basically have to do is to provide some instructions to the daemon, to let it know how it should manage mountpoints and devices (this is what we call a map), and optionally a set of options which can be used to alter its behavior. Let’s see what those configuration files are and what it is their role.
The /etc/sysconfig/autofs file
The /etc/sysconfig/autofs file is the main configuration file for the autofs daemon and contains its global settings. This is the file content in a default installation of CentOS 7.5:
# # Init syatem options # # If the kernel supports using the autofs miscellanous device # and you wish to use it you must set this configuration option # to "yes" otherwise it will not be used. # USE_MISC_DEVICE="yes" # # Use OPTIONS to add automount(8) command line options that # will be used when the daemon is started. # #OPTIONS="" #
We can modify the behavior of the daemon by removing the comment at Line 13 and passing command line arguments in the form of a string, as the value of the OPTIONS variable.
Let’s make an example: say we want to change the default time interval after which the daemon should automatically unmount a filesystem: the default value is 300 seconds or 5 minutes. By reading the autofs manual (automount(8)), we can see that to change this parameter we should use the --timeout option, which takes as parameter, the interval of time expressed in seconds:
-t , --timeout
Set the global minimum timeout, in seconds, until directories
are unmounted. The default is 10 minutes. Setting the timeout to
zero disables umounts completely. The internal program default
is 10 minutes, but the default installed configuration overrides
this and sets the timeout to 5 minutes to be consistent with
earlier autofs releases.
Say for example we want to change the default unmount timeout to 10 minutes, that’s how we should change the /etc/sysconfig/autofs file:
OPTIONS="--timeout=600"
After saving the changes we should restart the daemon for the new configuration to take effect. We can see how the new timeout option has been adopted by checking the daemon status with systemctl:
$ systemctl status autofs
autofs.service - Automounts filesystems on demand
[...]
CGroup: /system.slice/autofs.service
└─6452 /usr/sbin/automount --timeout=600 --foreground --dont-check-daemon
[...]
The /etc/auto.master file
The auto.master file is very important, since it contains the automounter master map. Each map associates a mountpoint with a configuration file where the filesystems to mount are described, so basically describes another map. A map is created using the following syntax:
<mountpoint> <configuration file> <options>
The configuration tells the daemon that the given mountpoint is managed by maps set in the given configuration file, applying the provided options, which can override the global ones (this can be useful, for example, to provide a specific unmount timeout for each mountpoint). Let’s see a concrete example: if we take a look at Line 7 of the file, we can see the following map:
/misc /etc/auto.misc
This configuration specifies that the /misc mountpoint is interested by mappings described in the /etc/auto.misc file. Let’s see how those maps are configured by taking a look at it.
The /etc/auto.misc file
As we saw in the /etc/auto.master file, the /misc mountpoint is associated with the /etc/auto.misc configuration file. Now we are going to examine it, in order to understand how a map for a device is defined. This is the default content of the file:
# # This is an automounter map and it has the following format # key [ -mount-options-separated-by-comma ] location # Details may be found in the autofs(5) manpage cd -fstype=iso9660,ro,nosuid,nodev :/dev/cdrom [...]
The syntax used for the configuration is the following:
<key> <mount options> <filesystem>
The first thing we have to specify is the key. The value of this parameter, will be used, in the case of indirect maps (we will different type of maps in a minute) as the name of the subdirectory which will be created if not exists, under the main mountpoint, which in this case is /misc. The /dev/cdrom device, will therefore be automatically mounted on the /misc/cd directory.
The second element to provide is the list of the mount options which should be applied: in this example the -fstype option has been used to specify the filesystem type, along with the ro, nosuid and nodev.
Finally we must specify the location of the filesystem. In this case, since it is a local path, it must be prefixed with a : (colon) character.
In the case of a remote NFS share, we would have write 192.168.1.39:/srv/nfs_share instead, where 192.168.1.39 is the address of the remote machine (the hostname can also be used), and /srv/nfs_share is the path of the shared directory on it.
When referring to a samba share, we should have instead provided -fstype=cifs as an option, specifying the remote machine ip and the path of the shared directory in the following format:
://192.168.1.39/srv/samba_share
Indirect, direct and hosts maps
We mentioned an indirect map before, let’s see now in detail, the different types of maps. There are three kinds of map we can use: direct, indirect and hosts maps: an example of indirect map is what we just seen in the /etc/auto.master file, for the /misc mountpoint.
A map is called indirect, because the key parameter specified in the configuration file (/etc/auto.misc in this case) associated with the mountpoint (/etc/misc), will be used as the name of the directory relative to that mountpoint where the filesystem (:/dev/cdrom in our example) will be mounted.
A direct map, is always specified with the following syntax in the auto.master file:
/- /etc/auto.misc
When /- is used as a mountpoint in a map, that means we are using a direct map. In this case, the key element of the syntax used in the configuration file associated with the mountpoint, must be an absolute path. Therefore, in the example above, we would have write:
/cd -fstype=iso9660,ro,nosuid,nodev :/dev/cdrom
Finally we can find an host map example in the /etc/auto.master file, on Line 13:
/net -hosts
Such a map is defined by default; how does it work? When an hosts map is specified, the automounter creates a subdirectory under the specified mountpoint (/net in this case) for each machines listed in the /etc/hosts which exports an NFS share. This is possible thanks to the /etc/auto.net script, which we will now examine. Each of the shared directories will be mounted by default with the nosuid and nodev options.
The /etc/auto.net and /etc/auto.smb scripts
There are two very useful scripts included in the autofs installation: /etc/auto.net and /etc/auto.smb. Those scripts are basically wrappers around, respectively, the showmount and smbclient programs, used to discover available NFS and samba shares. They will produce results a format which can be used by the automounter.
The /etc/auto.net script can be used to have an overview and to read NFS shares. We can invoke the script by specifying the hostname or the ip address of the server we want to search as argument:
$ sudo /etc/auto.net 192.168.1.39
Now, imagine that a share is found. The command will return an output similar to this:
/shared 192.168.1.39:/shared
This would mean that on the machine with ip 192.168.1.39, the /shared directory is shared via NFS. Based on hosts map we found in /etc/auto.master file we will be able to access the share at /net/192.168.1.39/shared. This is because, as we said before, when using an hosts map, for each machine in the /etc/hosts file exporting an NFS share, a subdirectory its created under /net.
The /etc/auto.smb works in a similar fashion. If we want the samba shares in our network to be automatically mounted by the automounter, just like happens for NFS shares, the first thing we have to do is to add this map in the /etc/auto.master file:
/cifs /etc/auto.smb
After the map is added, we should restart the daemon:
sudo systemctl restart autofs
At this point, thanks to the /etc/auto.smb script, for each machine exporting one or more smb share in our network, a directory will be created under /cifs. For example, imagine that on a machine with ip 192.168.122.32 we have a /srv/samba directory shared via samba. If we want to we verify it, we may run the /etc/auto.smb script against the ip of that machine. Here is the output:
$ /etc/auto.smb 192.168.122.32 -fstype=cifs,guest \ "/sambadir" "://192.168.122.32/sambadir"
As said before, the script is a wrapper around smbclient, and produces an output which can be used by the automounter. The shared directory will be available, in our local filesystem, inside the automatically created /cifs/192.168.122.32/ directory:
$ ls /cifs/192.168.122.32 sambadir
Lazy mounting and unmounting
To optimize the number of mountpoint created, the automounter uses a technique which is called lazy mounting. Instead of mounting a device as soon as it is available or discovered, it will wait until a user tries to access the filesytem: only then the mount operation is performed. The same happens for the unmounting process: a device is unmounted after a specified timeout automatically.