On Wed, May 9, 2018 at 5:19 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > 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? What are your full hostnames of each machine and does the reverse lookup from the ip to hostname on each machine give you what you expect? Sounds like all of them need to be resolved to <>.ib.1015grager.net but somewhere you are getting <>.1015grager.net instead. -- 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
