Linux, the operating system LIN · 06 · 04

fstab and boot mounts

/etc/fstab records which filesystems to mount at boot: device, mount point, fstype, options, dump, and pass. Use UUID not /dev names — device names shift when disks are added. A bad fstab line drops the system to emergency mode; nofail prevents this for non-critical mounts.

LIN Middle ◷ 22 min

Level

FoundationsJuniorMiddleSenior

You have mounted /dev/sdb1 at /data and everything works. You reboot the server — and /data is gone. Of course: mount changes only survive until the next reboot. /etc/fstab is the file that makes mounts permanent.

It is also the file that, when you get one line wrong — a typo in the UUID, a missing mount point directory, a network filesystem that is not reachable at boot — drops the entire system into emergency mode at the next boot, with a message asking for the root password to fix it. On a remote server with no out-of-band access, that is a hard lock-out. Understanding fstab means understanding both how to configure it correctly and how to recover when it goes wrong.

Goal

After this lesson you can write a correct /etc/fstab entry with all six fields, explain why UUIDs are safer than /dev/sda names, use nofail to protect non-critical mounts, test an fstab entry without rebooting, and recover a system that boots to emergency mode due to a bad fstab line.

/etc/fstab has exactly six fields per line, whitespace-separated. Each line is one mount.

cat /etc/fstab
# <device>                                <mountpoint>  <fstype>  <options>         <dump> <pass>
UUID=e5f6a7b8-c9d0-1234-5678-abcdef012345 /             ext4      errors=remount-ro 0      1
UUID=a1b2c3d4-5678-9abc-def0-123456789abc /boot         ext4      defaults          0      2
UUID=C7A2-1234                            /boot/efi     vfat      umask=0077        0      1
UUID=9f8e7d6c-ba98-7654-3210-fedcba987654 /data         xfs       defaults,noatime  0      2
tmpfs                                     /tmp          tmpfs     defaults,size=2G  0      0

The six fields:

device — what to mount: UUID, LABEL, or path (/dev/sda3). UUID is strongly preferred.
mountpoint — where in the tree. Must be an existing directory at mount time.
fstype — ext4, xfs, btrfs, vfat, tmpfs, nfs, etc.
options — comma-separated mount options. defaults = rw,suid,dev,exec,auto,nouser,async.
dump — 0 or 1. Controls the legacy dump backup tool. Almost always 0 on modern systems.
pass — 0 = skip fsck at boot; 1 = check first (root only); 2 = check after root. Root should be 1, other local filesystems 2, network/tmpfs always 0.

# Test all fstab entries without rebooting
sudo mount -a
# Mounts everything in fstab that is not already mounted
# If this returns an error, fix fstab NOW before rebooting

# Mount a single fstab entry by mountpoint
sudo mount /data
# mount looks up /data in fstab and applies the recorded options

Use UUID, not /dev/sda names — device names are not stable. The kernel assigns /dev/sda, /dev/sdb, etc. based on probe order at boot. Add a second disk, change a SATA port, or swap a drive bay, and the ordering can change. /dev/sda becomes /dev/sdb. Your root filesystem fstab entry now points at the wrong device.

# Get the UUID of a filesystem
lsblk -f /dev/sdb1
# NAME   FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
# sdb1   ext4   1.0         9f8e7d6c-ba98-7654-3210-fedcba987654  890G     5% /data

# Alternative
sudo blkid /dev/sdb1
# /dev/sdb1: UUID="9f8e7d6c-ba98-7654-3210-fedcba987654" BLOCK_SIZE="4096" TYPE="ext4"

# LABEL is another stable identifier (set at mkfs or with tune2fs)
sudo tune2fs -L mydata /dev/sdb1
sudo blkid /dev/sdb1
# /dev/sdb1: LABEL="mydata" UUID="9f8e7d6c-..." TYPE="ext4"

# Use LABEL in fstab:
# LABEL=mydata  /data  ext4  defaults,noatime  0  2

# UUID vs LABEL trade-off:
# UUID: always unique (assigned at mkfs), cannot collide, survives label rename
# LABEL: human-readable, but TWO filesystems can have the same label (undefined behavior)
# Recommendation: always use UUID in fstab unless you have a specific reason for LABEL

