Trying to mount my custom nfs4d server (a 4.1 server) using
mount -t nfs -o nfsvers=4,minorversion=1 127.0.0.1:/ /test
results in
NFS: state manager failed on NFSv4 server 127.0.0.1 with error 22
Error 22 is NFS4ERR_INVAL, but that error is never sent on the wire
(note NFS4_OK is returned for EXCHANGE_ID and CREATE_SESSION):
(RPC message #1 from Linux kernel)
nfs4d[14205]: client ::ffff:127.0.0.1 connected
nfs4d[14205]: RPC frag (40 bytes, LAST)
nfs4d[14205]: RPC: message (40 bytes, xid 3375e730, proc 0)
nfs4d[14205]: NULL proc invoked
nfs4d[14205]: RPC reply: 28 bytes, 1 writes
(RPC message #2 from Linux kernel)
nfs4d[14205]: RPC frag (256 bytes, LAST)
nfs4d[14205]: RPC: message (256 bytes, xid 3475e730, proc 1)
nfs4d[14205]: RPC CRED Unix (uid 0 gid 0 len 44)
nfs4d[14205]: op EXCHANGE_ID (127.0.0.1/localhost.localdomain/1, 1)
nfs4d[14205]: clientid 3cde47d62cea0bf6, seq 0, flg 10001
nfs4d[14205]: compound end (1 args, 1 results, status NFS4_OK)
nfs4d[14205]: RPC reply: 104 bytes, 1 writes
(RPC message #3 from Linux kernel)
nfs4d[14205]: RPC frag (216 bytes, LAST)
nfs4d[14205]: RPC: message (216 bytes, xid 3575e730, proc 1)
nfs4d[14205]: RPC CRED Unix (uid 0 gid 0 len 44)
nfs4d[14205]: op CREATE_SESSION (clid 3cde47d62cea0bf6, seq 0, flg 3)
nfs4d[14205]: sess id 68035f7e74ffff1d0000000000000000, seq 0, flg 3
nfs4d[14205]: compound end (1 args, 1 results, status NFS4_OK)
nfs4d[14205]: RPC reply: 128 bytes, 1 writes
Source code for the server is here, for the curious:
https://github.com/jgarzik/nfs4d
On Tue, Aug 28, 2012 at 12:06 PM, Andy Adamson <[email protected]> wrote:
> Which kernel?
Sorry! I had highlighted the kernel version for pasting, then forgot
to paste it:
3.5.2-3.fc17.i686
> Note that there are multiple checks on the successful CREATE_SESSION
> response that will trigger the client to reject the CREATE_SESSION
> response with -EINVAL.
>
> For example, if the recv maximum response size is greater than the
> sent maximum response size, or if the recv maximum number of
> operations is less than the sent maximum number of operations.....
Would this be nfs4_reclaim_lease(), nfs4_check_lease(),
nfs4_reset_session() or nfs4_bind_conn_to_session()?
Trying to narrow down where the check fails, and there's a lot of code
that seemingly might cause a failure there.
Thanks,
Jeff
Which kernel?
Note that there are multiple checks on the successful CREATE_SESSION
response that will trigger the client to reject the CREATE_SESSION
response with -EINVAL.
For example, if the recv maximum response size is greater than the
sent maximum response size, or if the recv maximum number of
operations is less than the sent maximum number of operations.....
-->Andy
On Tue, Aug 28, 2012 at 11:39 AM, Jeff Garzik <[email protected]> wrote:
> Trying to mount my custom nfs4d server (a 4.1 server) using
>
> mount -t nfs -o nfsvers=4,minorversion=1 127.0.0.1:/ /test
>
> results in
>
> NFS: state manager failed on NFSv4 server 127.0.0.1 with error 22
>
> Error 22 is NFS4ERR_INVAL, but that error is never sent on the wire
> (note NFS4_OK is returned for EXCHANGE_ID and CREATE_SESSION):
>
> (RPC message #1 from Linux kernel)
> nfs4d[14205]: client ::ffff:127.0.0.1 connected
> nfs4d[14205]: RPC frag (40 bytes, LAST)
> nfs4d[14205]: RPC: message (40 bytes, xid 3375e730, proc 0)
> nfs4d[14205]: NULL proc invoked
> nfs4d[14205]: RPC reply: 28 bytes, 1 writes
>
> (RPC message #2 from Linux kernel)
> nfs4d[14205]: RPC frag (256 bytes, LAST)
> nfs4d[14205]: RPC: message (256 bytes, xid 3475e730, proc 1)
> nfs4d[14205]: RPC CRED Unix (uid 0 gid 0 len 44)
> nfs4d[14205]: op EXCHANGE_ID (127.0.0.1/localhost.localdomain/1, 1)
> nfs4d[14205]: clientid 3cde47d62cea0bf6, seq 0, flg 10001
> nfs4d[14205]: compound end (1 args, 1 results, status NFS4_OK)
> nfs4d[14205]: RPC reply: 104 bytes, 1 writes
>
> (RPC message #3 from Linux kernel)
> nfs4d[14205]: RPC frag (216 bytes, LAST)
> nfs4d[14205]: RPC: message (216 bytes, xid 3575e730, proc 1)
> nfs4d[14205]: RPC CRED Unix (uid 0 gid 0 len 44)
> nfs4d[14205]: op CREATE_SESSION (clid 3cde47d62cea0bf6, seq 0, flg 3)
> nfs4d[14205]: sess id 68035f7e74ffff1d0000000000000000, seq 0, flg 3
> nfs4d[14205]: compound end (1 args, 1 results, status NFS4_OK)
> nfs4d[14205]: RPC reply: 128 bytes, 1 writes
>
> Source code for the server is here, for the curious:
> https://github.com/jgarzik/nfs4d
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Aug 28, 2012 at 12:11 PM, Jeff Garzik <[email protected]> wrote:
> On Tue, Aug 28, 2012 at 12:06 PM, Andy Adamson <[email protected]> wrote:
>> Which kernel?
>
> Sorry! I had highlighted the kernel version for pasting, then forgot
> to paste it:
>
> 3.5.2-3.fc17.i686
OK
>
>> Note that there are multiple checks on the successful CREATE_SESSION
>> response that will trigger the client to reject the CREATE_SESSION
>> response with -EINVAL.
>>
>> For example, if the recv maximum response size is greater than the
>> sent maximum response size, or if the recv maximum number of
>> operations is less than the sent maximum number of operations.....
>
> Would this be nfs4_reclaim_lease(), nfs4_check_lease(),
> nfs4_reset_session() or nfs4_bind_conn_to_session()?
nfs4_verify_fore_channel_attrs and nfs4_verify_back_channel_attrs was
what I was looking at. I would also check the server responses (and
the client reaction!) against rfc5661.
Have you turned on client debugging to /var/log/messages? This turns
it all on which for a mount failure is ok.
# rpcdebug -v -m nfs -s all
-->Andy
>
> Trying to narrow down where the check fails, and there's a lot of code
> that seemingly might cause a failure there.
>
> Thanks,
>
> Jeff
On Tue, Aug 28, 2012 at 12:31 PM, Andy Adamson <[email protected]> wrote:
> nfs4_verify_fore_channel_attrs and nfs4_verify_back_channel_attrs was
> what I was looking at. I would also check the server responses (and
> the client reaction!) against rfc5661.
>
> Have you turned on client debugging to /var/log/messages? This turns
> it all on which for a mount failure is ok.
>
> # rpcdebug -v -m nfs -s all
Will give that a try. But it looks like I need to rebuild with
CONFIG_NFS_DEBUG...
Jeff