From: Chuck Lever <chuck.lever@oracle.com>
Content-Type: text/plain; charset=us-ascii
Subject: Strange rpc.svcgssd behavior
Date: Mon, 15 Nov 2010 12:39:49 -0500
Message-Id: <1C8B051A-5DC1-4871-B9B9-96E571036A9B@oracle.com>
To: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Sender: linux-nfs-owner@vger.kernel.org
MIME-Version: 1.0

I've just set up a Linux KDC with a Linux NFS server (Fedora 13 with the latest updates).

rpc.svcgssd fails to start on the NFS server.

 ERROR: GSS-API: error in gss_acquire_cred(): Unspecified GSS failure.  Minor code may provide more information - Key table entry not found
 unable to obtain root (machine) credentials
 do you have a keytab entry for nfs/<your.host>@<YOUR.REALM> in /etc/krb5.keytab?

I do have an entry for nfs/<your.host>@<YOUR.REALM> in /etc/krb5.keytab.  The problem is that /etc/hosts looks like this:

 192.168.1.58	your.host	your	# Added by NetworkManager
 127.0.0.1	localhost.localdomain	localhost
 ::1		your.host your	localhost6.localdomain6 localhost6

Removing "your.host	your" from the "::1" entry makes this problem go away -- rpc.svcgssd starts up as expected.

Now I reboot, and NetworkManager happily adds "your.host	your" back to the "::1" entry, and rpc.svcgssd fails again.  I haven't tried this, but I suspect if the ::1 entry weren't there, NM would add "your.host.net	your" to the IPv4 loopback entry, and we'd have the same problem.

At a glance, it looks like the local hostname is determined in a library, and not in rpc.svcgssd.  This really needs to be more robust.

I see the "-p principal" option in the latest nfs-utils, but it doesn't seem to be supported in Fedora 13's rpc.svcgssd.  Is this the workaround?

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com