NFSv4 + Kerberos + users

[Kevin Coffman]

On 6/22/07, Zoltan Menyhart <Zoltan.Menyhart at bull.net> wrote:
> Kevin Coffman wrote:
>
> > I cannot make sense of this.  The same user and credentials are
> > involved in the case where it works and the case where it doesn't.
> > The existence of user 'linux' credentials should not be involved at
> > all, and should not make a difference.  Are you sure that it is not
> > simply the second attempt as root, regardless of the existence of
> > 'linux' credentials, that works?
>
> Well, repeating the mount as root gave 8 times the
> "mount.nfs4: Permission denied "
> and succeeded at the 9th attempt.
>
> In the previous example I posted this morning, I destroyed the credentials
> of the user linux as linux, and I managed the next mount as root
> immediately.
>
> To reproduce the problem, it is necessary to retry 5 - 10 times in order to
> obtain the first mount failure.
>
> > In both cases the mapping from the principal to the local user is to
> > 'root', which should get squashed to nfsnobody because of
> > root_squashing.  It looks like the gss context negotiation works in
> > both cases, but something else is failing the mount in the first case.
> > A network trace on the client might give a clue.
> >
> > K.C.
>
> Please have a look at the Ethereal traces.
> The second one shows repeated, failing cases.
>
> ftp://visibull.frec.bull.fr/pub/linux/err.ethereal
> ftp://visibull.frec.bull.fr/pub/linux/err2.ethereal
>
> (Sometimes Ethereal reports false checksum errors.)
>
> Thanks,
>
> Zoltan

Assuming that the svcgssd output looks like the previous examples you
sent, it appears that the server-side kernel is returning
GSS_S_NO_CONTEXT.  (That is clearly what is being sent, and I'm
assuming that rpc.svcgssd is not returning it.)

There have been reports of this in the past where restarting
rpc.svcgssd on the server has "fixed" it.  I don't know that we've
definitively figured out what the problem is.  It looked like it might
be a memory allocation problem, but I never understood how restarting
rpc.svcgssd helped that.

Could you try restarting rpc.svcgssd on the server to see if that has
any effect, and remind me what kernel version you have on the server?

K.C.