Re: mount.nfs internal error

Allen Kistler wrote:
Philip wrote:
I have Fedora 9 and of recently my nfs mounting is failing. I have tried the fedoraforum and linuxquestions, but have yet to get any real advice.

Whenever I try to mount from a server on my LAN, I get the internal error:

[root@walden5 /]# mount.nfs walden4.local:/opt2 /opt2 -v
mount.nfs: timeout set for Thu Jan 29 10:46:06 2009
mount.nfs: text-based options: 'addr=192.168.1.140'
mount.nfs: internal error

This was working and I suspect some update has broken it. I just do not know where to start given the lack of detail in the "internal error" message. I have searched around and I can say

* I do not have iptables or ip6table running. No firewall
* rpcbind is running on the nfs client and server
* Adding a -o udp to the mount still fails
* I can mount.nfs the directory locally to the server machine (walden4), the remote clients (walden5) fails.

Any suggestions would be appreciated. Any ideas how to troubleshoot beyond the "internal error" also appreciated. Here is the server rpcinfo below:

[snip]

Things to try in order:

You say you have F9. Are both walden4 and walden5 F9? I've heard some rumblings that F9 and F10 clients don't work and play well with older versions of servers.

All two clients and the one server are F9. Both clients have the same internal error problem. Both were working previously (2-3 weeks ago).


How sure are you that you don't have netfilter rules?
"/etc/init.d/iptables stop" will flush the rules if you've got any. (IPv6 netfilter rules are mostly irrelevant. Linux does not yet support nfs over IPv6, although rpcbind does support IPv6 queries.)

I have the the iptables service disabled everywhereas they all reside on my LAN behind a NAT router (WRT54G). But just in case:

[root@walden5 ~]# /etc/init.d/iptables stop
[root@walden5 ~]# mount -v -t nfs walden4.local:/opt2 /opt2
mount.nfs: timeout set for Sun Feb 1 12:24:52 2009
mount.nfs: text-based options: 'addr=192.168.1.140'
mount.nfs: internal error

Did not work.


There was an F9/F10 update that broke nfs a while ago, but it was fixed. Are you sure you've got the latest packages and not the broken ones? I believe nfs-utils-1.1.2-10.fc9.i386 and nfs-utils-lib-1.1.1-5.fc9.i386 are the latest. (I seem to recall that nfsd wouldn't even run when it was broken, so it's probably not that in your case.)

Yes I saw that, and they were updated around Jan 25. I actually suspect this patch broke my nfs (It appears to have stopped working around this time. Since I only use it on occasion, I cannot really tell). The same patch on both clients and the server. It is interesting to note, that I can self-mount the nfs to server, I just cannot mount the nfs to the clients.

[[root@walden5 ~]# rpm -qa | grep nfs-utils
nfs-utils-1.1.2-10.fc9.i386
nfs-utils-lib-1.1.1-5.fc9.i386

[root@walden4 ~]# rpm -qa | grep nfs-utils
nfs-utils-lib-1.1.1-5.fc9.i386
nfs-utils-1.1.2-10.fc9.i386


On walden5, what do you get for "rpcinfo walden4.local"?

[root@walden5 ~]# rpcinfo -p walden4.local
program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 40204 status
100024 1 tcp 32986 status
100011 1 udp 759 rquotad
100011 2 udp 759 rquotad
100011 1 tcp 762 rquotad
100011 2 tcp 762 rquotad
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100021 1 udp 44792 nlockmgr
100021 3 udp 44792 nlockmgr
100021 4 udp 44792 nlockmgr
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100021 1 tcp 56425 nlockmgr
100021 3 tcp 56425 nlockmgr
100021 4 tcp 56425 nlockmgr
100005 1 udp 51481 mountd
100005 1 tcp 59309 mountd
100005 2 udp 51481 mountd
100005 2 tcp 59309 mountd
100005 3 udp 51481 mountd
100005 3 tcp 59309 mountd


What have you got for /etc/hosts.allow and /etc/hosts.deny on walden4?

hosts.allow is empty (just comments)
hosts.deny does not include the LAN and only denies sshd access (I use denyhosts to prevent ssh hacking).

[root@walden4 ~]# grep wald /etc/hosts.deny
[root@walden4 ~]# grep 192 /etc/hosts.deny
httpd: 221.192.199.36
# DenyHosts: Tue Jan 13 09:00:41 2009 | sshd: 61.131.81.192
sshd: 61.131.81.192
# DenyHosts: Sun Jan 18 12:20:45 2009 | sshd: 189.14.192.80
sshd: 189.14.192.80


FWIW, the only thing you need on the client is rpcbind. On the server, you need nfsd, lockd, mountd, and statd. You only need quotad on the server if you're enforcing quotas, but it doesn't hurt even if you're not enforcing them.

Thanks, I will not pursue the missing nlockmgr lead on the client.
.

Relevant Pages

  • SuSE 10.0 NFS vs. Firewall
    ... I am attempting to get NFS working; both client and server are running ... 3/min burst 5 LOG level warning tcp-options ip-options prefix ... 3/min burst 5 state NEW udp dpt:sunrpc LOG level warning tcp-options ... 3/min burst 5 state NEW tcp dpt:sunrpc LOG level warning tcp-options ...
    (alt.os.linux.suse)
  • Re: Firewall problems with NFS
    ... It seems to only allow use as an NFS client, since that worked fine when I tested it. ... U was surprised to see that TCP with tcp_adv_win_size=5 and rsize=8192 was as fast as UDP, ... 100005 1 udp 841 mountd ...
    (Fedora)
  • Trying to get NFS working with FreeBSD & OS X
    ... NFS client on a Mac OS X box. ... 100000 4 tcp 111 portmapper ... 100000 4 udp 111 portmapper ... 100021 0 udp 617 nlockmgr ...
    (comp.unix.bsd.freebsd.misc)
  • Trouble making NFS work with Mac OS X
    ... NFS client on a Mac OS X box. ... 100000 4 tcp 111 portmapper ... 100000 4 udp 111 portmapper ... 100021 0 udp 617 nlockmgr ...
    (freebsd-net)
  • Re: NFS errors
    ... My computer uses another server to boot and run with NFS root. ... 100000 2 tcp 111 portmapper ... 100000 2 udp 111 portmapper ...
    (Linux-Kernel)