On 14/09/2020 19:30, Steve Dickson wrote:
Hello,
On 9/11/20 7:45 AM, Chris Hall wrote:
I have a client and server configured for nfs4 only.
Would you mind sharing this configuration? Privately if
that works better...
The client /etc/nfsmount.conf has:
[ NFSMount_Global_Options ]
Defaultvers=4
Nfsvers=4
Defaultproto=tcp
Proto=tcp
and (now, see below) nothing else.
FWIW, I guess setting the 'Defaultvers' and 'Defaultproto' is
redundant... but does not appear to stop anything from working.
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.]
The server /etc/nfs.conf has only:
[nfsd]
debug=0
threads=8
host=cerberus2
port=1001
# grace-time=90
# lease-time=90
udp=n
tcp=y
vers2=n
vers3=n
vers4=y
vers4.0=y
vers4.1=y
vers4.2=y
I wish I knew whether the 'vers4.X' settings make the slightest
difference. This server is my firewall, hence the funky port number.
I'm thinking that is a good direction to go towards
so maybe we make this configuration the default??
I don't use nfs very much, but every time I have tangled with it I have
come way limping :-(
Given that NFSv4 is going on 20 years old now, I do wonder why the
earlier versions are not treated a "legacy". When trying to discover
how to configure and use nfs I find I am still wading through stuff
which does not apply to NFSv4. Much of what the "wisdom of the
Internet" has to offer seems firmly routed in the past, and often NFSv4
is describe in terms of its difference from NFSv3 and v2.
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 ?)
The configuration used to work.
I have just upgraded from Fedora 31 to 32 on the client. I now get:
# mount /foo
mount.nfs4: Protocol not supported
I've been trying to keep the versions the same... hopefully
nothing has broken in f31... ;-(
Rest easy: my problem was entirely self inflicted -- it had nothing
directly to do with the upgrade from Fedora 31 to 32.
Since the client 'mount' and 'mount.nfs4' were not even attempting to
speak to the server, I downloaded the source and the debug symbols and
had a go at it with strace and gdb...
...and discovered that I had caused the problem by setting:
mountproto=tcp
mountvers=4
in /etc/nfsmount.conf at the client end. [Full disclosure: I am
building a replacement for the server and was reviewing all
configuration at both ends, updating Fedora all round and generally
tidying up.]
It turns out that mount.nfs4 takes a dim view of the existence of these
settings and declines to do the mount(2) call; instead it sets
errno=EPROTONOSUPPORT and returns as if the mount(2) had failed. [See
nfs_do_mount_v4() in stropts.c of utils/mount/. I note in passing that
it worries about "mounthost", "mountaddr", "mountvers" and "mountproto",
where "mountaddr" is not mentioned in the man-page for nfs. But it does
not worry about "mountport", which is mentioned in the man-page.]
Having checked carefully, I now know that mountport, mountproto,
mounthost and mountvers are all "Options for NFS versions 2 and 3 only".
But I don't know if their presence with 'nfsvers=4' would cause
mount(2) to fail.
In any case, frankly, I think that mount is being singularly obtuse.
Since it knows that these options do not apply, it could IMHO simply
discard them. If that's a step too far, it could produce a rather more
informative message -- in particular *not* the standard system message
for EPROTONOSUPPORT, which a quick search of POSIX.1-2017 tells me is
returned only by socket() and socketpair() !
Thanks,
Chris
