nfs4 and kerberos: Wrong principal in request

I've found the solution:

Looking at an strace of the rpc.svcgssd daemon, I saw that the last file opened before the error ways the /etc/krb5.keytab.

The keytab on the server was generated using kadmin with a kinit of "kadmin/admin".

A kinit -k -t /etc/krb5.keytab nfs/SERVER.example.com@REALM on the SERVER resulted in a invalid password errror. So i deleted the keytab and generated a new one using kadmin -l. There might be a problem with the keytab of my kadmin/admin user that resulted in a corrupt keytab. I haven't investigaed the problem yet.

After I created a new keytab, the nfs4+krb5 mount succeeded.

Thank your for your answers, they helped a lot in narrowing the problem down.

So for anyone encountering a similiar problem:

1. Try to kinit the service tickets on every invovled host using kinit -k -t /etc/krb5.keytab nfs/SERVER.example.com@REALM

2. Do a strace -p $(pidof rpc.svcgssd) -s4096 -e trace=open,close,read,write and check what is happening before the error occurs.

3. From all I have read, the "Wrong Principal" error usually occurs if the machines have a mapping to 127.0.0.1 for their hostname.

You are using a syntax marked as DEPRECATED in the exports(5) manpage:

RPCSEC_GSS security
   You may use the special strings "gss/krb5", "gss/krb5i", or "gss/krb5p" to restrict
   access to clients using rpcsec_gss security.  However, this syntax is deprecated; on
   linux kernels  since  2.6.23,  you  should instead use the "sec=" export option:

   sec=   The  sec=  option,  followed  by a colon-delimited list of security flavors, restricts the export to clients using those flavors.  Available security flavors include sys (the default--no cryptographic secu‐
          rity), krb5 (authentication only), krb5i (integrity protection), and krb5p (privacy protection).  For the purposes of security flavor negotiation, order counts: preferred flavors  should  be  listed  first.
          The  order  of  the  sec=  option  with respect to the other options does not matter, unless you want some options to be enforced differently depending on flavor.  In that case you may include multiple sec=
          options, and following options will be enforced only for access using flavors listed in the immediately preceding sec= option.  The only options  that  are  permitted  to  vary  in  this  way  are  ro,  rw,
          no_root_squash, root_squash, and all_squash.

So your exports should be:

/srv      XXX.XXX.209.0/24(fsid=0,rw,no_subtree_check,root_squash,async,sec=krb5)
/srv/home XXX.XXX.209.0/24(rw,no_subtree_check,root_squash,async,sec=krb5)

It is important that both the fsid=0 and the exported resource have the correct security configuration. Choose the appropriate krb5/krb5i/krb5p for your setup.

The error "Wrong principal in request" can be caused by wrong name resolution. If you are using local resolution, inspect your /etc/hosts file.

People dealing with problems like this, usually do:

1. DNS names and FQDN of your hosts must be lowercase, even if your DNS supports Uppercase in FQDN.
2. You should have a principal named like your machine name, in example: [email protected], and add to keytab accordingly (all UPERCASE and ending with $)
3. You should have principals host/your-machine.your.domain.name and nfs/your-machine.your.domain.name, and add this principal to keytab accordingly.
4. Your /etc/hosts must not have uppercases names, and FQDN should be firsts than short name if any.