LFCS 80 🐧 Persistent Mounts — /etc/fstab - KandZ

⏱️ Estimated read: 13 min | |

A mount performed at the shell lasts until reboot. A mount written into /etc/fstab survives. That distinction is the entire purpose of the file: it is the static description of which filesystems the system should attach at boot, read by mount, fsck, and umount as they iterate through its records in order . The LFCS exam treats this file as a required competency because a correct entry makes storage available automatically, and a wrong one can prevent the system from booting at all.

This chapter covers the structure and discipline of /etc/fstab. It begins with the six fields that make up each entry, then explains why UUIDs have replaced device names as the recommended identifier. It addresses the nofail option that prevents a missing disk from blocking boot, the verification steps that catch errors before a reboot, and the failure modes that turn a typo into an emergency shell. The chapter closes with the workflow for editing and testing an entry safely.

Key point: /etc/fstab is read at boot. A malformed entry, a wrong UUID, or a missing device without nofail can drop the system into emergency mode before any login is possible.

Why /etc/fstab exists

The boot-time reconstruction problem. The kernel does not remember mounts across reboots. Every time the system starts, it must be told which filesystems to attach and where. /etc/fstab is that instruction set. It is a plain text file, maintained by the administrator, and it is read sequentially by the boot process . The order of entries matters because fsck and mount process them in file order.

The identifier stability problem. Device names like /dev/sda1 are assigned by the kernel based on discovery order, and that order can change when disks are added, removed, or when controller initialization order shifts . An fstab entry that points to /dev/sdb1 may point to a different disk after the next reboot. UUIDs and labels are properties of the filesystem itself, not of the device’s discovery position, which makes them stable across hardware changes .

The failure isolation problem. If a filesystem listed in fstab cannot be mounted, the boot process may stop. For the root filesystem this is correct: the system cannot function without it. For a data disk that is not attached, or a network share that is unreachable, stopping the boot is unnecessary. The nofail option tells the boot process to continue even if the mount fails, which is essential for cloud instances, removable media, and non-critical storage .

The single source of truth. Tools other than mount consult fstab. fsck uses the pass number field to decide check order. umount can unmount by mount point because it finds the matching entry. systemd generates mount units from fstab entries. A well-maintained fstab is therefore not just a convenience; it is the configuration that the storage stack depends on .

a. The six fields of an fstab entry

Each line in /etc/fstab contains six fields separated by whitespace. Lines beginning with # are comments, and blank lines are ignored .

# A typical fstab entry:
# <device>        <mount point>  <type>  <options>        <dump> <pass>
UUID=abcd-1234    /data          ext4    defaults,nofail  0      2

The first field identifies the filesystem. It can be a device path (/dev/sdb1), a UUID (UUID=...), a label (LABEL=...), or a partition identifier (PARTUUID=...). The recommended form is UUID or LABEL, because device names are not stable . For swap, the field is the swap device; for pseudo-filesystems, any string that will appear in df output is acceptable.

The second field is the mount point. For swap entries, this field is none . The directory must exist before the mount is attempted. If the path contains spaces, they must be escaped as \040.

The third field is the filesystem type: ext4, xfs, btrfs, swap, nfs, and so on. The type tells mount which driver to use and tells fsck which checker to invoke .

The fourth field is a comma-separated list of mount options. defaults is a bundle that includes rw, suid, dev, exec, auto, nouser, and async. Additional options are appended: defaults,nofail, defaults,noexec, defaults,ro. There must be no spaces after the commas .

The fifth field is the dump flag, used by the obsolete dump backup utility. It is almost always 0 .

The sixth field is the pass number, which controls fsck order at boot. 0 means skip the check, 1 is reserved for the root filesystem, and 2 means check after root, in parallel with other filesystems marked 2. For non-root filesystems, 2 is the conventional value, though many modern systems use 0 for non-critical mounts .

b. UUIDs, labels, and why they matter

The fstab manual is explicit: UUID=<uuid> or LABEL=<label> is the recommended method, “as device names are often a coincidence of hardware detection order, and can change when other disks are added or removed” . The UUID is a 128-bit identifier assigned when the filesystem is created, and it normally does not change unless the partition is reformatted .

Finding the UUID is the first step of writing an entry. blkid reports the UUID, label, and filesystem type for a device. lsblk -f presents the same information in a tree format that shows the partition structure .

# Find the UUID and type of a specific device.
sudo blkid /dev/sdb1

# Output example:
# /dev/sdb1: UUID="c3d4e5f6-a7b8-9012-cdef-123456789012" TYPE="ext4" LABEL="data"

# A tree view of all block devices with filesystem information.
lsblk -f

