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

[Kevin Coffman]

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.
> >
>
>