Permanent mounts with /etc/fstab and UUIDs

Why fstab matters

At boot, systemd reads /etc/fstab and mounts each line. It is one of the most important files on the server: a mistake in it can stop the system from booting to normal mode. So learn the format exactly, and always test before rebooting.

# /etc/fstab
# device                                   mount point  type  options   dump fsck
/dev/mapper/rhel-root                      /            xfs   defaults  0    0
UUID=8f1c0d2a-6b3e-4d7f-9a1b-2c3d4e5f6a7b  /boot        xfs   defaults  0    0
/dev/mapper/rhel-swap                      none         swap  defaults  0    0
UUID=5b2f3c1e-8d7a-4f0b-a9e1-3c6d2b8f9a10  /data        xfs   defaults  0    0
UUID=0e9c7d6b-1a2f-4c3d-8e5f-6a7b8c9d0e1f  /backups     ext4  defaults,nofail  0  2

1. Device: what to mount. Best as UUID=..., or LABEL=..., or an LVM path like /dev/mapper/vg-lv or /dev/vg/lv.
2. Mount point: the directory (must exist). For swap write none (or swap).
3. Type: xfs, ext4, swap, nfs and so on.
4. Options: defaults, or a comma list such as defaults,noexec or ro. nofail lets the boot continue if this device is missing.
5. Dump: 0 (old backup tool flag; leave 0).
6. fsck order: 0 = never check at boot (always for XFS, which checks itself), 1 = the root file system for ext4, 2 = other ext4 file systems.

Why UUIDs and not /dev/sdb1?

Disk names like /dev/sdb are given in the order the kernel finds disks at boot. Add a new disk or a USB stick, or change a controller, and yesterday's sdb may be today's sdc. Your fstab would then mount the wrong disk, or fail. A UUID belongs to the file system itself and never changes. LVM paths (/dev/vgdata/lvdata) are also stable, because LVM finds its volumes by their own IDs.

# blkid /dev/vdb1
/dev/vdb1: UUID="5b2f3c1e-8d7a-4f0b-a9e1-3c6d2b8f9a10" TYPE="xfs" PARTLABEL="data" PARTUUID="a1b2c3d4-..."
# lsblk -no UUID /dev/vdb1
5b2f3c1e-8d7a-4f0b-a9e1-3c6d2b8f9a10

The safe workflow

# mkdir -p /data
# echo "UUID=5b2f3c1e-8d7a-4f0b-a9e1-3c6d2b8f9a10 /data xfs defaults 0 0" >> /etc/fstab
# systemctl daemon-reload        # let systemd re-read fstab
# mount -a                       # mount everything in fstab that is not mounted yet
# findmnt --verify               # check fstab for errors
Success, no errors or warnings detected
# df -h /data
Filesystem      Size  Used Avail Use% Mounted on
/dev/vdb1       2.0G   47M  2.0G   3% /data

When it goes wrong anyway

If a bad fstab line points at a missing disk, the boot waits about 90 seconds and then drops to emergency mode, asking for the root password. Log in, run mount -o remount,rw / so you can edit, fix or comment out the line with vi, then systemctl daemon-reload and reboot. Adding nofail to non-critical lines (like a USB backup disk) avoids this situation.

Common mistakes

• Typos in the UUID. Copy it with blkid output or use a command like lsblk -no UUID /dev/vdb1 >> /etc/fstab and then fix the line in vim.
• A mount point directory that does not exist.
• Wrong type: writing ext4 for an XFS file system. mount -a will complain.
• Rebooting without running mount -a first. Always test.