Configure fstab without losing boot

/etc/fstab tells systemd which filesystems to mount at boot. One bad required entry can delay boot or drop you into emergency mode.

My advice: always mount by UUID, never by a device name like /dev/sdb1. Device names move. UUIDs do not. Create the mount point directory before you edit fstab, and test every change while you still have recovery access open.

What an fstab line looks like

Each line has six fields: device, mount point, filesystem type, options, dump flag, and fsck order. For a data disk that can be absent at boot, nofail is the option that matters:

UUID=9a7f43c2-6c1d-4c2e-8f3a-2b64d0e51c77  /srv/data  ext4  defaults,nofail  0  2

Copy the UUID from blkid, not from memory. A single wrong character sends the kernel looking for a filesystem that does not exist.

Test before you reboot

Run findmnt --verify after editing. It catches syntax errors and missing mount points without touching the running system:

sudo findmnt --verify
# none of your target filesystems found, but all mount points are accessible
# 0 parse errors, 0 errors, 6 warnings

Warnings about swap or tmpfs are normal. Parse errors are not. Then run mount -a, which mounts everything in fstab that is not already mounted. If that succeeds, write a test file and read it back:

echo "fstab ok" | sudo tee /srv/data/.mount-test
cat /srv/data/.mount-test
# fstab ok

Only schedule a reboot after mount -a, findmnt, and a write test all pass.

Use the filesystem UUID, create the mount point, and test without rebooting:

sudo blkid /dev/sdb1
sudo mkdir -p /srv/data
sudoedit /etc/fstab
sudo mount -a
findmnt /srv/data

Keep a root shell or provider console open. A typo in fstab can delay or break boot. Run mount -a and verify the expected device, filesystem, options, and writable path before scheduling a reboot.

Try this on your own project: add a disposable filesystem to fstab using its UUID and nofail, test it without rebooting, then explain whether the real workload should tolerate the disk being absent.