How to mount an NFS export on Linux

Mounting an NFS export on Linux attaches a remote server directory to a local path so shell commands and applications can use it as a filesystem under that mount point. The risky part is not the mount command itself, but confirming the client package, server path, local directory, and boot behavior before the entry is made persistent.

Linux mounts NFS through the kernel plus distribution client utilities. Ubuntu and Debian provide mount.nfs through nfs-common, while RHEL-family systems provide it through nfs-utils; the server must already export the directory to the client host or network.

Use files.example.net:/srv/nfs/projects as the example export and /mnt/projects as the local mount point. Test a manual mount first, verify the mounted source with findmnt, and only then add an /etc/fstab entry using systemd network-mount options so a reboot or first path access uses the same export.

Steps to mount an NFS export on Linux:

Open a terminal on the Linux client with sudo privileges.
Install the matching NFS client package if mount.nfs 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 already gave the exact export path, test the mount directly and compare any failure with the server-side export list.

Related: How to list NFS exports from a client
Related: How to list NFS exports on a server
Create the empty 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.
```
$ sudo mount -t nfs4 files.example.net:/srv/nfs/projects /mnt/projects
```
Use the server-required type or options when the export is not NFSv4, such as nfs with vers=3 for an older server.

Verify that the mount point uses the expected server 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 files cannot be read or written, check the server export rule, filesystem permissions, UID/GID mapping, and any Kerberos security option required by the export.

Related: How to troubleshoot NFS permission denied errors
Unmount the temporary manual mount before testing the persistent entry.
```
$ sudo umount /mnt/projects
```
Add the export to /etc/fstab.
```
$ sudoedit /etc/fstab
```
```
files.example.net:/srv/nfs/projects /mnt/projects nfs4 rw,_netdev,x-systemd.automount,x-systemd.mount-timeout=30s 0 0
```
_netdev marks the entry as a network mount for systemd ordering, and x-systemd.automount creates an on-demand mount trigger instead of forcing the remote filesystem to mount during early boot.

A wrong server name, export path, or mount point in /etc/fstab can delay boot or fail the first path access. Keep the manual mount test successful before rebooting the client.

Check the /etc/fstab entry for syntax issues.

$ sudo findmnt --verify
Success, no errors or warnings detected

Reload the systemd manager configuration after changing /etc/fstab.
```
$ sudo systemctl daemon-reload
```
Mount the persistent entry by mount point.
```
$ sudo mount /mnt/projects
```

Verify the persistent mount resolves to the same NFS export.

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