kerberized NFS on OS X (gssd problem) - NFS

This is a discussion on kerberized NFS on OS X (gssd problem) - NFS ; 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: ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: kerberized NFS on OS X (gssd problem)

  1. kerberized NFS on OS X (gssd problem)


    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,

    --
    Richard Silverman
    res@qoxp.net


  2. Re: kerberized NFS on OS X (gssd problem)

    On 2008-01-18, Richard E. Silverman wrote:
    > 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


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

    - John

  3. Re: kerberized NFS on OS X (gssd problem)

    >>>>> "JC" == John Caruso writes:

    JC> On 2008-01-18, Richard E. Silverman wrote:
    >> 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


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

    --
    Richard Silverman
    res@qoxp.net


  4. Re: kerberized NFS on OS X (gssd problem)

    "Richard E. Silverman" writes:

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

    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

  5. Re: kerberized NFS on OS X (gssd problem)

    On 2008-02-08, Richard E. Silverman wrote:
    > 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

  6. Re: kerberized NFS on OS X (gssd problem)

    On 2008-02-08, John Caruso wrote:
    > On 2008-02-08, Richard E. Silverman wrote:
    >> 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

  7. Re: kerberized NFS on OS X (gssd problem)

    >>>>> "JC" == John Caruso writes:

    JC> On 2008-02-08, John Caruso wrote:
    >> On 2008-02-08, Richard E. Silverman wrote:
    >> 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

    --
    Richard Silverman
    res@qoxp.net


+ Reply to Thread