The Six fstab Fields, Precisely
In one line
One fstab line has six fields: device / mount point / type / options / dump / pass. There have been real cases where sloppily writing the last two numbers made the boot hang.
Why you need this
fstab is one of the most dangerous files on a system. If you write it wrong, the boot hangs midway, and if you have no console, there is nothing you can do. Yet the format is simple, so people copy and paste it carelessly.
How it works
UUID=1a2b... /srv/data ext4 defaults,noatime,nofail 0 2
[----1----] [---2---] [-3-] [--------4---------] 5 6
1. Device identifier. UUID=, LABEL=, PARTUUID=, or a device path. For a network filesystem, the form server:/export. A device path is unstable, so use the UUID.
2. Mount point. An absolute path. If it contains a space, escape it as \040.
3. Filesystem type. ext4, xfs, tmpfs, nfs4, none (bind mount), auto.
4. Options. Separated by commas. The commonly used ones:
| Option | Meaning | When |
|---|---|---|
defaults |
rw,suid,dev,exec,auto,nouser,async | Default |
noatime |
Do not update the access time on reads | Recommended on most servers |
nofail |
Continue booting even if the mount fails | Essential for data disks |
_netdev |
Mount after the network is ready | Essential for NFS/iSCSI |
noexec,nosuid,nodev |
Forbid execution/setuid/device files | /tmp, user upload paths |
ro |
Read-only | Data under audit |
bind |
Bind mount | See below |
Without nofail, if one data disk dies, the whole server will not boot. It is effectively essential for every entry that is not the root.
5. dump. A flag for the old dump backup tool. These days it is almost always 0.
6. pass — the fsck check order. This is the real trap.
| Value | Meaning |
|---|---|
0 |
Do not check (tmpfs, NFS, bind mounts) |
1 |
The root filesystem only. Checked first, on its own |
2 |
Other local filesystems. Checked in parallel after 1 finishes |
If you give 1 to something that is not the root, at boot it tries to check several filesystems at once, each as if it were alone, and the order gets tangled. If you give 1 or 2 to a network filesystem, it tries to check during the early boot stage when there is no network, and hangs.
Bind mounts
This makes one directory of the same filesystem visible at another path as well.
/srv/data /var/www/data none bind 0 0
How is it different from a symbolic link? A symlink is a path string, and a bind mount is a real mount. That is why, in places where the scope of path resolution is limited, such as inside a chroot or a container, a symlink breaks but a bind mount works. Also, you can give a bind mount a separate option such as ro — the original can be writable while this path alone shows it as read-only.
Verification
After you edit fstab, always check before you reboot. Rebooting to find out is not verification, it is gambling.
findmnt --verify --verbose
mount -a # 실제로 붙여 본다 (특권 필요)
What it looks like in the field
Leaving _netdev off an NFS entry. During boot, it tries to mount before the network is ready and waits until the timeout. Server boot gets 5 minutes longer.
Not fixing fstab after expanding capacity. You extended the LVM and even ran resize2fs, but after a reboot it comes back at the old size? In fact, fstab was pointing at a different volume.
systemd reads fstab
On modern Linux, fstab is not executed by itself; systemd reads it at boot and converts it into mount units. Knowing this explains two things.
First, you can view the mount status with systemctl status. /srv/data becomes a unit called srv-data.mount (the slashes in the path become dashes). When a mount fails, if you look at the cause with journalctl -u srv-data.mount, you get a much more specific message than when you just stare at fstab.
Second, some of the fstab options are actually instructions to systemd. nofail means do not block other units even if that mount fails, and _netdev means postpone the ordering until after the network is ready. The options that start with x-systemd. are systemd-specific altogether. Of these, I will point out only the two that are most valuable in practice.
x-systemd.automount— it does not mount at boot, but mounts when that path is actually accessed. It is especially good for network storage that is slow or sometimes absent. The boot is not delayed because of it.x-systemd.device-timeout=10s— shortens the time to wait for the device. The default is 90 seconds, so one nonexistent device holds up the boot for quite a while.
It is also easy to forget that after you edit fstab, you must tell systemd to read it again. If you do not run systemctl daemon-reload, systemd keeps holding the old units, which leads to a confusing state where mount -a mounts fine but after a reboot it behaves differently. If you add this to the findmnt --verify and mount -a mentioned earlier and make it a habit to check with three lines, incidents where the boot hangs because of fstab almost disappear.
What you will do in the next lab
You audit a broken fstab fixture against the rules to find the problem lines, fix it, and then write a verification script yourself. The grader runs that script on both good input and bad input to see whether it judges them correctly.