NFSv4: prob err=10036

Marcelo Araujo araujobsdport at
Wed Apr 23 06:05:42 UTC 2014

2014-04-16 5:01 GMT+08:00 Rick Macklem <rmacklem at>:

> Well, I looked at the packet trace and it is weird.
> One field (the NFSv4 operation #) is incorrect in the packet.
> It should have been 33 (0x21), which is PUTROOTFH and instead
> it is 39 (0x27), which is RELEASELOCKOWNER.
> All the arguments after the operation # are correct for the
> RPC, if that operation# was 33 (PUTROOTFH).
> Since the call looks like this (around line#4303 in
> sys/fs/nfsclient/nfs_clrpcops.c):
>    nfscl_reqstart(nd, NFSPROC_PUTROOTFH, nmp, NULL, 0, &opcntp, NULL);
> (Btw, there is a mapping from NFSPROC_xxx to NFSV4OP_xxx that occurs,
>  so these arguments are 33 and 34 respectively and not 33 and 39.)
> So, somehow the argument gets incremented by one when it is on the
> stack for the call. (It would be 34 in nfscl_reqstart(), since the
> tag is "Rellckown" and not "Dirpath" in the packet header. This tag
> is for debugging only and doesn't affect the RPC's semantics. For
> once, it was useful;-) So, this isn't some data error later, such as
> "on the wire".
> All I can suggest is that something is stomping on this field on
> the stack or there is a memory problem where this stack argument
> sits?
> Aren't computers fun? rick
Hello Rick,

First of all, thank you so much, once again with your help  I could solve
the weird situation.

Actually the problem was related with a VAAI implementation in the server
side that I was making the test, the VAAI implementation on that server
move one bit ahead for the NFSPROC operations and make my client totally

I made a fix on my NFSv4 client and now everything works properly. I don't
think make much sense send back this patch, as in my case here, this VAAI
implementation is not too much portable.

Once again, thank you so much, you have done an amazing working on NFS.

Best Regards,
Marcelo Araujo
araujo at

More information about the freebsd-fs mailing list