Everything you never wanted to know about the /etc/fstab File

Introduction

Mounting of filesystems during the startup process is managed by the /etc/fstab configuration file. An easy way to remember that is that fstab stands for “filesystem table,” and it is a list of filesystems that are to be mounted, their designated mount points, and any options that might be needed for specific filesystems.

The term to “mount” a filesystem in Linux refers back to the early days of computing when a reel of tape or removable disk pack would need to be physically mounted on an appropriate drive device. After being physically placed on the drive, the filesystem on the disk pack would be logically “mounted” by the operator to make the contents available for access by the OS, application programs, and users.

In Linux ( and Unix) a mount point is simply an empty directory, like any other, that is created as part of the root filesystem. So the home filesystem, for example, is mounted on the directory /home. Filesystems can be mounted at mount points on non-root filesystems in the directory tree, but this is less common.

The Linux root filesystem is mounted as the root directory (/) very early in the boot sequence. Other filesystems are mounted later, by the Linux startup programs, either rc under SystemV or by systemd in newer Linux releases.

If you’re not already familiar with Linux filesystems, directory trees, and some of the terms I’ve already used here, you should read my article, An Introduction to Linux Filesystems as it covers these concepts. I’ll wait.

About the Term, “Filesystem”

Before proceeding, let’s define the three meanings of the word “filesystem.” Note that while attempting to conform to standard “official” meanings, my intent is to define the term based on its usages.

1. The entire Linux directory structure starting at the top (/) root directory.
2. A specific type of data storage format, such as EXT3, EXT4, BtrFS, XFS, and so on. Linux supports almost 100 types of filesystems, including some very old ones as well as some of the newest. Each of these filesystem types uses its own metadata structures to define how the data is stored and accessed.
3. A partition or logical volume formatted with a specific type of filesystem that can be mounted on a specified mount point on a Linux filesystem.

You can usually determine which meaning is in use in a document or conversation by the context.

Data structure

The structure of the data that defines each filesystem in /etc/fstab is fairly simple on the surface. The fstab file contains one line for each filesystem that needs to be mounted. Each configuration line consists of six fields separated by white space, spaces or tabs.

1. Filesystem identifier — This can be a UUID, a label, or a device file. I’ll describe each of these in a bit more detail as we encounter them.
2. Mount point — This is the location on the filesystem directory tree on which the filesystem is mounted.
3. Filesystem type — The type of filesystem being mounted, such as EXT4, XFS, or BtrFS.
4. Options — filesystems can be mounted with a number of options that can be used to modify the behavior of the mounted filesystem.
5. Backup — This field contains a value of 0 or 1. When set to 1, it indicates that dump, an old backup program, will be used to perform a dump, i.e., backup, of the filesystem. Although this is still a viable backup solution and many modern distros install it by default, it’s seldom used even though this field is usually set to 1 for EXT filesystems.
6. Check order — During Linux startup, all filesystems are checked for consistency before being mounted. Some filesystems, such as root, must be mounted before others. This field contains a numeric value that indicates the sequence in which the checks occur. The root filesystem must be checked and mounted first so it has a value of 1. Other traditional filesystems in the Linux filesystem hierarchy can mostly be performed in parallel so have a value of 2. Additional filesystems may have higher values such as 3 or higher depending upon the number of layers in the structure. A value of 0 indicates the filesystem should not be checked.

A typical entry in fstab looks like this.

UUID=489de0f8-5c6e-46d3-be32-85b534a41c0c /boot ext4 defaults 1 2

Figure 1 shows a breakdown of the fields in that entry that will help clarify the structure.

Figure 1: A typical entry in the /etc/fstab file.

Regardless of how complex an entry looks, it will always break down into these six fields. The options field may just contain the entry, “defaults”, or a list of comma-separated options.

A Simple fstab File

