A machine stuck at boot, showing an emergency shell (Give root password for maintenance) after an otherwise routine restart, very often points to a single line in /etc/fstab: a mount listed as required while the device or remote server it references is no longer available.

What /etc/fstab promises by default

Every /etc/fstab line without the nofail option gets treated by default as a required mount for the boot to be considered successful: systemd generates a mount unit for each entry and waits for it to succeed before continuing the normal boot sequence.

# /etc/fstab: this mount is required by default,
# its failure blocks normal startup
/dev/sdb1  /data  ext4  defaults  0  2

An unplugged external drive, a partition renamed after a hardware change, or a temporarily unreachable NFS share then turns a simple missing resource into a complete boot failure, far beyond that missing resource’s actual real-world impact.

nofail: making a mount non-blocking

The nofail option explicitly states that this particular mount’s failure should never prevent the rest of the boot from continuing normally: the machine boots, the missing mount is simply absent, with no emergency shell and no hang.

# With nofail, this device's absence
# never blocks the boot anymore
/dev/sdb1  /data  ext4  defaults,nofail  0  2

The reverse trap: nofail everywhere isn’t always desirable

Adding nofail on a mount that’s genuinely critical to a service’s operation (a database whose data volume absolutely must be mounted before the corresponding service starts) shifts the problem rather than solving it: the machine boots fine, but the service fails silently later, unable to find its data in the expected place, a failure often harder to diagnose than an explicit boot hang.

x-systemd.device-timeout: reducing the wait without dropping the dependency

For a mount that’s genuinely needed but whose temporary unavailability (a slow-to-respond NFS share, for instance) shouldn’t block startup indefinitely, x-systemd.device-timeout sets a maximum wait before systemd considers the mount failed and moves on, a middle ground between nofail (no wait, no block) and the default behavior (potentially long wait, guaranteed block on failure).

# Waits at most 10 seconds before
# moving past this NFS mount
server:/export  /mnt/nfs  nfs  defaults,x-systemd.device-timeout=10  0  0

Takeaway

Any /etc/fstab line without nofail blocks the entire boot by default if the referenced device or share is unavailable, a behavior that turns a simple missing resource into a full machine outage — the same kind of implicit, underestimated dependency already seen with a systemd service’s automatic restart. nofail makes a mount non-blocking, but applying it blindly to a genuinely critical mount shifts the failure to the dependent service rather than resolving it. x-systemd.device-timeout offers a middle ground for mounts that are needed but sometimes slow to respond, capping the wait without removing the dependency itself — a reliability concern that connects directly to the reliability and observability offer.