NFS Troubleshoot: Fixing "Hanging on Mount" Issues

[dduardo]

I have an NFS server which seems to be talking to the client, but it just hangs during the mout process. I can see the two services exchanging data with ethereal. I'm pretty sure exports, hosts.deny, hosts.accept are all right. Anyone have a clue what might be going on?

Btw, I can mount the share locally on the server machine.

 

[graphic7]

Can you post your exports file?

hosts.deny and hosts.accept should have no effect unless you are using tcpwrappers. The exports file manages access to NFS, however, portmapper is sometimes wrapped in tcpwrappers.

Also, make sure you have portmapper running.

I could be wrong about hosts.* actually mattering, given I haven't touched a Linux system in quite awhile, let alone mess with it's ripped off NFS implementation.

 

[dduardo]

/etc/exports:
/home/share 192.168.1.192(rw,sync) 192.168.1.191(rw,sync)

/etc/hosts.deny:
portmap:ALL
lockd:ALL
mountd:ALL
rquotad:ALL
statd:ALL

/etc/hosts.allow
portmap:192.168.1.191, 192.168.1.192
lockd: 192.168.1.191, 192.168.1.192
rquotad: 192.168.1.191, 192.168.1.192
mountd: 192.168.1.191, 192.168.1.192
statd: 192.168.1.191, 192.168.1.192

/etc/fstab

192.168.1.191:/home/share /mnt/share nfs rw,hard,intr 0 0

This is what ethereal is capturing:

0.000000 192.168.1.191 -> 192.168.1.192 SSH Encrypted request packet len=64
0.038870 192.168.1.192 -> 192.168.1.191 TCP ssh > 32907 [ACK] Seq=0 Ack=64 Win=7904 Len=0 TSV=106662 TSER=7584188

bash-2.05b$ /usr/sbin/rpcinfo -p
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 32781 status
100024 1 tcp 32906 status
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100021 1 udp 32782 nlockmgr
100021 3 udp 32782 nlockmgr
100021 4 udp 32782 nlockmgr
100005 1 udp 626 mountd
100005 1 tcp 629 mountd
100005 2 udp 626 mountd
100005 2 tcp 629 mountd
100005 3 udp 626 mountd
100005 3 tcp 629 mountd

 

[graphic7]

Try mounting it without hard and initr.

As a precautinary, put ALL's in /etc/hosts.allow.

Also, NFS should be logging to a syslog facility. Watch dmesg and /var/log/syslog; they should give some insight into what's going wrong.

 

[dduardo]

I tried the first two things, but they didn't work

dmesg:

IN-interface1:IN=eth0 OUT= MAC=00:00:00:00:d7:98:00:06:25:04:62:9a:08:00 SRC=192.168.1.192 DST=192.168.1.191 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=3298 DF PROTO=TCP SPT=795 DPT=111 WINDOW=5840 RES=0x00 SYN URGP=0

Syslog:

Dec 20 19:44:01 gentoo1 rpc.mountd: authenticated mount request from 192.168.1.192:829 for /home/share (/home/share)

It looks like my machine is capturing the request, but not doing anything with it.

 

[graphic7]

I tried the first two things, but they didn't work

dmesg:

IN-interface1:IN=eth0 OUT= MAC=00:00:00:00:d7:98:00:06:25:04:62:9a:08:00 SRC=192.168.1.192 DST=192.168.1.191 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=3298 DF PROTO=TCP SPT=795 DPT=111 WINDOW=5840 RES=0x00 SYN URGP=0

Syslog:

Dec 20 19:44:01 gentoo1 rpc.mountd: authenticated mount request from 192.168.1.192:829 for /home/share (/home/share)

It looks like my machine is capturing the request, but not doing anything with it.

This might be a long shot, but I don't see nfsd running. I just see nfs, and that's usually the client.

Typically, mountd just captures the RPC requests, and passes them onto nfsd. Because of my unfamiliarity with the Linux NFS implementation, I'm not sure what all mountd does, but search around for nfsd.

 

[dduardo]

I'm pretty sure I followed the documentation to the letter. My only guess now is that the nfs-utils I'm using is borked. I'm going to try an older version

 

[dduardo]

O great, the ssh daemon on the other computer died. I guess i'll have to try again tommorow.