On Tue, Sep 15, 2020 at 02:06:23PM +0100, Chris Hall wrote: > Also FWIW, I gather that this is configuration for the client-side > 'mount' of nfs exports, *only*. I suppose it should be obvious that > this has absolutely nothing to do with configuring (server-side) > 'mountd'. Speaking as a fully paid up moron-in-a-hurry, it has > taken me a while to work that out :-( [I suggest that the comments > in the .conf files and the man-page could say that nfs.conf is > server-side and nfsmount.conf is client-side -- just a few words, > for the avoidance of doubt.] That sounds sensible. If you're feeling industrious, you can git clone git://linux-nfs.org/~steved/nfs-utils and patch those files and mail us a patch.... > Given that NFSv4 is going on 20 years old now, I do wonder why the > earlier versions are not treated a "legacy". Agreed, they basically are legacy now, but documentation's slow to catch up. > For example: I run nfs on my firewall machine so that I can > configure it from elsewhere on the network. Naturally, the firewall > machine is firmly wrapped so that it may only be accessed by > particular machines inside the network. I also try to ensure that > the absolute minimum number of daemons are running and the absolute > minumum number of ports are open. In that context, (a) is there a > way to persuade 'systemctl start nfs-service' to be "nfs4 only", and > to *not* start 'rpcbind' (and *not* open port 111), and (b) are > rpc.idmapd, rpc.mountd and rpc.statd required for nfs4 ? (ie, is > nfsdcld sufficient ?) For the server, you don't need rpcbind or rpc.statd for v4, but you do need rpc.idmapd, rpc.mountd and nfsdcld. rpc.mountd is the only one of those three that needs to listen on a network port, but that's only in the NFSv2/v3 case. I'm not sure if we're getting that right. --b.
