1. Overview
Storage is a critical part of any operating system, and we always need extra storage. We may mount storage volumes to an active system for various purposes, such as to run a backup or carry out a migration. When mounting storage volumes, we use either /mnt or /media directory. We use /media for temporary storage like a flash drive and /mnt generally for long-term storage. In order to automate this mounting process, we can use a filesystem table, also known as the fstab file.
In this tutorial, let’s learn more about the fstab file and how we can use it to allow users to read and write to a partition.
2. What Is the fstab File?
The filesystem table, popularly known as fstab, is a system file in Linux. It automates the mounting of a storage volume and configures what permissions system users can have when accessing a storage volume or partition. Let’s take a USB device, for instance. Their plug-and-play feature completely abstracts the process of mounting it.
Before plug and play, each time the system is booted, the system administrator had to manually mount each volume or filesystem to a specific file location using the mount command.
So, fstab was a perfect alternative as it enabled the administrator to automatically mount filesystems. It uses a specific order and assigns defined permissions to access the volume every time the system starts. It also saved the administrator from running into an emergency console when booting the system, including a failure to boot because of configuration errors.
3. Location of fstab and Its Contents
The fstab file is located at /etc/fstab on most Linux distributions. It also requires root privileges in order to be able to add an entry to it or edit existing entries.
Each row or entry we add to the fstab file represents a storage volume. Each row must contain all the six fields with their order as specified in the fstab, either as default values or select options based on the field. This is what the fstab file looks like when we cat its content:
$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda5 during installation
PARTUUID=3210473s-d29c-3b1f-0c37-d105e80b22c4 /boot/efi vfat umask=0077 0 0
UUID=acc0cd4c-29ca-44c9-9dbe-f5dc8acb9c96 / ext4 errors=remount-ro 0 1
/swapfile none swap sw 0 0
With that said, let’s look at the available fields and their descriptions:
3.1. The file system Field
The file system field is also known as the device and is used to identify the device being mounted. It contains information about a local or remote filesystem that should be mounted.
The easiest way to add a storage volume is using the device location. Therefore, we need to know where it’s located. To do that, we use the lsblk command. For this tutorial, we’ll use a USB device as our storage volume.
We can use lsblk and grep for sdc in order to get a more targeted response for the attached storage volumes:
$ lsblk | grep sdc
sdc 8:32 1 28.7G 0 disk
└─sdc1 8:33 1 28.7G 0 part /media/ssensalo/PROVLX64.OFThe device location changes once the device is rebooted. This subsequently makes the mount storage rule for that device invalid.
Preferably, we can use the UUID (Universally Unique Identifier) or PARTUUID as it’s unique to each device or partition, respectively, and most importantly, it’s static. Still using lsblk, we can get the UUID of our USB device:
$ lsblk -d -fs /dev/sdc1
NAME FSTYPE LABEL UUID MOUNTPOINT
sdc1 vfat PROVLX64.OF 6C0B-3BB0 /media/ssensalo/PROWe can see that the USB has a UUID of 6C0B-3BB0.
3.2. The mount point Field
The mount point field points to the location where we want the filesystem to be mounted.
Before we automate the mounting process, we need to create a mountpoint for the storage volume or make sure it has one. Unless the storage volume we’re referring to is swap, then we use none.
Let’s check if our storage volume has a mountpoint:
$ mount | grep sdc
/dev/sdc1 on /media/ssensalo/PROVLX64.OF type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
The USB device mountpoint is /media/ssensalo/PROVLX64.OF
3.3. The <type> Field
The type field specifies the filesystem type of the storage volume. For our case, storage volume sdc is of vfat format. We saw that in the output when getting the UUID.
3.4. The <options> Field
The options field offers a list of mount options used when mounting a filesystem.
Generally, we use the defaults value for this field. But to have more fine-grained control over users that access a storage volume, we can specify options. These are some of the common options:
- rw/ro: defines the read-write privileges to a filesystem or partition. ro for read-only and rw for read-write
- suid: setuid programs and their user IDs
- exec/noexec: determines if the storage volume can execute scripts or binaries
- auto/noauto: we can use this to enable automatic mounting of the storage volume or not when the system boots
- nouser/user: gives system users mounting privileges
- async: performs I/O tasks asynchronously on the partition or filesystem
- nofail: prevents boot errors for the missing storage volume
Specifying options override the setting for defaults. These are the options available in defaults: rw, suid, dev, exec, auto, nouser, async.
3.5. The <dump> Field
The dump field specifies if the storage volume should be backed up or dumped. Its value can be either 0 or 1. Usually, we set the dump field to 0.
3.6. The <pass> Field
The pass field determines the order of filesystem integrity checking.
When we have issues with our filesystem, and it halts unexpectedly, the fsck (filesystem checker) needs to run. It basically runs in a particular order on boot. We can use this field to specify which partitions should be checked and in what order.
4. Read and Write to a Partition With the fstab File
For various reasons, we may need to restrict access to a partition. Say we’re creating a company backup partition and don’t want users to be able to edit contents on that partition. We can use the fstab file to set rw privileges to a partition using the options field.
Let’s add an entry to the fstab file that mounts a partition with read-write permission:
# <file system> <mount point> <type> <options> <dump> <pass>
PARTUUID=0bb0s2d0-e78a-45ed-9dbe-d6ec8acb9c96 /mnt/storage1 ext4 defaults 0 0As shown in the code snippet above, the defaults option consists of rw permissions and can be used to provide users with all the major privileges needed to utilize the contents of a partition. To override this behavior, we can use the ro option:
# <file system> <mount point> <type> <options> <dump> <pass>
PARTUUID=0bb0s2d0-e78a-45ed-9dbe-d6ec8acb9c96 /mnt/storage1 ext4 defaults,ro 0 0
This entry provides read-only access to users that access that partition.
As we’ve discussed previously, we can ensure the storage volume location remains static on system boot-up using UUID or PARTUUID. Therefore, we can mount windows NTFS volumes to Linux using the fstab and set read-write permissions to them.
Let’s look at how we can add no automatic mount, read-write permissions on Linux to provide users access to a Windows partition:
# <file system> <mount point> <type> <options> <dump> <pass>
PARTUUID=ed06610-92a2-d820-15c5-b990as2144bd /mnt/windowsvol1 ntfs noauto,rw,users,permissions 0 0The line in the code snippet above enables users to access a Windows partition with read-write privileges.
5. How to Test the fstab File
It’s very important to make sure that the fstab file has no errors. We can test the fstab file using the mount command:
$ sudo mount -aThis automatically mounts all storage volumes recently added to the fstab file. We may not detect all errors within the fstab file with this command. It’s just one more check.
So it’s always good to visually check the file and confirm that we’ve defined all the fields correctly and in the correct order.
6. Conclusion
In this article, we looked at the /etc/fstab Linux system file, its contents, and how they are defined in detail.
We also discussed how the fstab file can be used for enabling read-write permissions to a partition and some cases when this is needed.
Lastly, we looked at ways to test the fstab file to ensure we don’t run into errors on system boot.