Labels are human-readable alternatives to UUIDs. They must be unique across the system, and they are set with filesystem-specific tools: e2label for ext4, xfs_admin -L for XFS, and swaplabel for swap . A label-based entry uses LABEL=data in the first field instead of UUID=.... Labels are easier to remember, but they are shorter and can collide if the administrator is not careful.

The /dev/disk/by-uuid/ directory provides a filesystem view of the UUID-to-device mapping, with symlinks named by UUID pointing to the actual device nodes . This is a useful inspection tool when verifying that a UUID in fstab matches an existing device.

c. The nofail option and boot safety

The nofail mount option is the difference between a missing data disk and an unbootable system. Without it, an fstab entry for a device that is not present causes the boot process to wait, then fail, and often drop into emergency mode . With nofail, the boot continues, and the filesystem is simply not mounted.

# Without nofail: a missing device blocks boot.
UUID=xxxx /data ext4 defaults 0 2

# With nofail: a missing device is skipped, boot continues.
UUID=xxxx /data ext4 defaults,nofail 0 2

The nofail option is particularly important for cloud instances, where data disks may be detached and reattached between boots . It is also recommended for NFS mounts and other network filesystems, where the server may be unreachable at boot time . The option should not be applied to the root filesystem: the system cannot function without root, so a failure there should stop the boot.

A related option for network filesystems is _netdev, which tells the boot process to wait until the network is up before attempting the mount . Without _netdev, an NFS mount may be attempted before networking is configured, which fails even if the server is available.

Complete Example Session

# ============================================
# PART 1: THE CURRENT STATE
# ============================================
# Read the existing fstab before changing anything.

cat /etc/fstab

# ============================================
# PART 2: THE SAFETY BACKUP
# ============================================
# Always back up fstab before editing.
# A corrupted fstab can prevent boot.

sudo cp /etc/fstab /etc/fstab.bak

# ============================================
# PART 3: FINDING THE UUID
# ============================================
# The UUID is the recommended identifier.
# It is stable across hardware changes.

sudo blkid /dev/sdb1
# Note the UUID value for the next step.

# ============================================
# PART 4: THE NEW ENTRY
# ============================================
# Append the entry to fstab.
# Fields: device, mount point, type, options, dump, pass.

# Using a text editor:
# sudo vi /etc/fstab
# Add this line:
# UUID=c3d4e5f6-a7b8-9012-cdef-123456789012 /data ext4 defaults,nofail 0 2

# Or append with tee:
echo 'UUID=c3d4e5f6-a7b8-9012-cdef-123456789012 /data ext4 defaults,nofail 0 2' | sudo tee -a /etc/fstab

# ============================================
# PART 5: THE MOUNT POINT
# ============================================
# The directory must exist before mount -a.

sudo mkdir -p /data

# ============================================
# PART 6: TESTING WITHOUT REBOOT
# ============================================
# mount -a reads fstab and mounts everything not already mounted.
# This is the verification step that catches errors before reboot.

sudo mount -a

# ============================================
# PART 7: VERIFICATION
# ============================================
# Confirm the mount succeeded and the source is correct.

findmnt /data
df -hT /data

# ============================================
# PART 8: THE SYSTEMD RELOAD
# ============================================
# On systemd systems, regenerate mount units after fstab changes.
# This is recommended by the fstab manual.

sudo systemctl daemon-reload

# ============================================
# PART 9: THE FAILURE CASE
# ============================================
# Remove the nofail option to see the failure behavior.
# Then restore it.

# If the device is missing and nofail is absent:
# sudo mount -a
# mount: /data: can't find UUID=xxxx.
# At boot, this would enter emergency mode.

# ============================================
# PART 10: THE FINAL CHECK
# ============================================
# Verify the entry is syntactically correct.

findmnt --verify

echo "fstab workflow complete."

The ten parts walk through the safe editing workflow: read, back up, find the UUID, append, create the mount point, test with mount -a, verify with findmnt, reload systemd, and check. The nofail option is included in the example because it is the default recommendation for any non-root mount, particularly in environments where hardware can change.

Quick Reference

The Six Fields

Field	Name	Example	Notes
1	Device	`UUID=xxxx`	UUID or LABEL recommended
2	Mount point	`/data`	Must exist; `none` for swap
3	Type	`ext4`	Filesystem driver
4	Options	`defaults,nofail`	No spaces after commas
5	Dump	`0`	Obsolete, always `0`
6	Pass	`2`	fsck order; `0` skip, `1` root

Identifier Types

Form	Stability	When to Use
`/dev/sdX`	Unstable	Never in fstab
`UUID=...`	Stable	Recommended
`LABEL=...`	Stable if unique	Human-readable alternative
`PARTUUID=...`	Stable	GPT partitions

