Creating And Managing Systemd Mount Units On Linux

A systemd mount unit defines how Linux should attach a filesystem and when that attachment should occur during boot. It can replace a traditional /etc/fstab entry when you need clearer dependencies, service-specific ordering, or easier control with systemctl.

This approach is useful on RHEL, CentOS Stream, Fedora, and compatible distributions. Common examples include local data volumes, NFS exports, encrypted disks, application directories, and backup storage mounted beneath /srv, /opt, or /var/lib.

A mount unit is managed like other systemd resources: it can be started, stopped, enabled, disabled, inspected, and logged. That makes filesystem administration more predictable than relying on a long, manually maintained boot script.

Australian administrators may use this pattern for workloads hosted in Sydney or Melbourne data centres, or for remote offices connected through NBN services. Maintenance windows should account for AEST and AEDT changes, while systems holding personal information should be managed with the Australian Privacy Principles under the Privacy Act 1988.

Understanding Mount Unit Names

The filename must match the escaped path where the filesystem will be attached. For /srv/projects, the unit is normally srv-projects.mount; for a path containing unusual characters, use systemd’s escaping utility rather than guessing:

systemd-escape --path --suffix=mount /srv/projects

The mount directory must exist before the unit starts. Create it with suitable ownership and permissions:

sudo mkdir -p /srv/projects
sudo chmod 0750 /srv/projects

The mount unit should be placed in /etc/systemd/system/ for local administration. Files under /usr/lib/systemd/system/ are generally managed by packages and may be overwritten during updates.

Writing A Mount Unit

A local XFS volume can use a unit such as /etc/systemd/system/srv-projects.mount:

[Unit]
Description=Projects filesystem
After=local-fs-pre.target
Before=local-fs.target

[Mount]
What=/dev/mapper/projects
Where=/srv/projects
Type=xfs
Options=defaults

[Install]
WantedBy=local-fs.target

What identifies the block device, logical volume, UUID, or remote export. Where must exactly match the unit filename’s path. Type should match the filesystem, while Options accepts normal mount options such as noatime, nosuid, or nodev where appropriate.

For stable local storage, a filesystem UUID is often safer than /dev/sdb1, because device names can change after hardware or virtual machine modifications. Retrieve it with lsblk -f or blkid, then use a value such as UUID=1a2b-3c4d in What.

Enabling And Testing

After creating or changing a unit, make systemd reread its configuration and start the mount:

sudo systemctl daemon-reload
sudo systemctl start srv-projects.mount
sudo systemctl enable srv-projects.mount

The enable command makes the unit start during boot through local-fs.target; it does not start the unit immediately. enable --now performs both actions, but testing with separate commands can make failures easier to isolate.

Confirm the result with:

systemctl status srv-projects.mount
findmnt /srv/projects
mountpoint /srv/projects

For a clean verification, write a small file, unmount the filesystem, and start it again. Never test against a directory containing unsaved application data. A failed mount can leave services writing into the underlying empty directory instead of the intended volume.

Handling Network And Credentials

An NFS mount might use the following configuration:

[Unit]
After=network-online.target
Wants=network-online.target

[Mount]
What=nas.example.com:/exports/projects
Where=/srv/projects
Type=nfs
Options=_netdev,hard,timeo=600,retrans=2

[Install]
WantedBy=multi-user.target

The _netdev option marks the filesystem as network-dependent. For CIFS, avoid placing plain-text passwords in the unit. Store credentials in a root-owned file such as /etc/samba/projects.cred, set it to mode 0600, and reference it with credentials=/etc/samba/projects.cred.

Network mounts should include realistic timeout behaviour. A remote share in a Brisbane office may be unavailable during an ISP outage, while a Sydney-hosted service may remain online. Use automount when an application does not need the share immediately at boot, reducing delays caused by unavailable storage.

Troubleshooting Dependencies

Inspect detailed unit relationships with:

systemctl list-dependencies srv-projects.mount
systemctl show srv-projects.mount
journalctl -u srv-projects.mount -b

Errors such as “Where= setting doesn’t match unit name” usually indicate that the directory path and filename do not correspond. Permission errors may involve filesystem ownership, mount options, SELinux contexts, or an NFS export policy. On RHEL and Fedora, check recent audit messages with ausearch -m AVC -ts recent.

A mount helper can also appear stalled while waiting for storage or a network response. Understanding process waiting and resumption can help when investigating such behaviour; these thread suspension notes provide related programming background. Always inspect the systemd journal before killing a process, especially on production hosts.

Maintaining And Removing Units

Use systemctl stop to detach a filesystem after stopping applications that use it. Then disable it if it should no longer start at boot:

sudo systemctl stop srv-projects.mount
sudo systemctl disable srv-projects.mount

Remove or archive the unit only after checking dependencies with systemctl list-dependencies --reverse srv-projects.mount. If another service still expects the path, stopping the mount can cause data to be written to the underlying directory.

System updates can restart services or change package-managed unit files. On RHEL systems, automated DNF updates should be scheduled alongside storage checks and an approved maintenance window. This is especially important for Australian businesses coordinating outages across AEST and AEDT or meeting internal change-control requirements.

A practical final check is to run sudo systemctl daemon-reload && sudo systemctl enable --now srv-projects.mount, then verify the result with findmnt /srv/projects.