2010-08-03 19:03:36

by Michael Guntsche

Subject: Kerberos auth Problem with nfs3/4

Some more news,

I tried mounting the same export from a macosx client and it succeeded.
There was a difference though when looking at the rpc.svcgssd output

rpc.svcgssd -vvf:
=================
leaving poll
handling null request
sname = [email protected]
DEBUG: serialize_krb5_ctx: lucid version!
prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length 8
doing downcall
mech: krb5, hndl len: 4, ctx len 85, timeout: 1280897678 (35627 from now), clnt: <null>, uid: 1000, gid: 1000, num aux grps: 8:
( 1) 1000
( 2) 20
( 3) 24
( 4) 25
( 5) 29
( 6) 44
( 7) 46
( 8) 118
sending null reply
finished handling null request
entering poll
leaving poll
handling null request
sname = [email protected]
DEBUG: serialize_krb5_ctx: lucid version!
prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length 8
doing downcall
mech: krb5, hndl len: 4, ctx len 85, timeout: 1280897678 (35627 from now), clnt: <null>, uid: 1000, gid: 1000, num aux grps: 8:
( 1) 1000
( 2) 20
( 3) 24
( 4) 25
( 5) 29
( 6) 44
( 7) 46
( 8) 118
sending null reply
finished handling null request

As you can see it uses a different sname and there are two requests, while I only see one with the linux client. Of course uid and gid are different too.

Kind regards,
Michael

2010-08-03 20:07:27

by Andy Adamson

Subject: Re: Kerberos auth Problem with nfs3/4

So the macosx client mount succeeded because the [email protected] was successfully mapped to a UID whereas the linux client mount failed because the sname=nfs/[email protected] UID mapping failed (or hung as Bruce described).

-->Andy

On Aug 3, 2010, at 3:03 PM, Michael Guntsche wrote:

> Some more news,
>
> I tried mounting the same export from a macosx client and it succeeded.
> There was a difference though when looking at the rpc.svcgssd output
>
> rpc.svcgssd -vvf:
> =================
> leaving poll
> handling null request
> sname = [email protected]
> DEBUG: serialize_krb5_ctx: lucid version!
> prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length 8
> doing downcall
> mech: krb5, hndl len: 4, ctx len 85, timeout: 1280897678 (35627 from now), clnt: <null>, uid: 1000, gid: 1000, num aux grps: 8:
> ( 1) 1000
> ( 2) 20
> ( 3) 24
> ( 4) 25
> ( 5) 29
> ( 6) 44
> ( 7) 46
> ( 8) 118
> sending null reply
> finished handling null request
> entering poll
> leaving poll
> handling null request
> sname = [email protected]
> DEBUG: serialize_krb5_ctx: lucid version!
> prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length 8
> doing downcall
> mech: krb5, hndl len: 4, ctx len 85, timeout: 1280897678 (35627 from now), clnt: <null>, uid: 1000, gid: 1000, num aux grps: 8:
> ( 1) 1000
> ( 2) 20
> ( 3) 24
> ( 4) 25
> ( 5) 29
> ( 6) 44
> ( 7) 46
> ( 8) 118
> sending null reply
> finished handling null request
>
> As you can see it uses a different sname and there are two requests, while I only see one with the linux client. Of course uid and gid are different too.
>
> Kind regards,
> Michael
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html