[vox-tech] NFS mount "RPC: Timed out" error

[Peter Jay Salzman]

On Mon 14 Jul 03,  3:06 PM, Ken Herron <Kherron@newsguy.com> said:
> --On Monday, July 14, 2003 13:35:20 -0700 Bill Kendrick <nbs@sonic.net> 
> wrote:
> 
> >>Shouldn't nfsd be in there?
> >
> >*shrug*  Sure?!  Why not? ;)  Like I said, it worked previously, and I
> >know I didn't mess with hosts.allow between the time it /was/ working
> >and now, but I'll try it anyway...
> 
> Err, isn't hosts.allow the TCP wrappers config file? NFS usually runs 
> over udp in a lan environment; I don't see how TCP wrappers could be 
> involved.
 
yep.

but portmapper should listen to both tcp and udp ports though...
 
 
> >For the host in question, I get back:
> >
> >   program vers proto   port
> >    100000    2   tcp    111  portmapper
> >    100000    2   udp    111  portmapper
> >    100003    2   udp   2049  nfs
> >    100003    2   tcp   2049  nfs
> >    100005    1   udp    630  mountd
> >    100005    2   udp    630  mountd
> >    100005    1   tcp    633  mountd
> >    100005    2   tcp    633  mountd
> 
> Hmm, you should have entries for lockd and statd (I think) in there. The 
> timeout could be from the client trying to contact lockd on the server, 
> but I don't know if that happens at mount time.
> 
> It'd be helpful to to know exactly what rpc program/version the client is 
> trying to invoke when it times out. Could you snoop the network during a 
> mount attempt? If it's trying to talk to nfsd, then the question is why 
> nfsd is ignoring the client. If the client is trying to talk to lockd, 
> then the question is why lockd isn't running.

i was going to suggest that myself.  bill, do this:

   # tcpdump -i eth0 udp port 2048

and try to mount.  you should see a communication attempt.   this should
narrow down the culprit a bit.
 
> >Before I go much further... is there any chance at all that this could
> >be a kernel issue on mountING system?  (The one trying to make the NFS
> >connection to the mountED server)
> 
> Shrug, anything's possible. It'd be nice to know exactly what is failing 
> before leaping for the kernel, though.

if you didn't update the kernel, there's no reason to expect the kernel
is the culprit.

when was the last time you apt-got anything?

have you checked daemon.log?  messages?   can you run nfsd and portmap
with some kind of debug switches?

pete

-- 
GPG Instructions: http://www.dirac.org/linux/gpg
GPG Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D