Check fstab and missing mounts before rebooting Linux

A wrong filesystem entry can turn a routine reboot into emergency mode. These checks are for an administrator of a Debian or Ubuntu VPS or dedicated server. They inspect configuration and mounted filesystems; they do not format disks, repair a filesystem or force mounts. Keep browser console access and a verified backup available before editing boot-critical configuration.

Record the actual layout

lsblk -f
findmnt
cat /etc/fstab
findmnt --verify --verbose

Compare each configured UUID or label with the device list. Device names such as /dev/sdb can change across boots, so do not substitute one simply because it looks plausible. Check the mountpoint, filesystem type and options as separate fields. A clean verification report catches some configuration errors, but does not prove that every device will appear on the next boot.

Use findmnt -T /srv/example for an application path. If an expected data disk is absent, the application may be writing into a directory on the root filesystem instead. Do not mount the missing disk over those new files and assume the data is merged; the mount hides the underlying directory contents.

Review before changing anything

Save a private copy of the current fstab with a clear timestamp and record the current mount output. Check whether any entry represents swap, a network share, encrypted storage or a provider-managed volume. Each has dependencies that a simple local-disk recipe misses. Root and boot entries require particular care.

A missing optional data disk and a missing root filesystem are different incidents. Options such as nofail change boot behaviour; they do not make the data available or make it safe for an application to start without its storage. Do not apply them to every entry as a general fix. Avoid running mount -a blindly on an unfamiliar production server because it can activate unrelated entries.

If the server is already in rescue mode

Open the provider console and capture the exact failure message first. Establish whether you are in the installed system's emergency shell or a separate rescue operating system. Their device names and root directories may differ. Inspect lsblk -f before choosing any device; a size match alone is insufficient identification.

Read-only rescue access is preferable for evidence collection. Filesystem-specific restrictions still apply, and damaged or journaled filesystems may need special handling. Ask support before mounting a questionable volume or running a repair tool. Do not run a repair command on a mounted filesystem. Photograph or copy the relevant error text without exposing secrets.

Validate a controlled correction

After a reviewed edit, repeat fstab verification and compare the exact changed line with the saved copy. Confirm that applications depending on the data path are stopped or otherwise protected before altering mounts. Schedule a reboot only when console access and a recovery plan are ready; a syntax check is not a complete boot test.

If the correction fails, use the saved configuration and console to reverse that specific edit. Preserve both the old and new evidence for support. Reinstalling the operating system is not a prerequisite for investigating a missing mount.

Recover console access. Verify a downloaded backup.

Reference: Official documentation. Check the documentation installed on your own operating-system release when an option differs.