FAILED RPC Security Service for NFS Server after 4.3 Upgrade

UCS - Univention Corporate Server
, ,
#1

Hi

After upgrading version 4.2.3 to 4.3 I get this error at boot time.

[FAILED] Failed to start RPC Security service for NFS Server.

In more detail:

root @ server: ~ # systemctl status rpc-svcgssd.service
● rpc-svcgssd.service - RPC security service for NFS server
   Loaded: loaded (/lib/systemd/system/rpc-svcgssd.service; static; vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2018-03-14 17:24:35 -03; 10 minutes ago
  Process: 678 ExecStart = / usr / sbin / rpc.svcgssd $ SVCGSSDARGS (code = exited, status = 1 / FAILURE)
      CPU: 3ms

Mar 14 17:24:35 server systemd [1]: Starting RPC security service for NFS server ...
Mar 14 17:24:35 server systemd [1]: rpc-svcgssd.service: Control process exited, code = exited status = 1
Mar 14 17:24:35 server systemd [1]: Failed to start RPC security service for NFS server.
Mar 14 17:24:35 server systemd [1]: rpc-svcgssd.service: Unit entered failed state.
Mar 14 17:24:35 server systemd [1]: rpc-svcgssd.service: Failed with result 'exit-code'.
#2

I’ve got same error after upgrade to 4.3

#3

Hey,

are you two actually using NFSv4 with Kerberos integrity or security? 'cause that daemon should only be needed in that case, not for NFSv2 or v3. And in a default UCS setup NFSv4 with Kerberos isn’t provided out of the box. As a matter of fact, it doesn’t seem to work with Samba4’s Kerberos at the moment either.

So this is something that can probably be ignored. If it annoys you, tell systemd not to start the unit via systemctl mask rpc-svcgssd.service

The actual reason why the start of the daemon fails is that it cannot find the Kerberos principal nfs/FQDN@REALM in /etc/krb5.keytab. You can see the actual error message by running /usr/sbin/rpc.svcgssd -f — and you can verify you don’t have that principal via ktutil --keytab=/etc/krb5.keytab list

Kind regards,
mosu

#4

Hi,
I neither can’t remember accidantially enable this setting nor using NFSv4 with Kerb.
On 4.2 this service never causes some trouble - just saw the message after upgrade to 4.3

#5

Like I said: ignore the error if you’re not trying to use NFSv4.

#6

Actually, I’m not using NFS. In this case, I will follow your suggestion and turn off the warning.
Just out of curiosity, follow the result of the command you mentioned.

root @ server: ~ # /usr/sbin/rpc.svcgssd -f
ERROR: GSS-API: error in gss_acquire_cred (): GSS_S_FAILURE (failure in GSS not specified - no matching key table entry nfs / @
unable to get root credentials (machine)
do you have a keytab entry for nfs / <your.host> @ <YOUR.REALM> in /etc/krb5.keytab?

Probably more people will find this warning. In my case, I’m just suppressing the warning.

Thank you,
Michael

#7

Yeah, I know that the daemon outputs a bogus principal; not sure why it does that. What I was referring to above is that the intended use is to have a Kerberos principal such as e.g. nfs/master.my.domain@MY.DOMAIN in /etc/krb5.keytab, and by default such a principal doesn’t exist. The NFSv4 guide I linked to above creates that principal for the same reason. So even if the daemon were looking for the correct principal, it still wouldn’t find it and refuse to start.

#8

Thanks for the explanation, I got it.

Thank you very much,
Michael Voigt

#9

It’s unfortunately a combination of multiple things:

  • nfs-kernel-server is installed on all UCS server roles by default
  • we do not yet configure NFS with Kerberos in UCS
  • with UCS-4.3 the NFS related services are now started by systemd - with UCS-4.2 it was still init.d
  • The check for starting rcp-svcgssd.service is too simplistic: It only checks for the existence of /etc/krb5.keytab and then assumes, that Kerberos is going to be used for NFS, too. But the service itself then will complain about the missing nfs/ principal and abort with an error.
  • That file always exists in UCS as we always configure Kerberos - either via Samba4 itself or Heimdal when Samba4 is not used.

The defect is known and will be fixed when it reaches the top of our priority list.

For now just forcefully mask the service:

systemctl stop rpc-svcgssd.service
systemctl disable rpc-svcgssd.service
systemctl mask rpc-svcgssd.service
Mastodon