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.
Related: How to mount an NFS export on Linux
Related: How to automount an NFS export with autofs
Related: How to create a systemd automount unit
$ sudo apt install nfs-common
Use sudo dnf install nfs-utils on RHEL, CentOS Stream, Fedora, and compatible systems.
$ 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
$ sudo mkdir --parents /mnt/projects
Files already inside /mnt/projects become hidden while the NFS filesystem is mounted there.
$ 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.
$ findmnt -o TARGET,SOURCE,FSTYPE /mnt/projects TARGET SOURCE FSTYPE /mnt/projects files.example.net:/srv/nfs/projects nfs4
$ 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.
$ sudo umount /mnt/projects
$ 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.
$ sudoedit /etc/fstab
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.
$ sudo findmnt --verify Success, no errors or warnings detected
Fix any error that references the new /mnt/projects line before continuing.
$ sudo systemctl daemon-reload
$ 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.
$ 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.
$ ls /mnt/projects README.txt reports
The first access can pause while systemd starts mnt-projects.mount and the client contacts the NFS server.
$ 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.