After a routine hardware maintenance on our Linux fileserver running OpenSUSE, we encountered persistent NFSv3 mount timeouts from client machines. The server exports remained visible via showmount, but actual mounting attempts would hang indefinitely with kernel messages showing "server not responding, timed out".
Basic connectivity checks confirmed network access:
[root@client ~]# ping ark
PING ark.homebase (10.10.10.2) 56(84) bytes of data.
64 bytes from ark.homebase (10.10.10.2): icmp_seq=1 ttl=64 time=0.067 ms
The export configuration appeared correct:
ark:/etc # cat exports
/mnt/bigraid *(rw,root_squash,insecure,no_subtree_check,sync)
Checking RPC services revealed all required NFS components were running:
ark:/etc/init.d # rpcinfo -p
program vers proto port
100000 2 tcp 111 portmapper
100005 1 udp 37599 mountd
100003 2 udp 2049 nfs
[...]
The key fix involved completely restarting the NFS and RPC services:
ark:/etc/init.d # ./nfsserver stop
Shutting down kernel based NFS server: nfsd statd mountd idmapd done
ark:/etc/init.d # ./portmap stop
Shutting down RPC portmap daemon done
ark:/etc/init.d # ./portmap start
Starting RPC portmap daemon done
ark:/etc/init.d # ./nfsserver start
Starting kernel based NFS server: idmapd
exportfs: Warning: /mnt/bigraid does not support NFS export.
mountd statd nfsd sm-notify done
The warning about /mnt/bigraid does not support NFS export appeared misleading - the export became mountable despite this message. This suggests the filesystem may have needed proper remounting after hardware changes.
To avoid similar issues after future maintenance:
- Consider adding explicit port definitions in /etc/sysconfig/nfs
- Implement firewall rules for NFS ports if enabled
- Verify filesystem consistency before exporting
Example firewall rule for NFSv3:
iptables -A INPUT -p tcp --dport 111 -j ACCEPT
iptables -A INPUT -p tcp --dport 2049 -j ACCEPT
iptables -A INPUT -p tcp --dport 20048 -j ACCEPT
When your NFS client can successfully list exports via showmount -e but fails to mount with timeout errors, we're typically dealing with one of these scenarios:
# Classic symptoms seen in dmesg
[ 2526.676437] nfs: server ark not responding, timed out
[ 2529.183107] nfs: server ark not responding, timed out
Before diving deep, verify basic network functionality:
# Confirm DNS resolution and basic connectivity
ping ark
nslookup ark
# Check if NFS ports are accessible
rpcinfo -p ark
Many NFSv3 issues stem from improper service initialization sequence. Here's the correct restart procedure:
# On the NFS server
service portmap stop
service nfs-common stop
service nfs-kernel-server stop
# Then start in reverse order
service portmap start
service nfs-common start
service nfs-kernel-server start
Even if you think the firewall is off, double-check these critical ports:
# Required ports for NFSv3
Port 111 (portmapper)
Port 2049 (nfsd)
Ports 32764-32769 (typically used for mountd)
The warning message about filesystem support is particularly telling:
exportfs: Warning: /mnt/bigraid does not support NFS export.
This often indicates either:
- Filesystem wasn't properly mounted after hardware maintenance
- Underlying storage issues preventing NFS operations
- Filesystem corruption requiring fsck
For advanced diagnosis, capture the NFS negotiation:
tcpdump -i eth0 -s0 -w nfs_debug.pcap port 111 or port 2049 or port 32764
Look for these key patterns:
- Initial portmapper requests
- MOUNT protocol exchanges
- NFS procedure calls
When standard mounts fail, try these parameters:
mount -t nfs -o soft,timeo=5,retrans=3 ark:/mnt/bigraid /raid
Key options:
soft: Fail instead of hangingtimeo: Shorter timeout periodretrans: Fewer retry attempts
On the NFS server, these logs often reveal the root cause:
/var/log/messages
/var/log/syslog
journalctl -u nfs-server
Look for messages about:
- RPC service registration failures
- Filesystem export errors
- Permission issues