nfs-utils (1.3.1-r5 tested) provides a number of systemd unit files. These unit files have a top dependency nfs-server, which pulls in a number of services indiscriminately, regardless of whether you are using nfs v2,3,4. In the ebuild there appears to be some attempt to control this (specifically starting idmapd.service), by setting this up in /etc/conf.d/nfs, but as explained in bug 544772, the variables in this file are not read. Why does this matter? It makes debugging NFS problems difficult. Depending on the version you are using, you may not need a number of services, which, when started will fail if e.g. they haven't been configured (as they're not used). It would be better if nfs-server had the correct 'wants', so that e.g. if you only use nfs4, idmapd is tarted, as well as var_lib_nfs_rpc-pipe.mount, but NOT statd, or rpcbind, which are only required for v2/3. Here is a suggestion for how to resolve this: 1) add a nfs2 and nfs3 use flag 2) create a nfs-server.wants directory (as described in `man service.unit`) that is populated with the services depending on the use flags. 3) As mentioned above, fix bug 544772, and default /etc/conf.d/nfs with rpc.nfsd start variables corresponding to use flag. e.g. if you enabled nfs4 then append '-V 4' otherwise '-N 4' to explicitly enable/disable the version. Alternatively maybe set up different slots Reproducible: Always Steps to Reproduce: Here is an example. You only care about nfs4. systemctl start nfs-server will block, due to bug 455772, because the aforementioned 'mount' target is not enabled. However, pinpointing this is difficult. Looking in journalctl will show failure of a number of processes (rpcbind, statd) which are irrelevant. Expected Results: Only the services which are relevant for that version of NFS should be started. Have a look at arch wiki nfs, that gives some clarity on which process should/should not be started.
