Unit -.mount Is Masked: OpenVPN Client Will Not Start

Your service fails before OpenVPN ever runs, and the error talks about a mount unit you never configured. That is the tell: systemd is refusing the whole transaction because the root mount unit is masked, and your VPN profile has not been read yet. The usual cause is a leftover file in the runtime unit directory, not a broken fstab and not a missing certificate. Follow the file first, because it is the cheapest explanation to rule out.

The error names the root mount, not your profile

systemd generates the root mount unit itself from the kernel's mount information, and it names the unit -.mount because a dash stands for the root path. That unit normally exists only in memory and has no file behind it. When the error says it is masked, something has put a unit file where systemd will load it and pointed that file at /dev/null. The mask is a real state, not a typo in the message.

The instance unit fails because its job graph reaches the root mount through ordering and through its own mount requirements. The transaction is refused before the OpenVPN binary is executed, so nothing in the client's configuration can be the cause. That is why changing profiles, certificates or credentials has no effect on this particular failure.

Check the runtime directory before you debug OpenVPN

Look for a file with that exact name in the runtime unit directory, then ask systemd what it thinks the unit is. Both answers are quick, and together they separate a stray file from a genuine mount problem.

ls -l /run/systemd/system/-.mount
systemctl status -.mount
systemctl list-unit-files --state=masked | grep mount

A normal machine has no such file, and the masked list does not contain the root mount. If the first command prints a symlink to /dev/null, the diagnosis is settled. The same directory can hold a tmp.mount mask created by the same tooling, and that produces the same class of failure under a different name. Look at the whole directory rather than only at the name in the error.

ls -la /run/systemd/system/*.mount

If the directory is clean and the unit is still masked, the mask lives somewhere else in the search path, and systemctl cat -.mount will show which file is being loaded.

Delete the file, reload, and start again

Removing the runtime file and reloading the manager is enough, and it touches nothing that came from a package. Reload before starting, because systemd keeps the loaded unit state until it re-reads the directory.

sudo rm -f /run/systemd/system/-.mount /run/systemd/system/tmp.mount
sudo systemctl daemon-reload
systemctl status -.mount
sudo systemctl start [email protected]

Then read the service's own journal instead of assuming the fix worked. Starting cleanly proves only that systemd accepted the unit; the client can still die on a missing profile, an unreachable peer or a certificate that does not validate. Those are ordinary OpenVPN problems that were hidden behind the masked unit. It records which profile loaded and whether the tunnel actually established. If the unit starts and the tunnel does not, you have moved to a different problem, which is progress.

journalctl -u [email protected] -b --no-pager

Because /run is a temporary filesystem, a reboot clears the file as well. That makes a reboot a useful test: if the service works after a reboot and fails again after the next deployment, the file is being baked into the image.

Stop it coming back from the image

A container or virtual-machine template that masks mount units during its build will carry that mask into every clone. Whatever needs the filesystem next breaks, and the message blames the mount instead of the image it came from. Fixing it inside one running instance hides the problem until the next instance is created.

Search the build context for the filename and for the command that creates it, then remove the mask from the template and rebuild. If the mask is genuinely needed during the build, remove it in the same layer that finishes the build, so the shipped image starts clean. Verify on a fresh clone rather than on the machine you repaired by hand. That is the only test that proves the image changed.

The symptom to remember is the mismatch between the error and the thing you were configuring. When systemd complains about a mount while you are starting a VPN client, read the unit name in the message before you read the service name.