Payments are experiencing issues due to temporary restrictions in Russia. If your payment does not go through, please submit a support request.Our support team is available 24/7 — we are always here to help with hosting and server issues.We are now accepting requests for dedicated server rental and colocation services in our data center.Reminder: we recommend enabling backups for additional data protection.A new VPS/VDS lineup with NVMe storage and improved performance is now available.Maintenance work on some servers has been completed. All services are operating normally.
Article6 min readViews6

How to Verify fstab Before Reboot: findmnt Without mount -a

We verify the candidate fstab using findmnt --verify, analyze return codes and method limitations without mounting disks or altering the active configuration.

МихаилCommunity author★ 14
Comments 0

Server, Storage, and Pre-Modification Mount Table Checklist
In this article

After editing fstab, the server may boot without the required volume, halt in emergency mode, or mount the wrong partition. Rebooting is too late to catch a typo. First, we verify the candidate file separately from the working configuration.

Ubuntu 24.04 is compatible with findmnt from util-linux. The command with --verify parses the table, checks its suitability, and returns a non-zero code if an error is found. The --tab-file parameter allows specifying a copy without replacing /etc/fstab or performing mounting.

Verification Boundaries

Below, syntax and system-available information about the target and source are checked. This is not proof that the file system is correct, the network storage will be accessible at boot, the password for CIFS is valid, or that the application will survive a mount point change. The command performs no mounting and does not reproduce the boot of systemd.

The check was performed on October 7, 2026, in an isolated Ubuntu 24.04.3 with util-linux 2.39.3. Only directories and sample files in the working directory were used; /etc/fstab was not modified, and mount and the reboot were not triggered.

Confirm Version and Prepare a Copy

findmnt --version

In the checked environment, the version check result is: findmnt from util-linux 2.39.3. Capabilities and diagnostic phrasing may differ in other versions.

cp /etc/fstab ./fstab.candidate

The command creates a working copy in the current directory. It is not a full server backup and does not replace the approved configuration recovery method. Check directory access rights: the file may contain network resource addresses and paths.

Edit only fstab.candidate. If the source of the change is a configuration management system, generate the candidate using the same template that will be applied on the server: a manual copy and the file produced by automation may differ.

Verify the Candidate Without Mounting

findmnt --verify --verbose --tab-file ./fstab.candidate

Code 0 means that findmnt found no errors or warnings in the available check. This is not authorization for an automatic reboot. Code 1 requires reading the diagnostics, fixing the candidate, and repeating the same command.

findmnt documentation states: --verify checks table readability and suitability, while --tab-file substitutes the path to the file being checked. It also states that --verbose adds details, and code 1 is used in case of an error.

fstab candidate verification scheme: findmnt returns code 0 or terminates the process with code 1.
Code 0 proceeds to the next check; code 1 triggers candidate correction.

How three different failures appear

In the first test, the mount point existed and the bind source was accessible. The check completed with the message Success, no errors or warnings detected and code 0.

findmnt --verify --verbose --tab-file ./fstab-valid; echo $?

In the second test, the destination directory specified in the line did not exist. findmnt reported unreachable on boot required target and returned 1. This result is important even with the correct number of fields: the line is formally readable, but it cannot be applied as a mandatory mount.

findmnt --verify --verbose --tab-file ./fstab-bad-target; echo $?

The third test used UUID, which does not exist in the environment. Diagnostics reported unreachable on boot required source and returned 1. This checks for the availability of the tag on the current node, not the state of the file system inside the device.

findmnt --verify --verbose --tab-file ./fstab-bad-source; echo $?

A single-field line returned parse error at line 1 -- ignored and code 1. A line without the fifth and sixth fields passed with code 0: this is not a skipped check. For fs_freq and fs_passno, the documentation defines default values, so their absence is not considered a syntax error.

Result matrix for four fstab checks with return codes 0 and 1
In a completed test check, a correct line yielded 0, while errors in target, UUID, and syntax yielded 1.

The six-field format, space escaping, and default values are described in the fstab reference. Pay special attention to the second column—the mount point—and the source identifier in the first.

Do not limit yourself to the green line

After code 0, match the candidate against actual devices. For UUID and LABEL, it is not a similar string that matters, but resolving the tag to the correct device.

findmnt --fstab --evaluate --tab-file ./fstab.candidate --output=SOURCE,TARGET,FSTYPE,OPTIONS

The command displays what tags resolve to and shows the target, type, and options. For scripts, specify columns explicitly: documentation warns that the default output set may change.

Then separately verify whether the expected directory exists, who owns it, and whether the new mount hides data already present there. findmnt will confirm the target exists, but it will not determine whether files in the directory should remain visible after mounting.

Why mount -a is not a neutral check

mount -a attempts to perform operations from fstab, except for entries with noauto. This state change can mount a network resource, hide directory contents with a new mount, or trigger file system helpers. Do not use such a command solely for syntax checking.

If you need to test actual mounting before rebooting, do it as a separate step within a coordinated window: with a confirmed configuration copy, a known unmounting method, and verification of applications that use the path. This article does not perform such a test.

Safe acceptance procedure

  • Save the candidate separately from /etc/fstab and record the initial configuration.

  • Check the version of util-linux.

  • Run findmnt --verify --verbose with an explicit --tab-file.

  • Fix every error and warning; do not rely only on the Success text.

  • Check which devices UUID and LABEL convert to when calling findmnt --fstab --evaluate.

  • Match the source, target, type, and options against the change plan.

  • After standard application, check /etc/fstab again.

  • Perform actual mounting and rebooting only with a rollback plan and console access.

The stop condition is simple: any parse error, unreachable source, or unreachable target leaves the change unprepared. Exit code 0 allows proceeding to the next check, but does not prove data availability after boot.

The final question before rebooting is not 'Was the command green?', but 'which source mounts to which target, with what options, and how do I restore the system if the boot proceeds differently?'. findmnt addresses the first part of this question; the recovery plan and service testing remain the team's responsibility.

GENERAL IT

Help with your project

GENERAL IT

Read more on this topic

Discussion 0

Share your experience and ask questions. Comments without links appear after editorial review.

No comments yet. Start the discussion.