Linux clients often need the same NFS share available at a stable local path after reboot, service start, or the first time a user opens a project directory. An /etc/fstab entry records that remote export as part of the client's filesystem layout so operators do not have to repeat a manual mount command.
An NFS fstab record contains the server export, local mount point, filesystem type, mount options, and the two unused dump and fsck fields. Current Linux NFS client documentation uses nfs in the fstype field and selects a protocol version with an option such as vers=4.2 when the server requires one.
Use a manual mount test before saving the record in /etc/fstab. On a systemd-based client, the entry can create an on-demand automount, avoid early boot delays, and put a timeout around the actual NFS mount attempt when the path is first accessed.
Related: Mount an NFS export on Linux
Related: Mount an NFS export with a systemd mount unit
Related: Automount an NFS export with autofs
$ sudo apt install nfs-common
Use sudo dnf install nfs-utils on RHEL, CentOS Stream, Fedora, and compatible systems.
$ sudo mkdir --parents /mnt/projects
Files already inside /mnt/projects become hidden while the NFS filesystem is mounted there.
$ sudo mount -t nfs -o rw,hard,vers=4.2,proto=tcp files.example.net:/srv/nfs/projects /mnt/projects
Replace files.example.net:/srv/nfs/projects with the server and export path assigned by the NFS server owner. Add server-required options such as sec=krb5p before saving the fstab line.
Related: How to mount an NFS export on Linux
$ findmnt -o TARGET,SOURCE,FSTYPE /mnt/projects TARGET SOURCE FSTYPE /mnt/projects files.example.net:/srv/nfs/projects nfs4
The fstab entry can use nfs while a mounted NFSv4 export appears as nfs4 in the live mount table.
$ ls /mnt/projects README.txt reports
If the mount succeeds but files cannot be read or written, check the server export rule, filesystem permissions, UID/GID mapping, and any security option required by the export.
$ sudo umount /mnt/projects
$ sudoedit /etc/fstab
files.example.net:/srv/nfs/projects /mnt/projects nfs rw,hard,vers=4.2,proto=tcp,_netdev,x-systemd.automount,x-systemd.mount-timeout=30s,x-systemd.idle-timeout=10min 0 0
_netdev tells systemd to treat the entry as a network mount. x-systemd.automount creates an on-demand trigger, x-systemd.mount-timeout=30s limits the mount attempt, and x-systemd.idle-timeout=10min lets systemd release the idle mount later.
A wrong server name, export path, mount point, or option in /etc/fstab can delay boot or fail the first path access. Keep the manual mount test successful before relying on the saved entry.
$ sudo findmnt --verify Success, no errors or warnings detected
$ findmnt --fstab --target /mnt/projects -o TARGET,SOURCE,FSTYPE,OPTIONS TARGET SOURCE FSTYPE OPTIONS /mnt/projects files.example.net:/srv/nfs/projects nfs rw,hard,vers=4.2,proto=tcp,_netdev,x-systemd.automount,x-systemd.mount-timeout=30s,x-systemd.idle-timeout=10min
$ sudo systemctl daemon-reload
$ systemd-escape --path --suffix=automount /mnt/projects mnt-projects.automount
$ sudo systemctl start mnt-projects.automount
On the next boot, systemd creates the same automount unit from /etc/fstab.
$ systemctl is-active mnt-projects.automount active
$ ls /mnt/projects README.txt reports
The first access can pause while the client contacts the NFS server and completes the mount.
$ findmnt -o TARGET,SOURCE,FSTYPE /mnt/projects TARGET SOURCE FSTYPE /mnt/projects files.example.net:/srv/nfs/projects nfs4