How to automatically mount an NFS export on Linux

An automatic NFS mount lets a Linux client keep a remote export available at a fixed local path without forcing the network filesystem to mount during early boot. This is the right fit when users and jobs expect /mnt/projects to work after startup, but the client should wait until the path is actually opened before contacting the server.

Current systemd systems can create an on-demand automount directly from an /etc/fstab entry. The example uses files.example.net:/srv/nfs/projects as the export, /mnt/projects as the local mount point, and mnt-projects.automount as the generated unit that watches the path.

A manual mount should work before the persistent entry is added. The finished configuration is correct when /etc/fstab validates, the generated automount unit is active and waiting, and the first access to /mnt/projects produces a mounted NFS filesystem from the expected server export.

Steps to automatically mount an NFS export on Linux with systemd:

Open a terminal on the Linux client with sudo privileges.
Install the NFS client utilities if the mount helper is not already available.
```
$ sudo apt install nfs-common
```
Use sudo dnf install nfs-utils on RHEL, CentOS Stream, Fedora, and compatible systems.

Related: How to install an NFS client on Ubuntu
Related: How to install an NFS client on CentOS Stream, RHEL, and Fedora
Confirm the server advertises the export from the client network.
```
$ showmount --exports files.example.net
Export list for files.example.net:
/srv/nfs/projects 192.0.2.0/24
```
Some NFSv4-only servers do not answer showmount. If the server owner gave the exact export path, test the mount directly and compare failures with the server-side export table.

Related: How to list NFS exports from a client
Related: How to list NFS exports on a server
Create the local mount point.
```
$ sudo mkdir --parents /mnt/projects
```
Files already inside /mnt/projects become hidden while the NFS filesystem is mounted there.
Mount the export manually once.
```
$ sudo mount -t nfs4 files.example.net:/srv/nfs/projects /mnt/projects
```
Use nfs plus a version option such as vers=3 only when the server requires an older NFS version.

Verify that the manual mount uses the expected export.

$ findmnt -o TARGET,SOURCE,FSTYPE /mnt/projects
TARGET        SOURCE                               FSTYPE
/mnt/projects files.example.net:/srv/nfs/projects nfs4

List the mounted directory as a user who should have access to the export.
```
$ ls /mnt/projects
README.txt  reports
```
If the mount succeeds but access fails, check export rules, filesystem ownership, UID/GID mapping, and any required Kerberos security option before making the entry persistent.

Related: How to troubleshoot NFS permission denied errors
Unmount the manual test mount.
```
$ sudo umount /mnt/projects
```
Get the generated systemd automount unit name for the mount point.
```
$ systemd-escape --path --suffix=automount /mnt/projects
mnt-projects.automount
```
systemd derives unit names from mount paths. The matching mount unit for this path is mnt-projects.mount.
Open /etc/fstab for editing.
```
$ sudoedit /etc/fstab
```
Add the NFS export entry.
```
files.example.net:/srv/nfs/projects /mnt/projects nfs4 rw,_netdev,x-systemd.automount,x-systemd.idle-timeout=5min,x-systemd.mount-timeout=30s 0 0
```
_netdev marks the entry as a network mount. x-systemd.automount creates the on-demand trigger, x-systemd.idle-timeout=5min lets systemd unmount it after idle time, and x-systemd.mount-timeout=30s limits how long the first access waits for the server.

Add nofail only when the export is optional for this client. A critical application path should fail loudly if the server export cannot mount.
Verify the /etc/fstab syntax before reloading systemd.
```
$ sudo findmnt --verify
Success, no errors or warnings detected
```
Fix any error that references the new /mnt/projects line before continuing.
Reload the systemd manager so it regenerates units from /etc/fstab.
```
$ sudo systemctl daemon-reload
```
Start the generated automount unit.
```
$ sudo systemctl start mnt-projects.automount
```
The automount unit is the trigger. Starting it should not mount the NFS export until a process accesses /mnt/projects.
Confirm the automount trigger is active and waiting.
```
$ systemctl show -p ActiveState -p SubState mnt-projects.automount
ActiveState=active
SubState=waiting
```
Use sudo systemctl status mnt-projects.automount for fuller service output when the state is not active and waiting.
Access the path to trigger the NFS mount.
```
$ ls /mnt/projects
README.txt  reports
```
The first access can pause while systemd starts mnt-projects.mount and the client contacts the NFS server.
Verify that the path is mounted from the expected export.
```
$ findmnt -o TARGET,SOURCE,FSTYPE /mnt/projects
TARGET        SOURCE                               FSTYPE
/mnt/projects files.example.net:/srv/nfs/projects nfs4
```
If the path does not mount, inspect both generated units with journalctl -u mnt-projects.automount -u mnt-projects.mount -b and confirm the manual mount still works.

Author: Mohd Shakir Zakaria
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.