Critical Options

Option	Effect	When to Use
`defaults`	Bundle: rw,suid,dev,exec,auto,nouser,async	Baseline
`nofail`	Boot continues if mount fails	Non-critical mounts
`_netdev`	Wait for network before mount	NFS, network filesystems
`noexec`	Prevent execution	Data partitions
`ro`	Read-only	Rescue, forensics

Verification Commands

Command	Purpose
`mount -a`	Mount all fstab entries not already mounted
`findmnt /data`	Confirm the mount
`findmnt --verify`	Syntax and consistency check
`systemctl daemon-reload`	Regenerate systemd mount units

Best Practices

✅ Do This:

# Back up fstab before editing.
sudo cp /etc/fstab /etc/fstab.bak                                    # ✅

# Use UUIDs, not device names.
UUID=xxxx /data ext4 defaults,nofail 0 2                            # ✅

# Add nofail to non-critical mounts.
UUID=xxxx /data ext4 defaults,nofail 0 2                            # ✅

# Test with mount -a before rebooting.
sudo mount -a                                                        # ✅

# Use _netdev for network filesystems.
server:/export /mnt nfs defaults,_netdev,nofail 0 0                 # ✅

# Reload systemd after fstab changes.
sudo systemctl daemon-reload                                        # ✅

❌ Don’t Do This:

# Don't use device names in fstab.
/dev/sdb1 /data ext4 defaults 0 2  # may change on reboot           # ❌

# Don't omit nofail for removable or cloud disks.
UUID=xxxx /data ext4 defaults 0 2  # missing disk blocks boot        # ❌

# Don't apply nofail to the root filesystem.
UUID=xxxx / ext4 defaults,nofail 0 1  # root must fail if absent     # ❌

# Don't use a stale UUID after reformatting.
UUID=old-uuid /data ext4 defaults 0 2  # filesystem changed          # ❌

# Don't skip mount -a testing.
# A syntax error in fstab can prevent boot.                         # ❌

# Don't edit fstab without a backup.
# Emergency recovery is harder without a known-good copy.           # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
System drops to emergency mode	Missing device without `nofail`	Add `nofail` or remove the entry
Mount fails with “can’t find UUID”	Wrong UUID or reformatted filesystem	Re-run `blkid` and update the entry
Mount point does not exist	Directory was not created	`mkdir -p` before `mount -a`
Network mount fails at boot	NFS attempted before network is up	Add `_netdev`
fstab syntax error	Missing field, space in options	Use `findmnt --verify`
Systemd does not see the new mount	fstab modified after boot	`systemctl daemon-reload`
Label collision	Two filesystems share a label	Use UUID instead

Real-World Examples

1. UUID Entry with nofail

UUID=abcd-1234 /data ext4 defaults,nofail 0 2

2. Label Entry

LABEL=data /data xfs defaults 0 0

3. NFS Entry with _netdev

server:/export /mnt/nfs nfs defaults,_netdev,nofail 0 0

4. Swap Entry

UUID=swap-uuid none swap sw 0 0

5. Read-Only Data Mount

UUID=xxxx /archive ext4 defaults,ro,nofail 0 2

6. Backup Before Edit

sudo cp /etc/fstab /etc/fstab.bak

7. Find UUID

sudo blkid /dev/sdb1

8. Test All Entries

sudo mount -a

9. Verify Syntax

findmnt --verify

10. Reload Systemd

sudo systemctl daemon-reload

Visual

The Six Fields

┌─────────────────────────────────────────────────────────┐
│  UUID=abcd-1234  /data  ext4  defaults,nofail  0  2    │
│    │               │       │       │             │  │   │
│    │               │       │       │             │  └─ pass
│    │               │       │       │             └──── dump
│    │               │       │       └────────────────── opts
│    │               │       └────────────────────────── type
│    │               └────────────────────────────────── mnt
│    └────────────────────────────────────────────────── device
│                                                         │
│  Field 1: stable identifier (UUID recommended)          │
│  Field 2: directory, must exist                         │
│  Field 3: driver name                                   │
│  Field 4: comma-separated, no spaces                    │
│  Field 5: obsolete, 0                                   │
│  Field 6: fsck order (0, 1, or 2)                       │
└─────────────────────────────────────────────────────────┘

The Boot Failure Path

