Out of curiosity what user does this run on other distros like Arch, Debian, Gentoo, RedHat, etc...?

This is somewhat confusing if you aren't familiar with the internals of nfs. Since you aren't running the service as the statd user the module simply appears to be creating a user for no apparent reason (if you don't know that rpc.statd will drop privileges based on the ownership of a directory, which I did not know). A comment would go a long way.

If we look at the mkdir usage in the preStart this starts to look like a mild security concern. If /var/lib/nfs is blown away for some reason and tmpfiles doesn't have a chance to run then the mkdir command will create directories owned by root and we're back to the (bad) situation the module is currently in. I would recommend removing all (or at least as much) usage of mkdir as possible here in favour of another solution (like tmpfiles.rules). It would become even easier if we made an attribute set to replace the exports option... but now I'm starting to make massive scope creep on this PR 😆

If we merge this PR now as is would you have capacity to either work on or review a PR which replaced the exports option with an attribute set?

Very good points - I totally missed those mkdirs @aanderse. It's been cleaned up now and some docs added too.

Found another mkdir invocation which is now gone.

It works here though. I just tried shutting down the nfs service, remove the directory and reboot the nas. This is what is created:

# ls -la nfs
total 8
drwx------  1 statd statd 132 Sep  7 20:22 .
drwxr-xr-x  1 root  root  256 Sep  7 20:22 ..
-rw-r--r--  1 root  root  207 Sep  7 20:22 etab
-rw-------  1 root  root    0 Sep  7 20:22 .etab.lock
-rw-r--r--  1 root  root    0 Sep  7 20:22 export-lock
drwxr-xr-x  1 root  root    0 Sep  7 20:22 recovery
dr-xr-xr-x 11 root  root    0 Sep  7 20:22 rpc_pipefs
drwxr-xr-x  1 root  root    0 Sep  7 20:22 sm
drwxr-xr-x  1 root  root    0 Sep  7 20:22 sm.bak
-rw-r--r--  1 root  root    4 Sep  7 20:22 state
drwxr-xr-x  1 root  root    0 Sep  7 20:22 v4recovery

This is admittedly with this PR applied to 20.03 which uses systemd 243. I don't know if anything changed since then.

@GrahamcOfBorg eval

This merge breaks a test #97582 (I checked a local revert). Unless we have a fix very soon (say, today), I suggest to revert it until the issue is resolved.

Thanks for handling this - things were working perfectly fine here. I'll get this fixed later.