Skip to contentSkip to conversation

Kerberos auth Problem with nfs3/4

DISCUSSION Michael Guntsche 2 participants 2 messages Aug 3, 2010

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

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

#1 lore raw

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

Quoted 51 lines · Michael Guntsche

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