How to troubleshoot NFS mount timeouts

An NFS mount timeout means the client started the mount request but did not receive the network or server response needed to attach the export. The cause can sit in name resolution, routing, TCP port 2049, a stopped server unit, a firewall rule, or the older RPC services used by NFSv3.

Modern Linux clients mount NFSv4 over TCP 2049 when the server supports it. NFSv3 and mixed-version environments can also involve rpcbind, mountd, rpc.statd, and lockd, so a successful ping does not prove that the mount path is open.

Retry options such as hard, soft, timeo, and retrans change how mounted NFS operations wait after requests have started. systemd timeout options decide how long a boot or fstab mount job waits for the mount command, but they do not fix an unreachable server, blocked port, missing service, or export policy mismatch.

Steps to troubleshoot NFS mount timeouts:

Reproduce the failure with the same server, export path, mount point, and NFS options.
```
$ sudo mount -t nfs -o vers=4.2,proto=tcp files.example.net:/srv/nfs/projects /mnt/projects
mount.nfs: Connection timed out
```
Use the version and security options that failed in the original mount. For an older server, use vers=3 only when the export is intentionally NFSv3.
Resolve the server name from the client.
```
$ getent hosts files.example.net
192.0.2.10      files.example.net
```
No output means the client cannot resolve the server name. Fix DNS, /etc/hosts, or the search-domain choice before changing NFS options.
Check the route to the resolved server address.
```
$ ip route get 192.0.2.10
192.0.2.10 via 192.0.2.1 dev ens18 src 192.0.2.25 uid 1000
    cache
```
Network is unreachable, No route to host, or the wrong interface points to routing, VPN, VLAN, or gateway policy rather than an NFS daemon problem.
Test the NFSv4 TCP port from the client.
```
$ nc -vz -w 5 files.example.net 2049
nc: connect to files.example.net (192.0.2.10) port 2049 (tcp) timed out: Operation now in progress
```
For a strict NFSv4 server, TCP 2049 is the main client path. A timeout usually points to a firewall or dropped route; Connection refused points to no listener on the server address.
Check the NFS server unit on the server.
```
$ sudo systemctl is-active nfs-server
active
```
Current Ubuntu and Debian packages may also expose nfs-kernel-server.service, but nfs-server.service is the common systemd unit name across current Linux packages.

Related: How to check NFS server status in Linux
Confirm that the server is listening on the NFS port.
```
$ ss -ltn 'sport = :2049'
State  Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0      64           0.0.0.0:2049      0.0.0.0:*
LISTEN 0      64              [::]:2049         [::]:*
```
If the service is active but nothing listens on 2049, inspect the server journal and /proc/fs/nfsd/versions before changing client mount options.
Confirm that the active export table includes the expected client network.
```
$ sudo exportfs -v
/srv/nfs/projects
		192.0.2.0/24(sync,wdelay,hide,no_subtree_check,sec=sys,rw,root_squash,no_all_squash)
```
If the export path, client selector, or sec= value is missing, reload or correct the export before changing firewall or client retry settings.

Related: How to list NFS exports on a server
Related: How to reload NFS exports
Open TCP 2049 for the client network on a UFW-managed server when the port test timed out and the server is listening.
```
$ sudo ufw allow proto tcp from 192.0.2.0/24 to any port 2049 comment 'NFSv4 from client subnet'
Rule added
```
Use the firewall tool that manages this server. NFSv3 clients may also need rpcbind, mountd, and fixed lock or status ports instead of only TCP 2049.
Related: How to allow NFS server traffic through UFW
Related: How to allow NFS server traffic through firewalld

Retest the NFS port from the client.

$ nc -vz -w 5 files.example.net 2049
Connection to files.example.net (192.0.2.10) 2049 port [tcp/nfs] succeeded!

Check RPC and export visibility when NFSv3 or mixed-version clients are in scope.
```
$ showmount --exports files.example.net
Export list for files.example.net:
/srv/nfs/projects 192.0.2.0/24
```
A strict NFSv4 server may not answer showmount because NFSv4 does not use the separate MOUNT protocol. Use the known export path and a real mount retry for NFSv4-only servers.

Related: How to list NFS exports from a client
Related: How to list NFS exports on a server
Retry the original mount after the blocked layer is fixed.
```
$ sudo mount -t nfs -o vers=4.2,proto=tcp files.example.net:/srv/nfs/projects /mnt/projects
```
If the error changes to access denied by server while mounting, the network path is now working and the remaining issue is the export rule, client selector, security option, or filesystem permission.
Related: How to troubleshoot NFS permission denied errors

Verify that the client mounted the expected export.

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

Check persistent mount timeout settings only after the manual mount path works.
```
$ findmnt --verify
Success, no errors or warnings detected
```
For /etc/fstab entries managed by systemd, x-systemd.mount-timeout= controls how long systemd waits for the mount command to finish. NFS timeo and retrans control NFS request retries after the mount exists and should be tuned separately.
Related: How to configure hard or soft NFS mount options