nfsv4 FreeBSD server vs. Linux client I/O error

[Gerrit Kühn]

On Thu, 12 Nov 2009 14:45:04 -0500 (EST) Rick Macklem
<rmacklem at uoguelph.ca> wrote about Re: nfsv4 FreeBSD server vs. Linux
client I/O error:

RM> A few things to check on the server:
RM> - Did you add a "V4:" line to your /etc/exports and what did you set as
RM>    the root path in it? If you used "V4: /" then the root file system
RM>    would need to be exported by another line in /etc/exports for it to
RM>    work.
RM> 
RM> - If you are only exporting another filesystem, lets say "/exports",
RM>    then your mount command would have to look like:
RM>  	mount -t nfs4 <server>/exports /mnt
RM>    (assuming "V4: /" was used)

I think I do not yet understand the last part. How do I restrict the
export of... oh, I guess I see. If I put / in the exports list, this will
merely only allow for the full path still being used on the client side,
but I have still to add the file systems actually to be exported. I was
wondering about the notes in the manpages about this.

RM> - If you used "V4: /exports", then "mount -t nfs4 <server>:/ /mnt"
RM>    would work and you would see /exports at /mnt.

However, this is exactly the way I went. My exports line on my server
(cliff) looks like this:

V4: /tank -network 192.168.0.0 -mask 255.255.0.0


On the client I try to mount like this:

---
pt-ws1 ~ # time mount -t nfs4 cliff:/ /mnt

real    0m30.005s
user    0m0.000s
sys     0m0.002s
---


As you see, there is a timeout of about 30s involved. After that the nfs
appears to be there:

pt-ws1 ~ # mount
[...]
nfsd (rw) cliff:/ on /mnt type nfs4
(rw,addr=192.168.33.96,clientaddr=192.168.32.3)


But it cannot be accessed:

pt-ws1 ~ # ls /mnt
ls: cannot open directory /mnt: Input/output error


Unmounting gives the same timeout, but afterwards the nfs mount is indeed
unmounted:

pt-ws1 ~ # time umount /mnt

real    0m30.002s
user    0m0.001s
sys     0m0.001s


RM> Beyond something like the above, if you capture packets using
RM> "tcpdump -s 0 -w <file> host <server>" on the server and then
RM> email me "<file>", I can take a look at it. (tcpdump doesn't know
RM> diddly about NFSv4, but wireshark does and can handle tcpdump
RM> captures.)

I will do that, thanks.


cu
  Gerrit