The UUID is written into the filesystem’s superblock at mkfs time and does not change unless you reformat. When you replace a failed disk and restore from backup, the new filesystem gets a new UUID — remember to update fstab.

nofail prevents a missing or failed mount from dropping the system to emergency mode. Without it, any fstab entry that fails to mount at boot causes systemd to abort the boot sequence and present the emergency shell.

# WITHOUT nofail: if /dev/sdc1 is missing (e.g. USB drive not plugged in),
# boot halts with:
# [FAILED] Failed to mount /backup.
# See 'journalctl -xe' for details.
# [!!!!!!] Dependency failed for Local File Systems.
# You are in emergency mode.

# WITH nofail: missing device is silently skipped, boot continues
# /etc/fstab entry:
UUID=abc123...  /backup  ext4  defaults,nofail  0  2

# For network filesystems, combine with _netdev (tells systemd to wait for network)
# and nofail (skip if network is down at boot):
//nas.local/share  /mnt/nas  cifs  credentials=/etc/samba/creds,_netdev,nofail  0  0

# For external/removable drives: always use nofail
UUID=def456...  /mnt/external  ext4  defaults,nofail,x-systemd.automount  0  2
# x-systemd.automount: mount on first access, not at boot (lazy mount)

Use nofail for: external drives, USB devices, network shares, secondary data disks. Do NOT use nofail for the root filesystem or /boot — those are critical and you want to know immediately if they fail.

A bad fstab line is a classic way to lock yourself out at boot. The scenario: you add an entry for a new disk, make a typo in the UUID or forget to create the mount point directory, save fstab, and reboot. systemd tries to mount every entry; the bad one fails; the boot halts.

# The emergency mode screen looks like:
# You are in emergency mode. After logging in, type "journalctl -xb" to view
# system logs, "systemctl reboot" to reboot, "systemctl default" or ^D to
# try again to boot into default mode.
# Give root password for maintenance
# (or press Enter for automatic login):

# RECOVERY STEPS from the emergency shell:

# Step 1: remount root read-write (it is mounted read-only in emergency mode)
mount -o remount,rw /

# Step 2: identify the bad line
cat /etc/fstab
# Find the line you just added — the one with the typo or wrong UUID

# Step 3: fix or comment out the bad line
nano /etc/fstab
# Comment out the offending line with #:
# #UUID=WRONGUUID  /data  ext4  defaults  0  2

# Step 4: verify the fix before rebooting
mount -a
# If this succeeds (or fails only on the commented-out line), you are safe

# Step 5: reboot
systemctl reboot

# PREVENTION: always test with 'mount -a' before rebooting after any fstab edit
# If mount -a reports an error, fix it immediately
sudo mount -a

On a remote server where emergency mode is inaccessible (no console, no IPMI), a bad fstab is a hard outage requiring cloud provider rescue mode or serial console access. This is why mount -a before reboot is not optional hygiene — it is a production safety gate.

systemd converts fstab entries to mount units at boot. Understanding this explains some behaviors that seem mysterious.

# systemd generates mount units from fstab at boot via systemd-fstab-generator
# You can see the generated units:
systemctl list-units --type=mount
# UNIT                     LOAD   ACTIVE SUB     DESCRIPTION
# boot.mount               loaded active mounted /boot
# boot-efi.mount           loaded active mounted /boot/efi
# data.mount               loaded active mounted /data
# mnt-nas.mount            loaded active mounted /mnt/nas

# Inspect a generated mount unit
systemctl cat data.mount
# # Automatically generated by systemd-fstab-generator
# [Unit]
# SourcePath=/etc/fstab
# Documentation=man:fstab(5) man:systemd-fstab-generator(8)
# Before=local-fs.target
#
# [Mount]
# Where=/data
# What=/dev/disk/by-uuid/9f8e7d6c-...
# Type=xfs
# Options=defaults,noatime

# You can also write mount units directly (without fstab) — useful in containers
# File: /etc/systemd/system/data.mount
# [Unit]
# Description=Data volume
# [Mount]
# What=/dev/disk/by-uuid/9f8e7d6c-...
# Where=/data
# Type=xfs
# Options=noatime
# [Install]
# WantedBy=local-fs.target

# Check mount status via systemd
systemctl status data.mount
# ● data.mount - /data
#      Loaded: loaded (/etc/fstab; generated)
#      Active: active (mounted) since ...
#       Where: /data
#        What: /dev/sdb1

