fstab

As Mount and Umount showed, a manually run mount command is temporary — every manually mounted filesystem disappears when the system reboots. In practice, disks, network shares, and other devices need to mount automatically, with agreed-upon parameters, every time the system boots. Linux uses /etc/fstab (file system table) for exactly this: a central configuration file, read at boot via mount -a, that defines how and with what parameters each filesystem is mounted. The user-level restrictions covered in the next article, Disk Quotas, also often depend on mount parameters defined right here.

What You Will Learn

By the end of this article you will be able to:

• read and write the six-column format of /etc/fstab;
• explain why a UUID or label is more reliable than a device path (/dev/sdX);
• know the most commonly used mount options: defaults, noatime, nofail, ro;
• explain the purpose of the dump and fsck columns;
• safely test a new fstab entry before rebooting, with mount -a and findmnt --verify;
• know that a bad fstab entry can leave a system unable to boot, and how to fix that situation.

The fstab Format: Six Columns

Every line in /etc/fstab (other than blank lines and #-prefixed comments) describes one filesystem and consists of six columns, separated by spaces or tabs:

<device>  <mount point>  <fs type>  <options>  <dump>  <fsck order>

Example:

# <device>                                 <mount point>  <fs type>  <options>       <dump>  <fsck>
UUID=1b4e28ba-2fa1-11d2-883f-0016d3cca427  /              xfs        defaults        0       1
UUID=9c8e6f3a-1234-4a3b-9abc-0011223344ee  /home          ext4       defaults,noatime 0      2
LABEL=data                                 /mnt/data      ext4       defaults,nofail 0       2
/dev/sda2                                  swap           swap       defaults        0       0

Columns, in order:

1. device — a device path, a label (LABEL=...), or a UUID (UUID=...);
2. mount point — the directory the device should be mounted to (the word swap is used for swap);
3. fs type — the filesystem type (ext4, xfs, swap, nfs, and so on), matching the type used when it was created with mkfs;
4. options — mount options, comma-separated, with no spaces (defaults,noatime is correct, defaults, noatime is wrong);
5. dump — a flag for the dump backup tool (0 — ignore, 1 — back up);
6. fsck order — the order in which fsck runs at boot (0 — not checked, 1 — checked first, usually for /, 2 — checked next, for the remaining filesystems).

Why UUID or Label Instead of /dev/sdX

Names like /dev/sda, /dev/sdb depend on the order disks are detected — an order that isn't guaranteed to stay the same. Adding a new disk, plugging in a USB device, or even an ordinary reboot can change disk naming order. As a result, if fstab has a hardcoded path like /dev/sdb1, on the next boot that name might point to a different disk entirely, or not exist at all.

A UUID (universally unique identifier) and a label are tied to the disk itself, written as metadata when the filesystem is created — they stay the same regardless of which port the disk is connected to or in what order it was detected. This is why production systems almost always use a UUID or label.

Viewing UUIDs:

lsblk -f

or, if only the UUID is needed:

sudo blkid

Sample output:

/dev/sda1: UUID="1b4e28ba-2fa1-11d2-883f-0016d3cca427" TYPE="xfs" PARTUUID="..."
/dev/sda2: UUID="7f3c9e21-..." TYPE="swap"
/dev/sdb1: LABEL="data" UUID="9c8e6f3a-..." TYPE="ext4"

Setting a label uses a tool matching the filesystem, for example, for ext4:

sudo e2label /dev/sdb1 data

Commonly Used Mount Options

Multiple options are combined with commas:

UUID=9c8e6f3a-...  /mnt/data  ext4  defaults,noatime,nofail  0  2

mount -a: Applying and Testing fstab

To apply every fstab entry after editing the file, without rebooting the system:

sudo mount -a

mount -a reads every line in fstab and mounts whatever filesystem isn't mounted yet. If a line has a syntax error or an incorrect UUID, mount -a stops with an error message — catching the mistake before rebooting.

If the filesystem type or a mount option is written incorrectly, a typical error looks like:

mount: /mnt/data: wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or helper program, or other error.

findmnt --verify: a Deeper Check

mount -a only attempts to mount — it doesn't deeply validate the fstab format itself (for example, the number of columns, a duplicate mount point). findmnt --verify is built specifically for this:

findmnt --verify

Sample output, if everything is correct:

0 parse errors and 0 known filesystem checks

If there's an error, findmnt --verify shows exactly which line and why there's a problem — for example, a duplicate mount point, a nonexistent UUID, or an incorrect option name.

Practical Scenario: Checking an fstab Entry Before Rebooting

Problem. A new disk needs to be permanently mounted at /mnt/archive, but manually adding a fstab entry risks a typo — which could leave the system unable to boot on the next reboot.

Inspection (finding the UUID before adding the entry).

sudo blkid /dev/sdc1

/dev/sdc1: UUID="a1b2c3d4-e5f6-4789-90ab-cdef01234567" TYPE="ext4"

Action (adding the fstab entry).

echo 'UUID=a1b2c3d4-e5f6-4789-90ab-cdef01234567  /mnt/archive  ext4  defaults,nofail  0  2' | sudo tee -a /etc/fstab

Verification (before rebooting, in a safe environment).

sudo mkdir -p /mnt/archive
findmnt --verify
sudo mount -a

findmnt --verify catches syntax errors, while mount -a checks that the mount actually succeeds. If both pass without errors:

mount | grep /mnt/archive
df -hT /mnt/archive

Result. The entry is confirmed correct in mount point, UUID, and filesystem type, without needing a reboot.

Conclusion. Running mount -a and findmnt --verify together makes it possible to know in advance, without rebooting, that a new fstab entry won't cause a boot problem. Not skipping these two checks is the basic rule for making changes to fstab on a production server.

Fixing a System That Won't Boot Due to a Bad fstab Entry

If a server drops into an emergency shell after a reboot because of a bad fstab entry, the following steps are the usual fix:

1. Enter the emergency/rescue shell. On many distributions, a broken fstab automatically opens a maintenance shell asking for the root password (on systemd-based systems: "Give root password for maintenance").

2. Open the filesystem for writing, if it's read-only:

   mount -o remount,rw /
   

3. Find the problematic line in fstab and comment it out temporarily (by adding #):

   nano /etc/fstab
   

4. Check the remaining entries with findmnt --verify, then reboot:

   findmnt --verify
   reboot
   

5. Once the system boots successfully, re-add the problematic device with the correct UUID and the nofail option.

To prevent this kind of situation in the future, applying nofail as standard practice — especially for devices that aren't guaranteed to always be connected (an external disk, a network filesystem) — is recommended, since it lets the boot process continue even when that mount fails.

Common Mistakes

Leaving a Space Between Options

defaults, noatime (comma + space) can confuse the fstab parser and cause an unexpected error. The correct format has no spaces: defaults,noatime.

Forgetting nofail for Network Filesystems

If a network filesystem like NFS boots while the network isn't available yet, the whole boot process can stall without nofail. This is covered in more depth in NFS and autofs.

Rebooting Directly Without Checking the Entry First

Rebooting immediately, without first checking with mount -a and findmnt --verify, is the most common and most costly mistake in a production environment. Both checks take only a few seconds but prevent a broken boot.

Exercises

1. In a disposable VM, create an extra partition, find its UUID with blkid, and add it to fstab with the nofail option.
2. Deliberately write an incorrect UUID into fstab and observe how findmnt --verify and mount -a report the error (without rebooting!).
3. Fix the bad entry and confirm the problem is gone with mount -a.
4. Compare, using stat, whether access time updates on a filesystem mounted with noatime versus one mounted without it.

Verification criterion: given a proposed new fstab entry, you should be able to state the two commands that verify it's safe before a reboot, and what each one checks that the other doesn't.

Summary

/etc/fstab stores mount configuration in a six-column format and applies it automatically at boot. Using a UUID or label protects against disk naming order changing, and nofail ensures boot doesn't stall for a device that might not always be present. Checking any change with mount -a and findmnt --verify before rebooting is the most reliable way to prevent a system from failing to boot due to a bad entry. The next article, NFS and autofs, shows how to apply this same fstab knowledge to network-mounted filesystems.

References

• man7.org: fstab(5)
• man7.org: mount(8)
• man7.org: findmnt(8)
• man7.org: blkid(8)
• Red Hat: The /etc/fstab file
• Ubuntu Server Guide: Mounting file systems