The fstab file is created during the Linux installation procedure and contains entries for the filesystems created at that time. Distributions that use the BtrFS filesystem, such as Linux Mint and Fedora 43 and later, OpenSUSE, and Ubuntu, generally create an fstab that looks similar to Figure 2. This example is for a new installation of Fedora 43 Xfce.

The UUID is a Universal Unique IDentifier created for each filesystem that is created using algorithms that generate a 128-bit number, often incorporating random values, timestamps, and hardware information to ensure uniqueness. This process typically occurs when a disk partition is formatted, and the UUID is assigned to help identify the partition reliably across different systems. Other identifiers such as labels and device names may be the same across multiple systems.

#####################################################################################
#
# /etc/fstab
# Created by anaconda on Thu Oct 30 13:47:07 2025
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
UUID=937c8d43-a026-4aeb-95c1-78120963467d /     btrfs subvol=root,compress=zstd:1 0 0
UUID=489de0f8-5c6e-46d3-be32-85b534a41c0c /boot ext4 defaults 1 2
UUID=937c8d43-a026-4aeb-95c1-78120963467d /home btrfs subvol=home,compress=zstd:1 0 0

Figure 2: A simple /etc/fstab from a Fedora 43 system with BtrFS.

In this example from one of my Linux hosts, three devices are specified using their UUIDs. The /boot filesystem uses an EXT4 filesystem because booting from BtrFS is not supported. The /boot partition can also be formatted another compatible file system. The problem is that GRUB does not support Btrfs snapshots. Using a separate /boot partition helps avoid issues with booting and kernel management.

The /boot EXT4 filesystem options field in Figure 2 contains the word, “defaults”, which means that it’s mounted with typical defaults for an EXT4 filesystem. The options and defaults are different for different filesystems. For example, the BtrFS filesystems have subvolume options that aren’t required for EXT4 and some other filesystems.

The man page for ext4 (man 5 ext4) contains a list of mount options for the EXT4 filesystem and the man page for BtrFS (man 5 btrfs) contains mount options for the BtrFS filesystem. Both of those pages have a wealth of additional information as well as pointers to even more.

The other two devices are BtrFS subvolumes of the same device. You can tell by the fact that the UUIDs are identical, and the subvolume names are in the options.

A Complex fstab File

My primary workstation has a much more complex /etc/fstab file. This is partly because the default was EXT4 when I initially installed Fedora on my first primary workstation, and because Fedora 43 doesn’t automatically convert EXT filesystems to BtrFS when upgrading from Fedora 42. I never saw the need to change to BtrFS “just because it was there.” I reinstalled the system completely in September, 2020 to replace 3 or 4 old hard drives — at least one of which was showing its age with SMART errors — with a pair of m.2 SSDs. I looked at using BtrFS at that time but found no compelling reason to do so.

In Figure 3 you see the fstab file for a system that has grown after the initial installation through the addition of more filesystems for various reasons. You can see the comments describing the various sections.

#############################################################################################
#
# /etc/fstab
# Created by anaconda on Thu Sep 10 11:12:33 2020
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
/dev/mapper/vg01-root                           /             ext4    defaults        1 1
UUID=73b04be9-ff03-4583-877a-9b6e556eecb5       /boot         ext4    defaults        1 2
UUID=1AE1-6B0D                       /boot/efi     vfat    umask=0077,shortname=winnt 0 2
/dev/mapper/vg02-home                           /home         ext4    defaults        1 2
/dev/mapper/vg01-tmp                            /tmp          ext4    defaults        1 2
/dev/mapper/vg01-usr                            /usr          ext4    defaults        1 2
/dev/mapper/vg01-var                            /var          ext4    defaults        1 2

#############################################################################################
# Added by David Both after initial installation.
#############################################################################################
# Storage for various stuff and virtual hard drive for VMs
/dev/mapper/vg03-Virtual        /Virtual        ext4    defaults        1 2
/dev/mapper/vg04-stuff          /stuff          ext4    defaults        1 2
/dev/mapper/vg04-VMArchives     /VMArchives     ext4    defaults        1 2
/dev/mapper/vg01-ansible  /home/dboth/development/ansible     ext4    defaults        1 3