The systemd-fstab-generator runs before the regular boot sequence and translates fstab lines into transient mount units. This is why systemctl daemon-reload is not needed after editing fstab — the generator runs fresh on each boot. However, to apply fstab changes without rebooting, use mount -a (for new mounts) or systemctl daemon-reload followed by systemctl restart <mountpoint>.mount.

At boot, systemd-fstab-generator reads /etc/fstab and produces mount units. systemd activates them in dependency order. A failure in a non-nofail entry halts the sequence and drops to emergency mode.

Worked example

Adding a second data disk permanently — the correct, safe procedure.

# Context: new 2 TiB disk /dev/sdb, already partitioned (/dev/sdb1) and formatted (xfs).
# Goal: mount at /data on every boot.

# Step 1: get the UUID (never use /dev/sdb1 in fstab)
sudo blkid /dev/sdb1
# /dev/sdb1: UUID="9f8e7d6c-ba98-7654-3210-fedcba987654" TYPE="xfs"

# Step 2: create the mount point
sudo mkdir -p /data

# Step 3: add the fstab entry (edit as root)
sudo nano /etc/fstab
# Add this line:
# UUID=9f8e7d6c-ba98-7654-3210-fedcba987654  /data  xfs  defaults,noatime,nofail  0  2

# Step 4: TEST before rebooting — this is mandatory
sudo mount -a
# If silent: success. If error: fix fstab NOW.

# Step 5: verify it mounted correctly
findmnt /data
# TARGET SOURCE    FSTYPE OPTIONS
# /data  /dev/sdb1 xfs    rw,noatime,attr2,inode64,logbufs=8,logbsize=32k,nofail,noquota

df -h /data
# Filesystem      Size  Used Avail Use% Mounted on
# /dev/sdb1       2.0T   25G  2.0T   2% /data

# Step 6: now it is safe to reboot
# The disk will mount automatically at every subsequent boot.

# Bonus: if you later replace the disk and restore from backup, remember to update
# the UUID in fstab after formatting the new disk:
# sudo blkid /dev/sdb1   <- new UUID after mkfs
# sudo nano /etc/fstab   <- update the UUID
# sudo mount -a          <- test again

▸Common mistake

The most dangerous fstab mistake on a remote server: adding a _netdev NFS or CIFS mount without nofail. If the network share is unreachable at boot (NAS is down, DNS fails, network interface is slow), systemd waits for a long timeout then drops to emergency mode. With no console access, the server is unreachable. The fix before it happens: always pair _netdev with nofail for any network filesystem. The fix after it happens: use your cloud provider’s rescue mode or out-of-band management (IPMI/iDRAC) to boot into a recovery environment, edit /etc/fstab, and reboot.

▸Why this works

Why does /dev/sda change when you add a disk? The kernel discovers disks during boot via the storage controller driver. The SCSI subsystem (which handles both real SCSI, SATA, and USB storage) assigns device names in the order it probes them. Add a disk to a SATA port that is probed earlier in the sequence, and all existing disks shift by one letter. NVMe uses a different naming scheme (nvme0n1, nvme1n1) that encodes the controller and namespace, which is more stable — but still not as stable as UUIDs. UUIDs are written into the filesystem superblock at format time and are tied to the data, not the hardware path.

Check yourself

Quiz

You add an fstab entry for a new disk using its /dev/sdb1 path (not UUID), reboot, and find /data is mounted on the wrong disk. What went wrong and how should the entry have been written?

Recap

/etc/fstab makes mounts permanent across reboots. Each line has six fields: device, mountpoint, fstype, options, dump, pass. Always use UUID (from blkid or lsblk -f) instead of /dev names — device names shift when disks are added or ports change. nofail prevents a failed mount from dropping the system to emergency mode; always use it for external drives and network filesystems. Test every fstab change with sudo mount -a before rebooting — on a remote server, an untested bad fstab line is a hard lock-out. If you do end up in emergency mode: mount -o remount,rw /, fix the bad line in /etc/fstab, run mount -a to verify, then systemctl reboot. systemd converts fstab lines to mount units via systemd-fstab-generator; you can also write .mount unit files directly for more control.

Practice

Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.

recallapplystretch0 of 4 done

Something unclear?

Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.