Bug 46690 - After Update 4.2 -> 4.3: NFS does not start
After Update 4.2 -> 4.3: NFS does not start
Status: RESOLVED DUPLICATE of bug 46587
Product: UCS
Classification: Unclassified
Component: NFS
UCS 4.3
amd64 Linux
: P5 normal (vote)
: ---
Assigned To: Philipp Hahn
UCS maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-03-17 13:24 CET by t0mc
Modified: 2018-04-14 13:52 CEST (History)
2 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 1: Cosmetic issue or missing function but workaround exists
Who will be affected by this bug?: 5: Will affect all installed domains
How will those affected feel about the bug?: 1: Nuisance – not a big deal but noticeable
User Pain: 0.029
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description t0mc 2018-03-17 13:24:30 CET
Hi everybody,

just updated my UCS from 4.2 to 4.3 yesterday and today I noticed that NFS Server isn't running. When trying to start it manually, it fails, this is in /var/log/syslog:

Mar 17 13:06:21 hostname systemd[1]: Starting Kernel Module supporting RPCSEC_GSS...
Mar 17 13:06:21 hostname systemd[1]: Starting Preprocess NFS configuration...
Mar 17 13:06:21 hostname systemd[1]: Started Kernel Module supporting RPCSEC_GSS.
Mar 17 13:06:21 hostname systemd[1]: Started Preprocess NFS configuration.
Mar 17 13:06:21 hostname systemd[1]: Starting NFS Mount Daemon...
Mar 17 13:06:21 hostname systemd[1]: Starting NFSv4 ID-name mapping service...
Mar 17 13:06:21 hostname systemd[1]: Starting RPC security service for NFS server...
Mar 17 13:06:21 hostname systemd[1]: Started NFSv4 ID-name mapping service.
Mar 17 13:06:21 hostname systemd[1]: Started NFS Mount Daemon.
Mar 17 13:06:21 hostname rpc.mountd[11210]: Version 1.3.3 starting
Mar 17 13:06:21 hostname rpc.svcgssd[11209]: ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure.  Minor code may provide more information) - No key table entry found matching nfs/@
Mar 17 13:06:21 hostname rpc.svcgssd[11209]: unable to obtain root (machine) credentials
Mar 17 13:06:21 hostname rpc.svcgssd[11209]: do you have a keytab entry for nfs/<your.host>@<YOUR.REALM> in /etc/krb5.keytab?
Mar 17 13:06:21 hostname systemd[1]: rpc-svcgssd.service: Control process exited, code=exited status=1
Mar 17 13:06:21 hostname systemd[1]: Failed to start RPC security service for NFS server.
Mar 17 13:06:21 hostname systemd[1]: rpc-svcgssd.service: Unit entered failed state.
Mar 17 13:06:21 hostname systemd[1]: rpc-svcgssd.service: Failed with result 'exit-code'.


Looks like some issue with Kerberos/SSO changes?
How can I correct krb5.keytab?
Comment 1 Philipp Hahn univentionstaff 2018-03-18 07:34:54 CET
We already know about the isse about rpc-svcgssd.service, which is tracked as Bug #46587: This is a "minor" issue as it only is relevant for NFS exports using Kerberos, which currently is not supported by UCS. Everything else does work.
You can mask the error by running the following command as user root to mask the error:
  systemctl mask rpc-svcgssd.service

*** This bug has been marked as a duplicate of bug 46587 ***