NFS Behind a VPN: Boot Mount or On-Demand Automount?

Two configurations solve the same problem and fail in opposite directions. Mounting the share at boot gives every service a filesystem that is either there or a reason why the boot stalled. An on-demand automount gives the machine a fast boot and hands the wait to whoever touches the path first. Behind a VPN the second is usually the better trade, and the reason is that the tunnel imposes an ordering the boot sequence cannot see.

Boot mount versus automount

A boot mount is simple to reason about. The filesystem target waits for the mount, services that declare a dependency on it start afterwards, and if the server is unreachable the machine either waits or fails depending on the options. Everything downstream inherits that single decision.

An automount inverts that. The path exists immediately, the real mount happens when something opens it, and services that start early do not block on a tunnel that has not come up yet.

The comparison comes down to who should absorb the delay. A workstation that needs the share before the user can work should probably wait. A laptop that boots in a bag, or a server whose share is optional, should not.

Neither option fixes a missing route. Both simply decide when the failure is observed.

The fstab line, option by option

Assume an existing OpenVPN client instance is [email protected], the server is files.corp.example and the mount point is /mnt/work. Replace all three with the authorised values from your own site. One workable line looks like this:

files.corp.example:/export/work /mnt/work nfs _netdev,nofail,x-systemd.automount,[email protected],x-systemd.mount-timeout=30s 0 0

_netdev marks the mount as needing networking, and it names no tunnel at all. nofail keeps the share optional for the normal filesystem target. x-systemd.automount creates the on-demand trigger instead of mounting immediately.

x-systemd.requires= is the part that ties the mount attempt to the VPN unit, and it belongs on the mount operation rather than on the trigger. Putting broad ordering on the automount unit itself is how people create cycles that systemd then complains about in language nobody reads twice.

x-systemd.mount-timeout=30s bounds the initial mount command. It does not bound anything that happens afterwards, which is the single most common misunderstanding about this option.

What started does not mean

Check what active means for the VPN unit you named. A tunnel service can report itself started before the route to the file server exists or before the private name resolves, and ordering after it then buys you nothing. This is the gap where almost every failed attempt lives. It is also invisible unless you look at the route and the resolver rather than the unit state.

Use the connection owner's own readiness signal as an additional prerequisite where one exists. A fixed sleep is a guess that works on your desk and fails on a slower network or after a reconnect.

Inspect the generated units for the example path: mnt-work.automount and mnt-work.mount. After a reviewed fstab change, reload systemd and manage those units directly rather than running a blanket mount command that exercises unrelated entries.

One more caveat belongs here. A service that touches /mnt/work at startup still triggers the mount and still waits for it, so marking the share optional does not make every application patient.

After the mount is a different failure

Once NFS is mounted, the filesystem's retry and recovery behaviour governs what a later outage does to a read or a write. The mount timeout you set has no influence on that.

A soft mount shortens some waits and changes error semantics, with data-integrity consequences that are easy to overlook when the goal is a faster boot. Choosing it to win two seconds of startup is rarely a good trade. If the requirement is really a bounded operation during an outage, that is an application-level decision, not an fstab flag.

Decide what should happen to a process that is mid-write when the tunnel drops, and write it down. That answer is more useful than any option string.

Test four states, not one

Normal startup with the tunnel available is the easy case and proves almost nothing. It confirms that the string is spelled correctly and nothing more. Test the first access with the VPN absent, then the recovery when it comes up, then a controlled outage after a successful mount.

Four states, four observations, and the notes go next to the fstab entry. The next person inherits behaviour instead of a configuration they have to reverse engineer.