Add and Verify an /etc/fstab Mount with systemd

A typo in /etc/fstab can leave a server refusing to boot, which is exactly why systemd-fstab-generator's own verification step matters. This guide adds one filesystem to the file, asks systemd to regenerate the mount unit, and verifies the mount without rebooting. Allow 15 minutes, plus time to identify the correct filesystem. The examples use systemd 255 from Ubuntu package version 255.4-1ubuntu8.17.

This guide assumes a filesystem that already exists and a mount point you are prepared to use. You need elevated privileges to edit /etc/fstab and mount the filesystem. The inspection commands are normally unprivileged. Do not use a guessed device name or UUID: mounting the wrong block device can expose, overwrite or corrupt data.

1. Identify the filesystem and mount point

Inspect available block devices before changing configuration:

$ lsblk -f
$ findmnt --verify

Choose a stable identifier such as UUID=YOUR-UUID or LABEL=YOUR-LABEL. Device names such as /dev/sdb1 can change when hardware detection order changes. Replace /srv/example below with a real, currently unused directory, and replace YOUR-UUID with the value from lsblk -f.

Create the mount point only after checking that it is the intended empty or disposable directory. This changes the filesystem, so use elevated privileges:

$ sudo install -d -m 0755 /srv/example
$ findmnt /srv/example

An empty result from findmnt means that path is not currently a mount point. If it already shows a mounted filesystem, stop and choose a different path.

2. Back up and edit /etc/fstab

Make a recoverable copy before editing. The backup remains on the root filesystem and should not be treated as a substitute for a tested rollback plan:

$ sudo cp --preserve=mode,ownership,timestamps /etc/fstab /etc/fstab.before-example
$ sudoedit /etc/fstab

Add one line with six fields separated by spaces or tabs:

UUID=YOUR-UUID  /srv/example  ext4  defaults,nofail  0  2

The first field identifies the source, the second is the target, and the third is the filesystem type. The fourth field contains comma-separated mount options. The final two fields are the dump and filesystem-check values. For ordinary non-root data filesystems, 0 2 is a common arrangement, but choose values that match your filesystem-check policy.

nofail prevents a missing device from making the boot transaction fail. It does not make a wrong UUID safe, and it can hide an unavailable data disk from a quick boot review. Omit it when the mount is a hard requirement and you want boot to report its failure.

Do not add noauto to this boot-mounted example. That option tells mount -a not to mount the entry, which also changes what you should expect from systemd.

3. Validate the file before reloading systemd

Run libmount's verifier first:

$ findmnt --verify
Success, no errors or warnings detected

The exact success wording can vary, but the command must return status 0. Check the status immediately if you need to distinguish a clean result from a warning:

$ printf 'findmnt status: %s\n' "$?"
findmnt status: 0

If validation fails, do not reload or mount yet. Recheck field spacing, the filesystem type, the UUID or label, and whether the target directory exists. A syntactically valid entry can still refer to a disk that is absent or a filesystem that the kernel cannot mount.

4. Regenerate the mount unit

systemd-fstab-generator reads /etc/fstab at boot and when the system manager is reloaded. Reload it now as an administrative operation:

$ sudo systemctl daemon-reload

The generator creates a native mount unit dynamically; it does not permanently write a hand-maintained unit into /etc/systemd/system. The generated output is discarded and recreated on a later reload or re-exec.

Convert the mount path to the unit name systemd uses. The --mount form accepts a path and produces a mount-unit name:

$ systemd-escape --path --suffix=mount /srv/example
srv-example.mount

$ systemctl cat srv-example.mount
# /run/systemd/generator/srv-example.mount
[Unit]
...
[Mount]
What=...
Where=/srv/example
Type=ext4
Options=defaults,nofail
...

The source path and dependency details will differ. The useful checks are that the unit exists, its Where value is the intended target, and its options match the line you reviewed.

5. Mount and verify it

Start the generated unit explicitly. This is the point at which the filesystem is mounted and service state can change:

$ sudo systemctl start srv-example.mount
$ systemctl status --no-pager srv-example.mount
$ findmnt --target /srv/example

A successful status has Active: active (mounted). findmnt should show /srv/example as the target and the expected source and filesystem type. The unit name must match the escaped path exactly; a path containing spaces, for example, will produce a different escaped name.

Do not infer success from the absence of output from systemctl start. If it fails, inspect the unit journal:

$ journalctl -b -u srv-example.mount --no-pager

Common causes are an incorrect UUID, an unavailable device, a missing filesystem driver, a target that is already in use, or an option unsupported by the filesystem. Correct the underlying problem, edit /etc/fstab, run findmnt --verify again, and reload before retrying.

6. Undo the example safely

Stop the mount before removing its configuration. This unmounts the filesystem and may disrupt programs using it, so check findmnt --target /srv/example and close users of the mount first:

$ sudo systemctl stop srv-example.mount
$ sudoedit /etc/fstab
$ sudo systemctl daemon-reload

Remove only the line you added, then verify that the unit is no longer being generated:

$ findmnt --verify
$ systemctl cat srv-example.mount

systemctl cat should report that the unit could not be found. Keep the backup until the replacement configuration has survived a planned reboot or another deliberate test. If the edit made /etc/fstab unusable, restore it with sudo cp --preserve=all /etc/fstab.before-example /etc/fstab, run findmnt --verify, and reload systemd.

7. Understand the generator's less obvious boundaries

The generator also creates swap units from swap entries. The passno field is treated by systemd-fstab-generator as a boolean, so its filesystem-check ordering information is discarded; a checked root filesystem is still checked before other filesystems. Do not expect the numeric ordering from /etc/fstab to become systemd ordering.

Kernel command-line settings can change what the generator processes. fstab=no makes it ignore mounts and swap devices from /etc/fstab; rd.fstab=no applies only in the initrd. These settings are useful for deliberate recovery or image configurations, but adding them casually can make a correct /etc/fstab entry appear to be broken.

Finally, the generator resolves symbolic links in /etc/fstab as far as possible because mount units reject symbolic-link targets. Prefer a real, canonical mount point anyway. If the target does not yet exist when generation runs, the unresolved link target is treated as the final target, which can make a typo surprisingly persistent.