Back up /etc/fstab and record the actual block-device layout with lsblk -f. Confirm filesystem type, UUID, mount point and intended ownership. Keep console access available, especially when changing root, boot, encrypted or network-storage entries.

1. Create the intended empty mount point and check whether existing files there would be hidden by a mount. Move or preserve them through a planned procedure rather than mounting over active application data.
2. Add the reviewed fstab entry using the correct stable identifier, filesystem and mount options. Do not copy a UUID or device name from another server.
3. Choose boot-dependency behavior deliberately. An optional archive disk and a mandatory application-data disk should not necessarily have the same nofail or timeout policy.
4. Run findmnt --verify --verbose where supported to check the table. Then test the specific new mount without unmounting critical live filesystems or activating unrelated unreviewed entries.
5. Inspect the actual mount with findmnt and test access as the intended application account. Reload systemd mount definitions as documented when fstab changes, then schedule a controlled reboot only after the live test succeeds.

After preparing a mount change on a Linux server, run these checks from the administrative session. Replace /srv/data with the affected path. The verification command checks the filesystem table; it does not mount every entry or prove that remote storage will be reachable during boot.

sudo findmnt --verify --verbose
findmnt --target /srv/data
lsblk -f

Read the result: Resolve reported syntax, source and mount-point problems. Compare the fstab source with the actual UUID or device and check the filesystem type. An existing runtime mount can still differ from the saved entry, which is why reading the current mount alone is insufficient.

For network storage, also review boot ordering, credentials and failure behaviour. Complete a targeted mount test using the approved procedure before a planned reboot. Keep console access available so a bad persistent mount cannot leave the server recoverable only through a failed SSH connection.

A mount can hide files already present in the mount-point directory. The underlying files may still exist, but inspect them only through a safe unmount or alternate recovery view that does not disrupt active services.

Confirm the filesystem is mounted from the intended source with the expected options and data. After a maintenance reboot, verify service ordering and application access. Ensure a missing mandatory mount cannot silently redirect application writes into the underlying root filesystem.

If mounting fails, inspect the exact source identifier, filesystem driver and options. Restore the previous entry through the console when necessary. Do not format a device merely because a mount failed or add nofail to every entry just to suppress a boot problem.

• Inspecting an unbootable Linux server from rescue mode
• Extending a Linux logical volume safely
• Responding to a Linux filesystem that became read-only
• Testing SSH configuration before reloading the service

• Debian manual: Fstab.5.en
• Debian manual: Findmnt.8.en
• Debian manual: Systemd.mount.5.en

• util-linux lsblk manual, published by Debian