You are not logged in.
Hi everybody,
so, I'm trying to mount an NFS share from a server at work (with Ip NFSIP).
The general problem is as follows:
# mount -vv -t nfs NFSIP:/home/dberger /media/nfs
mount.nfs: timeout set for Thu May 31 10:03:38 2012
mount.nfs: trying text-based options 'vers=4,addr=NFSIP,clientaddr=PRIVIP'
mount.nfs: mount(2): Operation not permitted
mount.nfs: trying text-based options 'addr=NFSIP'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying NFSIP prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying NFSIP prog 100005 vers 3 prot UDP port 983
mount.nfs: Protocol not supportedrpcbind, nfs-commons is started.
Everybody else around me uses the server (as homedirs) on a daily basis.
My arch linux is a fresh install, up to date.
The guy next to me uses gentoo and has similar versions and it works for him (with my credentials, ...).
In particular I run
mount.nfs: (linux nfs-utils 1.2.6)
rpcbind 0.2.0-8and left the standard /etc/conf.d/nfs-common.conf
(I tried enabling idmapd, but no change)
The server seems accessible:
# rpcinfo -p NFSIP
program vers proto port service
100000 2 tcp 111
100000 2 udp 111
100021 1 udp 32772
100021 3 udp 32772
100021 4 udp 32772
100021 1 tcp 55018
100021 3 tcp 55018
100021 4 tcp 55018
100024 1 udp 786
100024 1 tcp 789
100003 2 udp 2049
100003 3 udp 2049
100003 4 udp 2049
100003 2 tcp 2049
100003 3 tcp 2049
100003 4 tcp 2049
100005 1 udp 983
100005 1 tcp 986
100005 2 udp 983
100005 2 tcp 986
100005 3 udp 983
100005 3 tcp 986However, note the strange behavior of rpcinfo not displaying the service, or see:
# rpcinfo -t NFSIP nfs
rpcinfo: nfs is unknown serviceAnd:
# showmount -a NFSIP
clnt_create: RPC: Unknown hostI figure it might be a quite stupid point I'm missing here.
The only related thread I found, was [https://bbs.archlinux.org/viewtopic.php?id=112412], though.
And, taking the idea from there, i.e., reinstalling iana-etc, didn't work for me.
Last edited by danielberger (2012-06-05 05:58:31)
Offline
Today, I tried to investigate a bit more into this topic.
First, I tried explicit versions (2/3) and protocol statements (udp/tcp). No luck:
mount.nfs: timeout set for Fri Jun 1 08:36:56 2012
mount.nfs: trying text-based options 'nolock,nfsvers=3,addr=NFSIP'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying NFSIP prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying NFSIP prog 100005 vers 3 prot UDP port 983
mount.nfs: Protocol not supportedmessages.log shows
May 31 09:21:52 localhost automount[626]: >> mount.nfs: Protocol not supported
May 31 09:21:52 localhost automount[626]: mount(nfs): nfs: mount failure NFSDNSNAME:/home/dberger on /home/dberger
May 31 09:43:54 localhost rpc.statd[872]: Running as root. chown /var/lib/nfs to choose different user
May 31 10:01:38 localhost kernel: [ 1217.506330] FS-Cache: Netfs 'nfs' registered for caching
May 31 10:58:32 localhost rpc.statd[635]: Running as root. chown /var/lib/nfs to choose different user
May 31 11:06:30 localhost rpc.statd[650]: Running as root. chown /var/lib/nfs to choose different user
Jun 1 08:20:01 localhost rpc.statd[646]: Running as root. chown /var/lib/nfs to choose different user
Jun 1 08:21:29 localhost kernel: [ 101.648781] FS-Cache: Netfs 'nfs' registered for cachingThe same can be seen in daemon.log. Only one time is saw a
May 30 19:15:54 localhost rpc.statd[785]: Failed to read /var/lib/nfs/state: Successnot sure what this means, though.
I tried to enable a higher debugging level (by a tip on [http://stromberg.dnsalias.org/~strombrg … ing-2.html])
echo 2048 > /proc/sys/sunrpc/rpc_debug
echo 1 /proc/sys/sunrpc/nfs_debugbut not sure where this should give any reaction?
Btw, some related versions are
local/libnfs 1.3.0-1
local/nfs-utils 1.2.6-1
local/nfsidmap 0.24-3
local/rpcbind 0.2.0-8Edit: Removed IP-addresses as they are public and not mine.
Last edited by danielberger (2012-06-01 15:47:36)
Offline
So, I did a fast trace on the network traffic and found kind of weird behavior:
<-> LDAP SYN
-> LDAP simple bindRequest for Rooot
<- success
-> LDAP searchRequest for whole Subtree
<- success [0 results]
<-> SUN RPC SYN
-> Portmap GETPORT Call: NFS(100003) V:3 TCP
<- GETPORt Reply: Port: 2049
<-> SUN RPC FIN
-> NFS V3 NULL Call
<- NFS V3 NULL Reply
<-> NFS FIN
<-> LDAP foo
-> Portmap V2 GETPORT Call: Mount(100005) V:3 UDP
<- Portmap V2 GETPORT Reply: Port 983
-> MOUNT V3 NULL Call
<- MOUNT V3 NULL Reply
-> LDAP RST (!)
(..) nothing moreIts true, this is an LDAP-enabled login. However, current user is a local one and NFSv3 shouldn't use LDAP (or anything for auth), right?
Well, might be not directly related to NFS (but to checking the mountpoint, wse?).
Secondly, I understand from [http://tools.ietf.org/html/rfc1813#page-31] that the Null call "is made available to allow server response testing and timing."
And then, this is how it ends. Really weird, to me...
Additionally, LDAP gets a reset (which it doesn't for usual LDAP lookups...)
Erm, I would not like to publish the full pcap here, however, if anybody would be willing to help, I'll share in any private way.
Another thing: I just tried to check /etc/services (remember the changes with iana-etc, right?).
It actually differed for NFS and read:
# <== NOTE Conflict on 2049 !
shilp 2049/tcp
shilp 2049/udp
nfs 2049/tcp # Network File System - Sun Microsystems
nfs 2049/udp # Network File System - Sun Microsystems
# Brent Callaghan <brent&terra.eng.sun.com>
nfs 2049/sctp # Network File System
# [RFC5665]I tried ommitting the weird entries - no change.
Finally, I just want to mention that yes the NFS server is in my /etc/hosts and I would greatly appreciate any help ;-)
Offline
Check your/etc/nsswitch.conf file, it may be directing service lookups to LDAP rather than /etc/services file.
Offline
Damn it, right you are.
I had several entries in my nsswitch.conf from the wiki reading (e.g.)
services: ldap [NOTFOUND=return] fileschanging the order to first lookup 'files' then 'ldap' solved the issue completely.
Many thanks
Offline