Bug 1217885

Summary: dracut: the nfs module issues "rpc.statd: Running as root. chown /var/lib/nfs to choose different user"
Product: [openSUSE] openSUSE Tumbleweed Reporter: Antonio Feijoo <antonio.feijoo>
Component: BasesystemAssignee: dracut maintainers <dracut-maintainers>
Status: NEW --- QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: nfbrown, thomas.blume
Version: Current   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: dracut patch

Description Antonio Feijoo 2023-12-07 15:03:04 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?
Comment 1 Neil Brown 2023-12-08 00:19:14 UTC 
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.
Comment 2 Antonio Feijoo 2023-12-12 07:45:17 UTC 
(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.
Comment 3 Thomas Blume 2023-12-12 08:17:12 UTC 
(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.