#############################################################################################
# 2TB External HDD for Experiments writing book Using and Administering Linux
#############################################################################################
# LABEL=Experiments     /Experiments    ext4                  noauto,defaults         0 0

#############################################################################################
# SSHFS mounts (All one line in reality but wraps here)
#############################################################################################
dboth@bunkerhill:/var/Pictures /home/dboth/Pictures     fuse.sshfs allow_other,noexec,default_permissions,noauto,_netdev,reconnect,identityfile=/home/dboth/.ssh/id_rsa  0 0

#############################################################################################
# Backup drives
#############################################################################################
# Internal backup drive
LABEL=Backups           /media/Backups          ext4    noauto,defaults         0 0
# External backup devices
LABEL=MyBackups         /media/MyBackups        ext4    noauto,defaults         0 0
LABEL=TripBackups       /media/TripBackups      ext4    noauto,defaults         0 0

Figure 3: A more complex fstab file.

The original

This more complex environment allows us to explore some of the interesting aspects of the fstab file. Let’s start at the top. Figure 4 shows the original fstab file for this system when I reinstalled it in 2020. This section was created by the Anaconda installer during the installation of Fedora.

#############################################################################################
#
# /etc/fstab
# Created by anaconda on Thu Sep 10 11:12:33 2020
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
/dev/mapper/vg01-root                           /             ext4    defaults        1 1
UUID=73b04be9-ff03-4583-877a-9b6e556eecb5       /boot         ext4    defaults        1 2
UUID=1AE1-6B0D                       /boot/efi     vfat    umask=0077,shortname=winnt 0 2
/dev/mapper/vg02-home                           /home         ext4    defaults        1 2
/dev/mapper/vg01-tmp                            /tmp          ext4    defaults        1 2
/dev/mapper/vg01-usr                            /usr          ext4    defaults        1 2
/dev/mapper/vg01-var                            /var          ext4    defaults        1 2

Figure 4: The /boot/efi entry uses the VFAT filesystemial /etc/fstab generated when my primary workstation was reinstalled in 2020.

All of the filesystems in Figure 4 are LVM/EXT4 or just EXT4 on a raw disk partition, except for the /boot/efi filesystem which is VFAT — the filesystem from which the system must boot. You can also see that two of the filesystems, /boot and /boot/efi are identified by their UUID, while the remainder are identified by their device special files.

The /boot filesystem is EXT4 on a raw disk partition. The rest of the EXT4 filesystems use LVM in two volume groups (VG). During the installation, I renamed these from the clunky original volume group names to VG01 and VG02. The LVM volume device special files are all located in the /delaterv/mapper directory. The root ( / ) filesystem check sequence is 1 because it must be mounted first and everything else mounted to mount points on it. The rest have check values of 2.

Filesystems I added

Figure 5 shows the fstab entries for filesystems that I added after the initial Fedora installation. These filesystems already existed prior to the reinstallation of Fedora so I created the mount points and added these entries immediately after that reinstallation.

These are all EXT4 filesystems on LVM.

#############################################################################################
# Added by David Both after initial installation.
#############################################################################################
# Storage for various stuff and virtual hard drive for VMs
/dev/mapper/vg03-Virtual        /Virtual        ext4    defaults        1 2
/dev/mapper/vg04-stuff          /stuff          ext4    defaults        1 2
/dev/mapper/vg04-VMArchives     /VMArchives     ext4    defaults        1 2
/dev/mapper/vg01-ansible  /home/dboth/development/ansible     ext4    defaults        1 3

Figure 5: I added these filesystems to my fstab after the initial installation.

