Mounting and Filesystem Management with fstab and NFS
You will configure resilient boot-time mounts for local and network filesystems on a server. By the end you will mount a local disk by UUID and an NFS share, both surviving reboot.
Learning Objectives
- Write safe UUID-based fstab entries with the nofail option.
- Mount an NFS share at boot.
- Validate every entry without risking a boot hang.
- Time: ~2 hours · Difficulty: Intermediate · Prereqs: a server plus a local disk and (optionally) an NFS export.
Architecture Overview
Environment Setup
You will need: util-linux, and nfs-common for the NFS portion.
Before you begin: know your disk UUID (blkid) and the NFS server export path.
Prerequisites
- Linux with util-linux and, for step 2, nfs-common installed and an NFS export available.
- Root or sudo access to edit /etc/fstab and mount.
- A spare formatted device for the local mount step.
- Backup of /etc/fstab before editing.
Step-by-Step Execution
UUIDs are stable across reboots; nofail avoids a boot hang if the disk is absent.
echo "UUID=$(blkid -s UUID -o value /dev/sdb1) /mnt/local ext4 defaults,nofail 0 2" | sudo tee -a /etc/fstabExpected output:
UUID=a1b2c3d4-5678-90ab-cdef-1234567890ab /mnt/local ext4 defaults,nofail 0 2
(entry appended to /etc/fstab)What this teaches: Command substitution embeds the live UUID so the entry is correct by construction; nofail lets boot continue if the disk is ever absent.
NFS lets multiple servers share centralized storage over the network.
echo "192.168.1.50:/export/share /mnt/share nfs defaults,_netdev,nofail 0 0" | sudo tee -a /etc/fstabExpected output:
192.168.1.50:/export/share /mnt/share nfs defaults,_netdev,nofail 0 0
(entry appended to /etc/fstab)What this teaches: NFS entries name server:/export plus the nfs type; _netdev tells systemd to order the mount after the network is up.
Expected output:
What this teaches: mount -a replays fstab now, catching errors before a reboot does; findmnt verifies each target resolved to the intended source. Note: mount -a needs root, which is why the session above uses the # prompt; prefix with sudo as a non-root user. For an even safer check that never touches a mount, run sudo findmnt --verify, which parses fstab and reports errors without mounting anything.
How It Works
Server mounts split into two kinds: local devices identified by UUID, and network filesystems identified by server and export path. fstab handles both with the same six fields, but network mounts add ordering constraints: the network must be up before the mount is attempted, which is what _netdev communicates to systemd.
systemd translates fstab into mount units at boot, which is why _netdev and nofail actually work: they become unit dependencies and failure policies rather than comments. Understanding this translation explains boot ordering bugs that look mysterious from a pure fstab perspective.
NFS itself is stateless from the client's view: the server exports a subtree, the client mounts it, and file handles survive server reboots better than stateful protocols. The trade-off is that a hung server hangs client processes in uninterruptible sleep, so soft/timeo tuning and nofail belong in any production NFS entry.
The last two fstab fields deserve attention because the examples use them deliberately: the dump field (5th) is 0 everywhere since the dump backup utility is obsolete, and the fsck pass field (6th) is 2 for the local ext4 filesystem but 0 for NFS, because fsck cannot check a network filesystem. The root filesystem alone uses pass 1; everything local and non-root uses 2.
Progress So Far
Testing & Validation
mount -a && df -hT /mnt/local /mnt/sharesudo findmnt --verifyYou should see both mounts with their filesystem types and no errors from mount -a. findmnt --verify should report success, confirming fstab parses cleanly without changing any mount state. If clean, your mounts are boot-safe.
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| NFS mount hangs at boot | _netdev missing so mount raced the network | Add _netdev and consider x-systemd.automount for on-demand mounting |
| Permission denied on NFS files | Squash mapping or UID mismatch between client and server | Align UIDs or configure no_root_squash / all_squash deliberately on the export |
| Stale file handle errors | Server-side export changed underneath the client | Remount the share; for persistent issues check exportfs -v on the server |
| mount -a reports bad option | Typo in the options field | Validate against mount(8); options are comma-separated with no spaces |
| Local mount missing after reboot | Entry used /dev/sdX which got reordered | Switch to UUID= form via blkid |
| Automount storms on login | Many on-demand mounts trigger at once | Tune x-systemd.idle-timeout so unused mounts release |
Troubleshooting
- Boot hangs waiting for a mount: add
nofail(and_netdevfor network mounts). - NFS mount times out: confirm the export with
showmount -e 192.168.1.50and firewall on TCP/2049. - Permission denied on NFS: check the export's allowed clients and squash settings.
Extension Ideas
- Replace fstab with a systemd
.mountunit for dependency control. - Combine with LVM for flexible local capacity.
- Secure NFS with Kerberos (sec=krb5p).
Key Results
- Configured local and NFS mounts that persist across reboot.
- Prevented boot hangs with nofail and _netdev options.
- Validated entries safely with
mount -abefore reboot. - Centralized shared storage over NFS for multiple servers.
Key Takeaways
- Local mounts: UUID plus nofail for reboot safety.
- NFS mounts need _netdev so systemd orders them after networking.
- fstab becomes systemd mount units; options are real dependencies.
- mount -a plus findmnt validates without a reboot.
- Tune NFS timeouts; hung servers hang clients.
Practice Challenges
Challenge 1: Automount share
Goal: convert the NFS entry to x-systemd.automount with a 60-second idle timeout, then prove it mounts on first access and unmounts when idle.
Hint: watch findmnt before and after ls.
Challenge 2: Boot-order proof
Goal: on a test VM, remove _netdev from the NFS line, reboot, and document what happens; then restore it.
Hint: snapshot before breaking the boot.