NFS Mount Hangs: Diagnosis, Recovery and Safe Unmount Options

An unavailable NFS server can make harmless-looking commands such as df, ls or a monitoring probe block. The first recovery rule is to stop touching the mount path while collecting evidence. Query the kernel’s mount tables and the network path before starting more filesystem operations.

Identify the mount without traversing it

grep ' nfs' /proc/self/mounts
grep -F '/mnt/archive' /proc/self/mountinfo
nfsstat -m

nfs01:/export/archive /mnt/archive nfs4 rw,relatime,vers=4.2,hard,proto=tcp,timeo=600,retrans=2 0 0

A default or explicit hard mount retries NFS requests indefinitely. That protects data integrity during a temporary outage but leaves callers waiting while the server is unreachable. For TCP, timeo=600 is measured in deciseconds and represents 60 seconds, not ten minutes.

Separate DNS, routing and NFS service checks

getent ahosts nfs01
ip route get 192.0.2.40
ping -c 2 192.0.2.40
nc -vz -w 3 192.0.2.40 2049

Failed ICMP does not prove that NFS is down because firewalls may drop ping. NFSv4 normally uses TCP 2049. NFSv3 can also depend on rpcbind, mountd and additional RPC services:

rpcinfo -p 192.0.2.40

If DNS returns several addresses, verify which endpoint the mounted client is using. A healthy node behind the same name does not recover a transport session tied to another address.

Find tasks blocked on the mount

ps -eo state,pid,ppid,wchan:32,etime,comm,args | awk '$1 ~ /^D/'
sudo journalctl -k --since '-20 min' --no-pager | grep -iE 'nfs|rpc|blocked|not responding'

Wait channels beginning with NFS or RPC symbols support the diagnosis. Repeated SIGKILL attempts do not release an uninterruptible kernel wait; the signal is handled only after the I/O path returns.

Check the server and its backing storage

sudo systemctl status nfs-server --no-pager
sudo exportfs -v
sudo ss -lntup | grep ':2049'
sudo journalctl -u nfs-server --since '-20 min' --no-pager

A running NFS daemon can still be unable to answer when the exported filesystem, RAID, LVM, SAN path or another upstream network filesystem is stalled. Inspect D-state tasks and the kernel log on the server as well as on the client.

Prefer a normal unmount after I/O recovers

Stop applications in their documented order and try:

sudo umount /mnt/archive

If it reports target is busy after the share is responsive, find nested mounts, open files and working directories:

findmnt -R /mnt/archive
sudo fuser -vm /mnt/archive

Force and lazy unmount have different consequences

Use the absolute mount path, not a symlink. Path canonicalization can itself call stat or readlink on the unavailable filesystem. A successful lazy detach does not confirm that buffered writes reached the server.

Do not convert every hard mount to soft

The Linux NFS manual warns that soft and softerr timeouts can cause silent data corruption in some situations. They return an error after the configured retransmissions instead of retrying indefinitely. That trade-off may be acceptable for reproducible read-only data, but it is very different for databases, mail stores, VM images or backups.

Test how the application handles I/O errors before changing persistent mount policy. The legacy intr option is ignored on kernels newer than 2.6.25 and does not restore a universal “interrupt this mount” behavior.

Verify recovery without creating another hang

findmnt /mnt/archive
ps -eo state,pid,wchan:32,comm | awk '$1 ~ /^D/'
sudo journalctl -k --since '-5 min' --no-pager | grep -iE 'nfs|rpc|not responding'
timeout 5 stat /mnt/archive

The path is ready for controlled reuse when the expected server and options are mounted, no new D-state callers appear and the bounded stat completes. Old blocked PIDs that remain after service recovery need their own wait-channel and kernel-stack review.

References: Linux nfs(5) and util-linux umount(8).