Bugzilla – Bug 1217885
dracut: the nfs module issues "rpc.statd: Running as root. chown /var/lib/nfs to choose different user"
Last modified: 2024-02-23 08:02:33 UTC
Created attachment 871199 [details] dracut patch While testing the dracut nfs module in Tumbleweed, I found this warning in the journal: > Dec 07 14:07:30 localhost systemd[1]: Starting dracut pre-udev hook... > Dec 07 14:07:30 localhost kernel: RPC: Registered named UNIX socket transport m> > Dec 07 14:07:30 localhost kernel: RPC: Registered udp transport module. > Dec 07 14:07:30 localhost kernel: RPC: Registered tcp transport module. > Dec 07 14:07:30 localhost kernel: RPC: Registered tcp-with-tls transport module. > Dec 07 14:07:30 localhost kernel: RPC: Registered tcp NFSv4.1 backchannel trans> > Dec 07 14:07:30 localhost rpc.statd[363]: Version 2.6.3 starting > Dec 07 14:07:30 localhost rpc.statd[363]: Initializing NSM state > ---> Dec 07 14:07:30 localhost rpc.statd[363]: Running as root. chown /var/lib/nfs to choose different user > Dec 07 14:07:30 localhost rpc.idmapd[477]: Setting log level to 0 > Dec 07 14:07:30 localhost rpc.idmapd[477]: libnfsidmap: requested translation method, 'nsswitch', is not available > Dec 07 14:07:30 localhost systemd[1]: Finished dracut pre-udev hook. I never saw this in SLE, but then I noticed that nfs-utils adds the statd user via sysusers.d configuration since version 2.5.1: > $ rpm -qf /usr/lib/sysusers.d/statd-user.conf > nfs-client-2.6.3-41.1.x86_64 > $ cat /usr/lib/sysusers.d/statd-user.conf > # Type Name ID GECOS [HOME] Shell > u statd - "NFS statd daemon" /var/lib/nfs - Also, the nfs-utils.spec file defines: > # lib/nfs must be root-owned. > # sm and sm.back and contents should be statd:statd, > # but only chown if the dirs are currently root-owned. > # This is needed for some upgraded, but chown is best avoided > # when not necessary > ... > %{_sysusersdir}/statd-user.conf > %dir %{_localstatedir}/lib/nfs > %dir %{_localstatedir}/lib/nfs/rpc_pipefs > %dir %{_localstatedir}/lib/nfs/v4recovery > %attr(0700,statd,statd) %dir %{_localstatedir}/lib/nfs/sm > %attr(0700,statd,statd) %dir %{_localstatedir}/lib/nfs/sm.bak > %ghost %{_localstatedir}/lib/nfs/state Neil, I can't find this in nfs-utils upstream, is this SUSE-specific? how bad is this warning? should we add a custom patch (maybe similar to the one attached) to the dracut nfs module to avoid it?
Why are we even running rpc.statd from the initrd - that doesn't make a lot of sense. What filesystem is being mounted? Presumably a root filesystem? Is this root filesystem shared with other clients? If so do all the clients treat as read-only? If the filesystem mounted is never shared, or if it is only accessed read-only. then we don't need NFS locking, and so don't need rpc.statd. Possibly the problem is that NFS is starting rpc.statd when it doesn't need to.
(In reply to Neil Brown from comment #1) > Why are we even running rpc.statd from the initrd - that doesn't make a lot > of sense. Maybe this code is outdated, it was introduced in 2009 (https://github.com/dracutdevs/dracut/commit/f6f74096f6fa2bac0e841f21134dba00b5b65d9a), at least it was added with the following comment: ``` # Start rpc.statd as mount won't let us use locks on a NFSv4 # filesystem without talking to it. NFSv4 does locks internally, # rpc.lockd isn't needed ``` > What filesystem is being mounted? Presumably a root filesystem? Yes. > Is this root filesystem shared with other clients? If so do all the clients > treat as read-only? I don't know the answer to this question. Thomas, have you ever seen the dracut nfs module on a real customer setup? > If the filesystem mounted is never shared, or if it is only accessed > read-only. then we don't need NFS locking, and so don't need rpc.statd. > > Possibly the problem is that NFS is starting rpc.statd when it doesn't need > to. Thanks for this background.
(In reply to Antonio Feijoo from comment #2) > > Is this root filesystem shared with other clients? If so do all the clients > > treat as read-only? > > I don't know the answer to this question. Thomas, have you ever seen the > dracut nfs module on a real customer setup? Yeah, I remember some setups on diskless clients. But Neil is right, a shared rw nfsroot doesn't make any sense as clients would overwrite each other. AFAICR all of these shared nfsroot setups were ro. So, I guess we can live without NFS locking for nfsroot in the initrd. Still, I would put a kind of warning there that shared nfsroot in rw mode is not supported. Just in case someone finds a usecase one day.