┌─────────────────────────────────────────────────────────┐
│  /etc/fstab entry for missing device without nofail:    │
│                                                         │
│  UUID=xxxx  /data  ext4  defaults  0  2                │
│                                                         │
│  BOOT:                                                  │
│  1. systemd reads fstab                                 │
│  2. Attempts to mount /data                             │
│  3. Device not found → timeout                          │
│  4. Mount fails → dependency failure                    │
│  5. System enters emergency mode                        │
│                                                         │
│  RESULT: no login, no services, recovery required       │
│                                                         │
│  ─────────────────────────────────────────────────────  │
│                                                         │
│  With nofail:                                           │
│                                                         │
│  UUID=xxxx  /data  ext4  defaults,nofail  0  2         │
│                                                         │
│  BOOT:                                                  │
│  1. systemd reads fstab                                 │
│  2. Attempts to mount /data                             │
│  3. Device not found → mount skipped                    │
│  4. Boot continues normally                             │
│                                                         │
│  RESULT: system boots, /data is simply absent           │
└─────────────────────────────────────────────────────────┘

UUID vs Device Name

┌─────────────────────────────────────────────────────────┐
│  DEVICE NAME (/dev/sdb1):                               │
│                                                         │
│  Boot 1: sda=disk0, sdb=disk1 → /dev/sdb1 = disk1      │
│  Boot 2: sda=disk1, sdb=disk0 → /dev/sdb1 = disk0      │
│                                                         │
│  Same fstab line, different disk. Data loss possible.   │
│                                                         │
│  ─────────────────────────────────────────────────────  │
│                                                         │
│  UUID:                                                  │
│                                                         │
│  UUID=abcd-1234 is written into the filesystem          │
│  superblock at mkfs time.                               │
│                                                         │
│  Boot 1: UUID=abcd-1234 → disk1                         │
│  Boot 2: UUID=abcd-1234 → disk1                         │
│                                                         │
│  The UUID follows the filesystem, not the device slot.  │
│  It changes only if the partition is reformatted.       │
└─────────────────────────────────────────────────────────┘

Safe Edit Workflow

┌─────────────────────────────────────────────────────────┐
│  1. cp /etc/fstab /etc/fstab.bak                        │
│         │                                               │
│         ▼                                               │
│  2. blkid /dev/sdb1 → note UUID                         │
│         │                                               │
│         ▼                                               │
│  3. Edit fstab, add entry with UUID and nofail          │
│         │                                               │
│         ▼                                               │
│  4. mkdir -p /mountpoint                                │
│         │                                               │
│         ▼                                               │
│  5. mount -a  ← catches syntax and UUID errors          │
│         │                                               │
│         ▼                                               │
│  6. findmnt /mountpoint  ← confirms success             │
│         │                                               │
│         ▼                                               │
│  7. systemctl daemon-reload                             │
│         │                                               │
│         ▼                                               │
│  8. Reboot (optional, to confirm persistence)           │
└─────────────────────────────────────────────────────────┘

Summary

Item	Value
File	`/etc/fstab`
Read by	`mount`, `fsck`, `umount`, systemd
Fields per line	6
Field 1	Device (UUID/LABEL recommended)
Field 2	Mount point
Field 3	Filesystem type
Field 4	Mount options
Field 5	Dump (obsolete, `0`)
Field 6	fsck pass (`0`, `1`, `2`)
Boot safety option	`nofail`
Network option	`_netdev`
Verification	`mount -a`, `findmnt --verify`

Key takeaways:

/etc/fstab is read at boot, not at login. A bad entry can prevent the system from reaching a usable state.
UUIDs are the recommended identifier. Device names depend on discovery order and can change; UUIDs are properties of the filesystem .
nofail is essential for non-critical mounts. Without it, a missing disk or unreachable network share can drop the system into emergency mode .
The six fields are positional. Device, mount point, type, options, dump, pass. A missing or extra field breaks the entry.
mount -a is the test that matters. It reads fstab and attempts every mount, catching syntax errors and wrong UUIDs before a reboot.
findmnt --verify checks consistency. It catches structural problems that mount -a may not report clearly.
Systemd needs a reload. After editing fstab, systemctl daemon-reload regenerates the mount units .
The root filesystem is the exception. It should not have nofail; if root cannot mount, the system cannot function.
Labels are acceptable but must be unique. They are easier to remember than UUIDs but can collide if the administrator is careless.
A backup is cheap; recovery is not. cp /etc/fstab /etc/fstab.bak before editing is the single most useful habit for this file.

Remember: /etc/fstab is the difference between a mount that exists for one session and one that exists for the life of the system. It is a simple file—six fields per line, read in order—but its position in the boot path makes every character consequential. Use UUIDs instead of device names, add nofail to everything that is not root, test with mount -a before rebooting, and keep a backup. The LFCS exam expects you to write a correct entry, explain why UUIDs are preferred, and recognize the failure mode that a missing nofail produces.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!