kerberized NFS on OS X (gssd problem)

[Richard E. Silverman]

This may be better directed to an OS X internals forum -- but it's worth
posting to these groups because it involves NFS and Kerberos. I'm trying
to use a Leopard machine as a kerberized NFSv4 client. I get this:

$ mount -v -t nfs -o vers=4.0alpha -o sec=krb5 server:/foo /foo
mount_nfs: /Users/res/foo: Authentication error

and I get this in the system log:

Jan 18 00:15:59 darwin kernel[0]: nfs_gss_clnt_gssd_upcall: gssd port not valid
Jan 18 00:15:59 darwin kernel[0]: nfs4_setclientid failed, 80

The kernel is making the expected upcall to gssd, but failing to
communicate with it. Now, gssd is started by launchd, which should be
listening on the gssd Mach port for this call. Indeed, the launchd
configuration for gssd,
/System/Library/LaunchDaemons/com.apple.gssd.plist, indicates it's
listening on task special port 8. And the xnu source shows that it should
be using the same port number:

[osfmk/mach/task_special_ports.h]
#define TASK_GSSD_PORT 8 /* GSSD port for security context */

But it's not working. Anyone run into this before, or have any ideas?

Thanks,

[John Caruso]

Post by Richard E. Silverman
I'm trying
$ mount -v -t nfs -o vers=4.0alpha -o sec=krb5 server:/foo /foo
mount_nfs: /Users/res/foo: Authentication error
Jan 18 00:15:59 darwin kernel[0]: nfs_gss_clnt_gssd_upcall: gssd port not valid
Jan 18 00:15:59 darwin kernel[0]: nfs4_setclientid failed, 80

I'm attempting the same thing and getting the same result. Did you ever
manage to resolve this issue?

- John

[Richard E. Silverman]

I'm trying to use a Leopard machine as a kerberized NFSv4 client.
$ mount -v -t nfs -o vers=4.0alpha -o sec=krb5 server:/foo /foo
mount_nfs: /Users/res/foo: Authentication error
Jan 18 00:15:59 darwin kernel[0]: nfs_gss_clnt_gssd_upcall: gssd
port not valid Jan 18 00:15:59 darwin kernel[0]: nfs4_setclientid
failed, 80

JC> I'm attempting the same thing and getting the same result. Did
JC> you ever manage to resolve this issue?

JC> - John

I'm afraid not; I have a bug open with Apple on it right now. I have
found that kerberized NFSv3 does work, though. Of course, it *does* say
the NFSv4 code is alpha...

[Sebastian Hanigk]

Post by Richard E. Silverman
I'm afraid not; I have a bug open with Apple on it right now. I have
found that kerberized NFSv3 does work, though. Of course, it *does* say
the NFSv4 code is alpha...

I haven't tried Apple's NFSv4 implementation yet, but I was able to
mount our Solaris-exported NFSv4 shares using Rick Macklem's newnfs
driver and utilities (<ftp://ftp.cis.uoguelph.ca/pub/nfsv4/darwin-port>).

While it works as such, it is unusable for data transfers over my DSL
line at home; the RPC roundtrip latency could be a problem.


Sebastian

[John Caruso]

I have found that kerberized NFSv3 does work, though.

That's the route I went as well. And it not only works, but it works
with just the behaviors I was looking for (files are created with the
Kerberos principal rather than uid 501, they're assigned the same gid
as the directory in which they're created, and mounting the filesystem
requires only a user principal rather than full-blown host/nfs keys).

Of course, it *does* say the NFSv4 code is alpha...

Yes, and it wouldn't be surprising if this was the code they haven't
gotten to yet.

- John

[John Caruso]

Post by John Caruso

I have found that kerberized NFSv3 does work, though.

That's the route I went as well. And it not only works, but it works
with just the behaviors I was looking for (files are created with the
Kerberos principal rather than uid 501, they're assigned the same gid
as the directory in which they're created, and mounting the filesystem
requires only a user principal rather than full-blown host/nfs keys).

However, I have found that the Mac client generates warnings like the
following on the Netapp filer while it has the NFSv3/Kerberos 5 mount in
place, even if I'm not actively using the mount (and/or the machine):

Fri Feb 8 15:20:24 PST [nfsd.auth.status.bad:warning]: Client a.b.c.d has an authentication error 14

They generally occur about 30 minutes apart, so perhaps there's some
process kicking off under OS X that's causing them. Are you seeing these
as well (or analogous errors if you're not using a Netapp filer as the
NFS server)?

- John

[Richard E. Silverman]

I have found that kerberized NFSv3 does work, though.
That's the route I went as well. And it not only works, but it
works with just the behaviors I was looking for (files are created
with the Kerberos principal rather than uid 501, they're assigned
the same gid as the directory in which they're created, and
mounting the filesystem requires only a user principal rather than
full-blown host/nfs keys).

JC> However, I have found that the Mac client generates warnings like
JC> the following on the Netapp filer while it has the NFSv3/Kerberos
JC> 5 mount in place, even if I'm not actively using the mount (and/or
JC> the machine):

JC> Fri Feb 8 15:20:24 PST [nfsd.auth.status.bad:warning]: Client
JC> a.b.c.d has an authentication error 14

JC> They generally occur about 30 minutes apart, so perhaps there's
JC> some process kicking off under OS X that's causing them. Are you
JC> seeing these as well (or analogous errors if you're not using a
JC> Netapp filer as the NFS server)?

I'm afraid not -- although we have kerberized NFS running on NetApp, I'm
only working with Solaris NFS servers for this, and have seen nothing
similar.

JC> - John