Strange "failed to create krb5 context" messages

[Norman Elton]

Kevin,

Both machines are running 2.6.18-53.1.4.el5 (RHEL5's latest-n-greatest).

I don't see any errors in the GSS transaction. I've posted the text  
output from Wireshark in case you want to take a look:

pastebin.com/f687d93e3

The UDP checksum errors are most likely due to the network card's  
offloading engine, so it shouldn't be causing the problem.

Any ideas? Thanks!

Norman Elton

On Jan 3, 2008, at 4:41 PM, Kevin Coffman wrote:

> I don't see an error in the svcgssd output either.  In the network
> trace of the failure case, does the server ever send a response to the
> NULL call with the GSS info?  If so, does it have anything interesting
> (an error code perhaps)?
>
> What kernel version are your server and clients running?  This is
> starting to sound like a resource problem that has been seen before.
> I'll look back to try and find it.  The kernel versions would help.
>
> K.C.
>
> On Jan 3, 2008 4:18 PM, Norman Elton <normelton at gmail.com> wrote:
>> Sorry, I forgot to mention that I did do a network capture. When the
>> mount fails, I see a handful of NULL request/responses, followed by
>> one NULL transaction with GSS information attached. Then the client
>> stops sending anything.
>>
>> When the mount succeeds, I see the exact same sequence, followed by a
>> COMPOUND transaction that is requesting the root filehandle, etc.
>>
>> Thanks for any advice,
>>
>> Norman
>>
>> On Dec 24, 2007, at 9:14 AM, Kevin Coffman wrote:
>>
>>
>>> On Dec 21, 2007 10:32 AM, Norman Elton <normelton at gmail.com> wrote:
>>>> I'm in the middle of testing a small NFSv4 deployment in our lab.
>>>> I've
>>>> got one server/kdc, and two clients. Just this morning, both  
>>>> clients
>>>> were unable to mount the share. In their GSSD log, I found:
>>>>
>>>> Dec 21 10:27:53 dev1 rpc.gssd[1178]: handling krb5 upcall
>>>> Dec 21 10:27:53 dev1 rpc.gssd[1178]: Using keytab file '/etc/
>>>> krb5.keytab'
>>>> Dec 21 10:27:53 dev1 rpc.gssd[1178]: INFO: Credentials in CC
>>>> 'MEMORY:/tmp/krb5cc_machine_DOMAIN' are good until 1198254529
>>>> Dec 21 10:27:53 dev1 rpc.gssd[1178]: using
>>>> MEMORY:/tmp/krb5cc_machine_DOMAIN as credentials cache for machine
>>>> creds
>>>> Dec 21 10:27:53 dev1 rpc.gssd[1178]: using environment variable to
>>>> select krb5 ccache MEMORY:/tmp/krb5cc_machine_DOMAIN
>>>> Dec 21 10:27:53 dev1 rpc.gssd[1178]: creating context using fsuid 0
>>>> (save_uid 0)
>>>> Dec 21 10:27:53 dev1 rpc.gssd[1178]: creating tcp client for server
>>>> server.fqdn
>>>> Dec 21 10:27:53 dev1 rpc.gssd[1178]: creating context with server
>>>> nfs at server.fqdn
>>>> Dec 21 10:27:54 dev1 rpc.gssd[1178]: WARNING: Failed to create krb5
>>>> context for user with uid 0 for server server.fqdn
>>>> Dec 21 10:27:54 dev1 rpc.gssd[1178]: WARNING: Failed to create krb5
>>>> context for user with uid 0 with credentials cache
>>>> MEMORY:/tmp/krb5cc_machine_DOMAIN for server server.fqdn
>>>> Dec 21 10:27:54 dev1 rpc.gssd[1178]: WARNING: Failed to create krb5
>>>> context for user with uid 0 with any credentials cache for server
>>>> server.fqdn
>>>> Dec 21 10:27:54 dev1 rpc.gssd[1178]: doing error downcall
>>>> Dec 21 10:27:54 dev1 rpc.gssd[1178]: destroying client clnt71
>>>> Dec 21 10:27:54 dev1 rpc.gssd[1178]: destroying client clnt70
>>>>
>>>> I had never seen these before, and NFS had been behaving itself
>>>> nicely
>>>> for the past few weeks. After dinking around with the clients, I
>>>> decided to restart the NFS processes on the server. All of a  
>>>> sudden,
>>>> things started working again.
>>>>
>>>> Does anyone know what would cause such problems? I'd rather get  
>>>> these
>>>> things ironed out before we roll out NFSv4 in a production
>>>> environment.
>>>>
>>>> Thanks!
>>>>
>>>> Norman Elton
>>>
>>> Offhand, I can't think of what might cause it.  Check for messages
>>> from rpc.svcgssd on the server.  Otherwise, a network trace might
>>> reveal why the context is not being created.
>>>
>>> K.C.
>>
>>
>> _______________________________________________
>> NFSv4 mailing list
>> NFSv4 at linux-nfs.org
>> http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
>>
>>