Request guidance on NFSv4.1 server using KRB5 with AD and without winbind

Latest response

Hello All,

I've been tasked with getting an NFSv4.1 server stood up within our infrastructure on EL6.  We'd like to use krb5p if possible, and currently have Windows Server 2008r2 domain controllers acting as our KDC.  We have Samba configured on the all our EL6 boxes and use that for things like GSSAPI SSH.


One requirement that's been stated, which I can't find any good examples of, is that we cannot use winbind. 

I've created (via net ads keytab add nfs) nfs/fqdn@DOMAIN and host/fqdn@DOMAIN principals on the test server and client.

Here are my exports:

/srv        *(rw,fsid=0,insecure,no_subtree_check,sync)
/srv/nfshomes    gss/krb5(rw,insecure,no_subtree_check,sync)
/srv/nfsgroups    gss/krb5(rw,insecure,no_subtree_check,sync)

And here's what I get when I try to mount:

# mount -v testserver:/srv/nfsgroups /mnt/nfstest -o minorversion=1 -o nolock -o nfsvers=4
mount: no type was given - I'll assume nfs because of the colon
mount.nfs: timeout set for Fri Mar  1 16:59:42 2013
mount.nfs: trying text-based options 'minorversion=1,nolock,nfsvers=4,addr=,clientaddr='
mount.nfs: mount(2): Protocol not supported
mount.nfs: Protocol not supported

Here are the encryption types in the nfs/fqdn and host/fqdn keys in the keytabs:







Does anyone have any advice on where I should go from here? 



Hello Kodiak,

did you already have a look at ?

If the details from that document do not help further,

  • running the involved daemons with debugging options (configured in /etc/sysconfig/nfs)
  • checking the principals in the keytab
  • and sniffing the network traffic

could be steps to further debug this. If we need further debugging then I would recommend to open a case with the Red Hat support.

cheers, Christian

Thanks for the reply, Christian.


The solution you posted a link to was definately some help - it's the first one I saw that closely mirrors what we're tryingt to do.


There is a problem with the posted solution and I'll be sure to add information about the problem in the comments of that solution. 


The root problem that's keeping this from working like it should is that the EL6 version of samba-common (3.6.9-151) and possibly all other versions, there is a problem with the 'net ads keytab add' command.  That command is the right way to create AD SPNs, rather than 'net ads join createupn=nfs/fqdn'.


With the 'net ads keytab add nfs' command, you'll get a correct-case 'nfs/fqdn' SPN in the local keytab, but it will mismatch with the SPN that it creates in AD which will be 'NFS/fqdn'.

The solution you linked to works around that in a hackish way by creating 'nfs/fqdn' as a UPN, but it only happens to work in his example because it's the last UPN to be created.  Each time a UPN is created and associated with an AD-joined computer, the previous UPN goes away.  Thus if you do what the poster of the solution says and run 3 'net ads join createupn=' commands, for 'host', 'root', and 'nfs', only the 'nfs' UPN is preserved, and the 'host' and 'root' ones are overwritten.

What's interesting (and a bit sad) is that this was reported as a bug in 2006 to Samba (#3671), promptly had patches submitted, was marked as fixed, but it appears the patch was never applied.


I've created a new bug linking to the original one to request it be fixed:


Once this is done and RH integrates the fix, we'll be able to create SPNs the right(tm) way and won't have to work around it via UPNs, which could be accidentally overwritten and cause NFS services to break.

Anyhow, your post was a big help toward getting me on the path to sorting some of this out.


Thanks a bunch!

Hi Kodiak,

thanks for the update.

The kbase carries 'unverified', I was involved in creation on debugging all of the clientside pieces here - yet we did not follow this up at that time in emulating also the Windows AD serverside completely. 

I did see you comment on the kbase. Thanks also for following up on this as a customer case, a testpackage including the patch should be possible.

cheers, Christian

Thanks Christian,

We would be thrilled to test the testpackage since we think this will be the last hurdle before we can deploy NFSv4 krb5p services, and thus, finally start deploying our next generation of desktops.

Hi ,

@Kodiak and @Christian, Is there an updated procedure version for the implementation discussed on this topic (NFSv4 server on Linux using Windows ADS Krb domain ) ?

Thanks, Alex