Fix Linux NFS Server Not Responding Timeout Errors (2026)

The NFS server is hanging because the kernel’s NFS client is unable to communicate with the rpc.statd daemon on the server, specifically during its initial handshake.

Here’s what’s actually happening: When an NFS client mounts a share, it needs to establish a lock ownership with the server. This is handled by rpc.statd. If rpc.statd isn’t running, or if there’s a network issue preventing the client from reaching it, the client will eventually time out, leading to the "server not responding" errors.

Common Causes and Fixes:

rpc.statd Not Running on Server: This is the most frequent culprit. The rpc.statd service is essential for NFS locking.
- Diagnosis: On the NFS server, run systemctl status rpcbind and systemctl status nfs-statd. You should see them as active (running). If not, check their status.
- Fix: Start and enable the services:
```
sudo systemctl start rpcbind
sudo systemctl enable rpcbind
sudo systemctl start nfs-statd
sudo systemctl enable nfs-statd
```
- Why it works: This ensures the necessary RPC daemons are active and will start on boot, allowing the NFS client to register its lock requests.
Firewall Blocking RPC Ports: NFS uses a range of dynamic ports for its services, including rpc.statd. If the firewall on the server or client is too restrictive, these ports can be blocked.
- Diagnosis: Check the firewall status on the NFS server (sudo firewall-cmd --list-all or sudo ufw status). Look for rules blocking ports associated with NFS (usually 2049 for NFS, and a range for rpc.statd, mountd, lockd). You can also check /etc/sysconfig/nfs (RHEL/CentOS) or /etc/default/nfs-kernel-server (Debian/Ubuntu) for static port configurations if they exist.
- Fix: Open the necessary ports. For firewalld:
```
sudo firewall-cmd --add-service=nfs --permanent
sudo firewall-cmd --add-service=rpc-bind --permanent
sudo firewall-cmd --add-service=mountd --permanent
sudo firewall-cmd --reload
```
  If rpc.statd is using a dynamic port and you want to assign a static one (e.g., 32765): Edit /etc/sysconfig/nfs (RHEL/CentOS) or /etc/default/nfs-common (Debian/Ubuntu) and add/modify STATDARG="-p 32765". Then restart nfs-statd and rpcbind. Finally, add the static port to the firewall:
```
sudo firewall-cmd --add-port=32765/tcp --permanent
sudo firewall-cmd --add-port=32765/udp --permanent
sudo firewall-cmd --reload
```
- Why it works: Explicitly allowing traffic on the RPC ports that rpc.statd and other NFS daemons use ensures the client can reach them.
SELinux Preventing Access: SELinux can be overly strict and block legitimate communication between NFS components.
- Diagnosis: Check SELinux status: sestatus. If it’s enforcing, check the audit logs for denials related to NFS or RPC: sudo ausearch -m avc -ts recent. Look for entries mentioning rpc.statd, nfsd, or mountd.
- Fix: Install the nfs-utils-lib package if it’s missing (common on some minimal installs) and then set the appropriate SELinux booleans:
```
sudo setsebool -P nfs_export_all_rw 1
sudo setsebool -P nfs_mount_all_rw 1
sudo setsebool -P use_nfs_home_dirs 1
```
  If specific denials persist, you might need to create custom SELinux policies, but the above booleans cover most common scenarios.
- Why it works: SELinux booleans allow specific operations for services. Enabling these booleans grants the NFS daemons the necessary permissions to interact and perform their functions, bypassing denials.
Incorrect /etc/exports Configuration: While less common for rpc.statd issues directly, an improperly formatted or incomplete /etc/exports can sometimes lead to unexpected behavior in NFS service startup.
- Diagnosis: Review the /etc/exports file on the server. Ensure it follows the correct syntax: /path/to/share client(options). Check for typos or missing spaces.
- Fix: Correct any syntax errors in /etc/exports. After editing, reload the exports:
```
sudo exportfs -ra
```
- Why it works: A valid /etc/exports file is required for the nfs-server service to correctly export shares and for mountd to know what to serve.
Network Connectivity Issues (between Server and Client): Basic network problems can prevent communication.
- Diagnosis: From the client, try pinging the NFS server. Then, from the client, try to connect to the NFS server’s RPC port that rpc.statd is listening on (e.g., 32765 if statically configured): telnet <nfs_server_ip> 32765 or nc -zv <nfs_server_ip> 32765.
- Fix: Resolve underlying network issues (e.g., incorrect IP addresses, routing problems, switch configuration). Ensure the client can resolve the server’s hostname if using hostnames.
- Why it works: Reliable network communication is fundamental for any client-server interaction, including NFS.
Stale NFSv4 State: In rare cases, especially after reboots or network interruptions, the NFSv4 state can become inconsistent, leading to lock issues.
- Diagnosis: Check the status of the nfs-client.target on the client.
- Fix: Restart the NFS client services on the client machine:
```
sudo systemctl restart nfs-client.target
```
  On the server, you might need to clear stale lock files located in /var/lib/nfs/statd/. Caution: This can disrupt existing file locks, so do this during a maintenance window.
```
sudo systemctl stop nfs-statd
sudo rm -f /var/lib/nfs/statd/sm/*
sudo rm -f /var/lib/nfs/statd/lock/*
sudo systemctl start nfs-statd
```
- Why it works: This forces the NFS client and server to re-establish their communication channels and potentially re-register lock ownership, clearing out any corrupted or stale state information.

After applying these fixes, you should be able to mount your NFS shares without encountering "server not responding" errors related to rpc.statd.

The next error you’ll likely hit if you haven’t configured it is a Permission denied error when trying to write to the NFS share, indicating that the export options or filesystem permissions are not set up correctly.