Linux mount boot contracts: prevent a service from writing into an empty mountpoint

Last updated: 2 Oct 20267 min read

tutorial

A mount configured as optional may let the host boot when its device is unavailable. That policy is useful for nonessential media, but dangerous for a stateful service that then writes into the bare directory on the root filesystem. An fstab nofail entry changes how the boot target treats the mount; it does not guarantee that every application depending on the path fails closed. The service needs an explicit mount requirement and a startup check that verifies the source or filesystem identity, not merely a directory's existence. For a remote mount, network ordering and timeout behavior must be tested during a cold boot and a later disconnect.

Operational decision

A document index expects a separate volume at /srv/index. The host boots once with that volume missing. The desired behavior is a healthy management plane but no index writer: the service stays stopped, readiness fails, and an alert names the absent mount. Operators inject the missing device on a disposable VM, inspect generated mount units and the index service's effective dependencies, then bring the volume back and verify that the service resumes only after the correct filesystem is present. They also confirm that no files were written to the root filesystem beneath the bare mountpoint. A second fault removes the remote storage after startup and checks whether the service detects failed I/O rather than serving stale success.

findmnt -no SOURCE,FSTYPE,OPTIONS /srv/index
systemctl status srv-index.mount
systemctl show index-writer.service -p RequiresMountsFor

Cost and verification

Failing a service closed when its data mount is absent reduces apparent uptime, but protects the intended data path from split storage. Long mount timeouts can delay boot and incident response, while a short timeout can reject a recoverable transient. Measure cold-boot readiness, mount retry behavior, and root filesystem usage during the fault. If the storage is intentionally optional, make that a different application contract with a defined fallback; do not reuse an optional boot rule as an implicit guarantee of safe application operation.

Common Mistakes

Do not check only whether the mountpoint directory exists.
Do not assume nofail means dependent services will fail safely.
Do not ignore what is written beneath a mountpoint while the volume is absent.

Connected lessons

Practice and check

devops

linux

storage-operations