Three of the filesystems in Figure 5 have check values of 2, so fsck checks them after the root filesystem has been checked and mounted. Because the ansible filesystem is mounted on the /home/dboth/development/ansible mount point, it should be checked after the /home filesystem so it ‘s check value is 3.

Mounting a remote filesystem with SSHFS

Figure 6 is very interesting because it contains an entry for an SSH filesystem on a remote host. I se it to share our digital pictures across all the systems in my home. The SSH Filesystem (SSHFS) is an excellent choice for remote access because it uses a standard SSH connection so requires no additional holes to be punched in the firewall on either host. It’s also quite easy to set up.

#############################################################################################
# SSHFS mounts (All one line in reality but wraps here)
#############################################################################################
dboth@bunkerhill:/var/Pictures /home/dboth/Pictures     fuse.sshfs allow_other,noexec,default_permissions,noauto,_netdev,reconnect,identityfile=/home/dboth/.ssh/id_rsa  0 0

Figure 6: This entry is a configuration for access to a remote filesystem using the SSH filesystem (SSHFS) in user space.

The filesystem entry in Figure 6 uses a standard URL to define the link to the remote filesystem. It logs in as dboth, to the remote host, bunkerhill, and the directory /var/Pictures. The local mountpoint is /home /dboth/Pictures.

There are a number of options listed in this entry but I won’t go into any detail on most of them as options vary amongst the many Linux filesystems. One thing to note is the noauto option, which means don’t mount the filesystem automatically on a boot or reboot.

Another notable option is the “identityfile” which specifies the SSH RSA key to use when making the connection. I had to create the RSA public/private keypair and then copy it to the bunkerhill host. You can read the details in my article, “How I use SSHFS to access remote filesystems.”

Note that the check value for this filesystem is 0. We don’t want the local host to run fsck on a remote filesystem because the remote host is responsible for that. Allowing the clients, the local hosts, to perform checks on could result in the very inconsistencies that the checks are intended to find and repair.

Backup devices

The last section in my fstab is for the backup devices on my primary workstation. Yes — I have three backup devices that I use with the rsbu backup script that I wrote. These entries also illustrate the use of labels for the device ID. These filesystems are all LVM/EXT4.

#############################################################################################
# Backup drives
#############################################################################################
# Internal backup drive
LABEL=Backups           /media/Backups          ext4    noauto,defaults         0 0
# External backup devices
LABEL=MyBackups         /media/MyBackups        ext4    noauto,defaults         0 0
LABEL=TripBackups       /media/TripBackups      ext4    noauto,defaults         0 0

Figure 7: This section contains the fstab entries for my backup drives.

One of my three backup devices is an internal 4TB HDD on my workstation. I used the e2label command to give it the “Backups” label, and I use that as its identifier in the fstab. It’s always there, and it always has the latest backup of my files. But it’s not portable.

The second backup in the list uses the label “MyBackups”. In fact, I have four 4TB HDDs with this label. I rotate them on a strict schedule and take the most recent to my safe deposit box. Using the same label on all four makes writing the backup script much easier. This gives me a set of four external USB HDDs to rotate through my off-site safe storage. This is a perfect use case for using labels as the device identifier.

The last entry in this section is for another 4TB HDD that I make a backup to just before I go on a trip. I take this drive with me when I go on trips, to ensure I always have the latest files with me. If the house is destroyed by some form of disaster, this drive always has the latest when I’m traveling.

The noauto option for all of these devices indicates that they’re not to be mounted at startup.

Conclusions

The /etc/fstab file is less complex than it looks at first glance. In addition to its more mundane functions, I’ve set up some interesting use cases.

I use it to access a remote host via the SSH filesystem (SSHFS). This is a secure and simple way to use SSH without the need to open additional ports through the firewall. I also use it as part of my configuration for multiple backup devices, including one to use when traveling.

There is a lot to know about the fstab file, but it can be used to good advantage. Even though systemd is changing many things, including the fstab file itself, it’s still the place to go for managing filesystem mounts.