I'm right on the edge of my understanding of how this all works. I've re-keyed my NFS server. Now on my client, I'm seeing this on vers=4.0,sec=sys mounts: May 8 16:40:30 manet kernel: NFS: NFSv4 callback contains invalid cred May 8 16:40:30 manet kernel: NFS: NFSv4 callback contains invalid cred May 8 16:40:30 manet kernel: NFS: NFSv4 callback contains invalid cred manet is my client, and klimt is my server. I'm mounting with NFS/RDMA, so I'm mounting hostname klimt.ib, not klimt. Because the client is using krb5i for lease management, the server is required to use krb5i for the callback channel (S 3.3.3 of RFC 7530). After a SETCLIENTID, the client copies the acceptor from the GSS context it set up, and uses that to check incoming callback requests. I instrumented the client's SETCLIENTID proc, and I see this: check_gss_callback_principal: acceptor=nfs@xxxxxxxxxxxxxxxxxxxxxxxx, principal=host@xxxxxxxxxxxxxxxxxxxxx The principal strings are not equal, and that's why the client believes the callback credential is bogus. Now I'm trying to figure out whether it is the server's callback client or the client's callback server that is misbehaving. To me, the server's callback principal (host@klimt) seems like it is correct. The client would identify as host@manet when making calls to the server, for example, so I'd expect the server to behave similarly when performing callbacks. Can anyone shed more light on this? -- Chuck Lever -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
