On Fri, 14 Jun 2013, Steve Thompson wrote:
> I still have an issue with user access to the NFSv4 mount, and a
> workaround for it, but that's for another time.
And now is another time (but I am at the point on giving up on this for
now, as it has become a large consumer of time).
To reiterate, I am trying to get Keberized NFSv4 to work with CentOS 6.4
clients in a Samba4 domain, using sssd and Samba 4.0.5 (no winbind). Now,
CentOS 6.4 uses kernel 2.6.32-358.6.2.el6 and nfs-utils 1.2.3-36. First of
all, the Samba4 KDC (a separate pair of systems) appears to be working,
DNS (samba4+bind9+dlz) is working (forward and reverse), and NFSv4 is
working just fine with sec=sys (ie no Kerberos), so I believe the basic
infrastructure to be sound, including ID mapping. I am using the sec=sys
case in production with Samba4, so I know that to be good (and,
interestingly, it feels a lot snappier than NFSv3).
NFSv4 mounts with sec=krb5 work fine as long as I create a suitable UPN in
the Samba database. On the client and server:
# kinit Administrator
# FQDN=`hostname`
# msktutil \
--base "CN=Computers" \
--keytab /etc/krb5.keytab \
--dont-expire-password \
--no-pac \
--computer-name nfs-$HOST \
--hostname $FQDN \
--service nfs/$FQDN \
--upn nfs/$FQDN \
--user-creds-only
and the nfs/... entries show up within the client and server's
/etc/krb5.keytab and look correct:
# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
--------------------------------------------------------------------------
1 host/<fqdn>@<REALM> (des-cbc-crc)
1 host/<fqdn>@<REALM> (des-cbc-md5)
1 host/<fqdn>@<REALM> (arcfour-hmac)
1 host/<fqdn>@<REALM> (aes128-cts-hmac-sha1-96)
1 host/<fqdn>@<REALM> (aes256-cts-hmac-sha1-96)
1 host/<shortname>@<REALM> (des-cbc-crc)
1 host/<shortname>@<REALM> (des-cbc-md5)
1 host/<shortname>@<REALM> (arcfour-hmac)
1 host/<shortname>@<REALM> (aes128-cts-hmac-sha1-96)
1 host/<shortname>@<REALM> (aes256-cts-hmac-sha1-96)
1 <SHORTNAME>$@<REALM> (des-cbc-crc)
1 <SHORTNAME>$@<REALM> (des-cbc-md5)
1 <SHORTNAME>$@<REALM> (arcfour-hmac)
1 <SHORTNAME>$@<REALM> (aes128-cts-hmac-sha1-96)
1 <SHORTNAME>$@<REALM> (aes256-cts-hmac-sha1-96)
1 HOST/<fqdn>@<REALM> (des-cbc-crc)
1 HOST/<fqdn>@<REALM> (des-cbc-md5)
1 HOST/<fqdn>@<REALM> (arcfour-hmac)
1 HOST/<fqdn>@<REALM> (aes128-cts-hmac-sha1-96)
1 HOST/<fqdn>@<REALM> (aes256-cts-hmac-sha1-96)
2 nfs-<shortname>$@<REALM> (arcfour-hmac)
2 nfs-<shortname>$@<REALM> (aes128-cts-hmac-sha1-96)
2 nfs-<shortname>$@<REALM> (aes256-cts-hmac-sha1-96)
2 nfs/<fqdn>@<REALM> (arcfour-hmac)
2 nfs/<fqdn>@<REALM> (aes128-cts-hmac-sha1-96)
2 nfs/<fqdn>@<REALM> (aes256-cts-hmac-sha1-96)
Here /data is the exported bind mount that is underneath the fsid=0
exports entry:
# mount -t nfs4 -o sec=krb5 <server_fqdn>:/data /mnt
# (works)
I can browse the mount point as root and all permissions and ownerships
are correct, except of course that I cannot descend into directories for
which root (aka nobody) does not have permissions, as expected.
Now as a user (me, with UID 1002), using the server as a client (but using
a separate client makes no difference), I can't even browse:
$ kinit
$ ls /mnt
ls: cannot access /mnt: Permission denied
and that's as far as I can get. From /var/log/messages:
rpc.gssd[7564]: using FILE:/tmp/krb5cc_1002 as credentials cache for client with uid 1002 for server <server_fqdn>
rpc.gssd[7564]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_1002
rpc.gssd[7564]: creating context using fsuid 1002 (save_uid 0)
rpc.gssd[7564]: creating tcp client for server <server_fqdn>
rpc.gssd[7564]: DEBUG: port already set to 2049
rpc.gssd[7564]: creating context with server nfs@<server_fqdn>
rpc.gssd[7564]: WARNING: Failed to create krb5 context for user with uid 1002 for server <fqdn>
I have of course researched this at length, and found lots of instances of
folks seeing the same "Failed to create krb5 context" message, but no-one
with the same combination of OS and Samba4, and no resolutions.
I have also tried a Fedora 18 client and server (kernel 3.9.5-201.fc18,
nfs-utils 1.2.7-6) with a different but equivalent pair of Samba4 domain
controllers. Again, NFSv4 with sec=sys works fine, and with sec=krb5 it
fails in *exactly* the same way as for CentOS.
Using "nfs ads keytab add nfs..." properly creates an SPN, and this is not
sufficient, on both CentOS and Fedora.
Any ideas? Please stop me from drinking so much coffee. TIA!
-Steve