Bug#1002826: rpc-svcgssd.service fails with "unable to obtain root (machine) credentials"
Sure, but why does systemctl complain about rpc-svcgssd.service, if there are no NFS credentials inside? Its perfectly fine to run NFS without cryptographic security, even though /etc/krb5.keytab does exist. I have the impression that the conditionals you mentioned are not complete.
Re: Bug#1002826: rpc-svcgssd.service fails with "unable to obtain root (machine) credentials"
Hi Salvatore, would it be possible to check if there are some NFS credentials in the krb5.keytab file before issuing an error? Regards Harri
Processed: Re: Bug#1002826: rpc-svcgssd.service fails with "unable to obtain root (machine) credentials"
Processing control commands: > tags -1 + moreinfo Bug #1002826 [nfs-common] rpc-svcgssd.service fails with "unable to obtain root (machine) credentials" Added tag(s) moreinfo. -- 1002826: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002826 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1002826: rpc-svcgssd.service fails with "unable to obtain root (machine) credentials"
Control: tags -1 + moreinfo Hi On Wed, Dec 29, 2021 at 02:36:14PM +0100, Harald Dunkel wrote: > Package: nfs-common > Version: 1:1.3.4-6 > > systemd moans about krb5.keytab at boot time > > ``` > # systemctl --failed > UNITLOAD ACTIVE SUBDESCRIPTION > * rpc-svcgssd.service loaded failed failed RPC security service for NFS server > > LOAD = Reflects whether the unit definition was properly loaded. > ACTIVE = The high-level unit activation state, i.e. generalization of SUB. > SUB= The low-level unit activation state, values depend on unit type. > 1 loaded units listed. > > # systemctl status rpc-svcgssd > * rpc-svcgssd.service - RPC security service for NFS server > Loaded: loaded (/etc/systemd/system/rpc-svcgssd.service; static) > Active: failed (Result: exit-code) since Wed 2021-12-29 14:00:51 CET; > 8min ago > Process: 301 ExecStart=/usr/sbin/rpc.svcgssd $SVCGSSDARGS (code=exited, > status=1/FAILURE) > CPU: 6ms > > Dec 29 14:00:50 nfs00.example.com systemd[1]: Starting RPC security service > for NFS server... > Dec 29 14:00:50 nfs00.example.com rpc.svcgssd[302]: 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/@ > Dec 29 14:00:50 nfs00.example.com rpc.svcgssd[302]: unable to obtain root > (machine) credentials > Dec 29 14:00:50 nfs00.example.com rpc.svcgssd[302]: do you have a keytab > entry for nfs/@ in /etc/krb5.keytab? > Dec 29 14:00:51 nfs00.example.com systemd[1]: rpc-svcgssd.service: Control > process exited, code=exited, status=1/FAILURE > Dec 29 14:00:51 nfs00.example.com systemd[1]: rpc-svcgssd.service: Failed > with result 'exit-code'. > Dec 29 14:00:51 nfs00.example.com systemd[1]: Failed to start RPC security > service for NFS server. > ``` > > Shouldn't svcgssd either exit silently with 0 or become optional? Looking at > nfs(5) Kerberos authentication for NFS appears to be optional, regardless if > there is a keytab file with or without NFS credentials. The rpc-svcgssd.service already has some conditionals: ConditionPathExists=|!/run/gssproxy.pid ConditionPathExists=|!/proc/net/rpc/use-gss-proxy ConditionPathExists=/etc/krb5.keytab If no /etc/krb5.keytab exists in fact the status will be ○ rpc-svcgssd.service - RPC security service for NFS server Loaded: loaded (/usr/lib/systemd/system/rpc-svcgssd.service; static) Active: inactive (dead) Condition: start condition failed at Tue 2021-12-21 10:28:53 CET; 1 week 1 day ago If you have a /etc/krb5.keytab then the condition is met to try to start rpc-svcgssd. Regards, Salvatore
Bug#1002826: rpc-svcgssd.service fails with "unable to obtain root (machine) credentials"
Package: nfs-common Version: 1:1.3.4-6 systemd moans about krb5.keytab at boot time ``` # systemctl --failed UNITLOAD ACTIVE SUBDESCRIPTION * rpc-svcgssd.service loaded failed failed RPC security service for NFS server LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB= The low-level unit activation state, values depend on unit type. 1 loaded units listed. # systemctl status rpc-svcgssd * rpc-svcgssd.service - RPC security service for NFS server Loaded: loaded (/etc/systemd/system/rpc-svcgssd.service; static) Active: failed (Result: exit-code) since Wed 2021-12-29 14:00:51 CET; 8min ago Process: 301 ExecStart=/usr/sbin/rpc.svcgssd $SVCGSSDARGS (code=exited, status=1/FAILURE) CPU: 6ms Dec 29 14:00:50 nfs00.example.com systemd[1]: Starting RPC security service for NFS server... Dec 29 14:00:50 nfs00.example.com rpc.svcgssd[302]: 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/@ Dec 29 14:00:50 nfs00.example.com rpc.svcgssd[302]: unable to obtain root (machine) credentials Dec 29 14:00:50 nfs00.example.com rpc.svcgssd[302]: do you have a keytab entry for nfs/@ in /etc/krb5.keytab? Dec 29 14:00:51 nfs00.example.com systemd[1]: rpc-svcgssd.service: Control process exited, code=exited, status=1/FAILURE Dec 29 14:00:51 nfs00.example.com systemd[1]: rpc-svcgssd.service: Failed with result 'exit-code'. Dec 29 14:00:51 nfs00.example.com systemd[1]: Failed to start RPC security service for NFS server. ``` Shouldn't svcgssd either exit silently with 0 or become optional? Looking at nfs(5) Kerberos authentication for NFS appears to be optional, regardless if there is a keytab file with or without NFS credentials. Regards Harri
