Controlling the mounting of filesystems is a useful technique for managing Linux systems. The mounting configurations are mostly in the /etc/fstab file. In this post, we will discuss 2 common and useful techniques for controlling the filesystem mounting by playing with the /etc/fstab file: allowing non-root users to mount/unmount filesystems and avoiding mounting failures blocking the booting of Linux.
A brief introduction to /etc/fstab
Table of Contents
First, let’s take a brief look at the /etc/fstab file and the format. For more details, please check the fstab man page. If you are already familiar with fstab format, you can skip this part.
The fstab contains descriptive information about the file systems. Each filesystem in the system is described on a line with fields separated by tabs or spaces in the fstab file. Lines starting with ‘#’ are comments and blank lines are ignored.
Each line has 7 fields. The first field is
fs_spec which describes the block special device or remote filesystem to be mounted. The second field is
fs_file which describes the mount point for the filesystem. The third field is
fs_vfstype which describes the type of the filesystem. The fourth field
fs_mntops describes the mount options associated with the filesystem formatted as a comma separated list of options. The fifth field is
fs_freq which is used for these filesystems by the
dump command to determine which filesystems need to be dumped. And the sixth field
fs_passno is used by the
fsck program to determine the order in which filesystem checks are done at reboot time.
Overall, the line for representing a filesystem is formated as
fs_spec fs_file fs_vfstype fs_mntops fs_freq fs_passno
With the basic understand of the fstab, let’s go to the 2 techniques.
Allow non-root users to mount and unmount filesystems
Usually, only root user can mount/unmount filesystems. It will be useful to let normal users mount/umount some filesystems that are non-critical to the system and can be mounted/unmounted when the filesystems are needed without the help of system admins.
To make a filesystem such as an NFS filesystem
localhost:/ mountable by normal users, we can use the
user option as follows.
localhost:/ /mnt/netshare nfs noauto,user,rw,vers=3,proto=tcp,nolock,noacl,rw,suid,dev,exec,async 0 0
user in the
fs_mntops field enables normal users to mount and umount the filesystem. Another option that is used together with
user here is
noauto that makes it not automatically mount the filesystem during boot or
rw,suid,dev,exec,async are those as the default mount
defaults use default options: rw, suid, dev, exec, auto, nouser, and async.
The other options in the above example are those for the NFS filesystem.
Avoid mounting failures blocking Linux booting
One common problem that makes Linux fail to boot is the failure of mounting filesystems specified in the /etc/fstab file. Having to get to the fail to boot server and configure it is one of the things that lazy admins do not like. For non-critical filesystems of the system, mounting failures may be fine and the Linux system can boot without these filesystems. After the system boots, the admins can remotely re-configure/disable the filesystem without the need to go to the server room.
First, we add the
noauto option introduced in the above technique to make the non-critical filesystems not mounted during boot time.
As one option, you may mount the filesystem manually or by a crontab
@reboot job after Linux boots. For example,
@reboot mount /mnt/large-disk to mount /mnt/large-disk after booting.
The option to be added is
x-systemd.automount. One example is as follows.
UUID=DISK-UUID /mnt/large-disk ext4 noauto,x-systemd.automount,rw,suid,dev,exec,async 1 2
systemd will mount the ext4 filesystem to /mnt/large-disk at the first time /mnt/large-disk is accessed instead of at the system booting time.
One more note: you may add
nofail to the fstab entry. It is another useful option if the device specified in an entry may not exist during boot:
nofail Do not report errors for this device if it does not exist.