KVNO matches but rpc.svcgssd insists it doesn't.

[Omri Schwarz]

Yes, restarting rpc.gssd on the client
turned out to fix the problem completely.

Thanks!

(Sorry about the top-posting, BTW)


On Fri, 23 Mar 2007, Kevin Coffman wrote:

> Does the client have a previously obtained service ticket with an old
> kvno?  Restarting rpc.gssd on the client should clear that out if it
> is the case.
>
> On 3/23/07, Omri Schwarz <ocschwar at mit.edu> wrote:
>> klist -e -k /etc/krb5.keytab
>> on the server continues to claim the same
>> KVNO as that in the DB. I've used ktutil
>> to trim the keytab to make sure only
>> the current KVNO is in it.
>> 
>> On Fri, 23 Mar 2007, Kevin Coffman wrote:
>> 
>> > On 3/23/07, Omri Schwarz <ocschwar at mit.edu> wrote:
>> >> Hi, folks, I am trying to get Kerberized
>> >> NFS going on in my shop. I have two hosts running
>> >> Fedora Core 6, i386, with nfs-utils-1.0.10-5.fc6.
>> >>
>> >> On the putative server, rpc.svcgssd
>> >> continues to insist that the KVNO for nfs/server at REALM
>> >> rpc.svcgssd[2980]: ERROR: GSS-API: error in handle_nullreq:
>> >> gss_accept_sec_context(): Unspecified GSS failure.  Minor code may 
>> provide
>> >> more information - Key version number for principal in key table is
>> >> incorrect
>> >> Mar 23 14:52:45 giordano rpc.svcgssd[2980]: WARNING: failed to write
>> >> message
>> >>
>> >> Yet when I check with kinit and kadmin, I keep seeing that
>> >> the KVNO does in fact match.
>> >>
>> >> This is preventing me from doing test mounts.
>> >> What to do? Many thanks for all replies.
>> >
>> > Hi Omri,
>> > What does "klist -e -k" on the server say?  (perhaps there are
>> > multiple keys for "nfs/server"?)  The kvno there matches what is in
>> > the DB (via kadmin)?
>> >
>> > K.C.
>> >
>> 
>> 
>