RE: NFS issues on 8.0-BETA4

From: Rick Macklem <rmacklem_at_uoguelph.ca>
Date: Fri, 11 Sep 2009 16:37:50 -0400 (EDT)
>>
>> I cannot sucessfully mount exports from the NFSv3 server on the
>> 8.0-BETA4 client.  All works well with 7.2 clients.
>>
>> The strange thing is, the directory in which I mount the nfs
>> filesystem disappears, and I get an error when I attempt to access the
>> directory.
>>

I went and looked at the message over in stable_at_ (I guess I have to join
that mailing list, too:-).

I think that the second mount attempt, which failed with errno==64
EHOSTDOWN probably gives you a better indication of what is broken
and hints at a networking problem, which hopefully others can help
with?

mount_nfs currently has the quirk that, if you don't specify either
"udp" or "tcp", it will use UDP for the mount protocol and then
switch to TCP for NFS. (I didn't make it that way, but noticed it
when I was adding changes for the experimental client.)
So, you might want to try adding "udp" or "tcp" to the mount
options for your "simplified mount" and see what happens? (I suggest
this, since it seems to have been able to talk to mountd on the server,
but not NFS on the server and the only explanation I can think of is
the switch to TCP for that.)

I think the first case failed after the retrycnt, due to the "soft"
option, but hadn't succeeded in doing any NFS Getattr, so the mount
point's type wasn't VDIR--> returning errno==1 EPERM for the "ls -l".

If the mount attempts with "udp" or "tcp" specified give you the same
behaviour, you could try using wireshark to capture the traffic.
(Wireshark is pretty good at decoding NFS traffic.) If you don't have
wireshark, you can use "tcpdump -w <file> -s 0 <host>" to capture the
traffic in a file that can be fed to wireshark later. (I'd be happy to
look at the traffic, if you were to email me the above <file>.)

Good luck with it, rick
ps: I'll assume that the client can talk to the server for other
     stuff ok.
pss: A big change between 7 and 8 is use of a new kernel RPC layer
     that handles the RPC transport (again, I wasn't the author, but
     am somewhat familiar with it).
Received on Fri Sep 11 2009 - 18:32:39 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:55 UTC