Based on the bug report, what seems to be happening is that the client is managing to negotiate an AES context even though the code calls set_allowable_enctypes to limit the context to only supporting des. So you get a CFX context on the server, which doesn't actually support CFX, so things lose. As it turns out, the client doesn't support CFX either, so things would have failed there in a few functions calls.
Now, there's a question about whether this is a bug in Kerberos or the nfs-utils code. Signs point to a kerberos bug. The major thing that has changed in this area is the addition of the mechglue layer in 1.6.1. It's possible that even for a krb5 credential, this routine doesn't do the right thing. Alternatively' it's possible that nfs's expectations about what a glue layer does are wrong and the bug is on the nfs side. I think this will be fairly easy to walk through this in a debugger and see what's going on. I'll do that before unleashing 1.6.1 on unstable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
