From: Chris Hall <linux-nfs@gmch.uk>
To: linux-nfs@vger.kernel.org
Subject: Re: mount.nfs4 and logging
Date: Tue, 15 Sep 2020 14:06:23 +0100 [thread overview]
Message-ID: <f7b9c8b4-29a6-2f28-b1d9-739c546fd557@gmch.uk> (raw)
In-Reply-To: <f06f86ef-08bd-3974-3d92-1fbda700cc11@RedHat.com>
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
next prev parent reply other threads:[~2020-09-16 0:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <S1725851AbgIKKt5/20200911104957Z+185@vger.kernel.org>
2020-09-11 11:45 ` mount.nfs4 and logging Chris Hall
2020-09-14 18:30 ` Steve Dickson
2020-09-15 13:06 ` Chris Hall [this message]
2020-09-16 12:52 ` Kenneth Dsouza
2020-09-16 14:31 ` Kenneth Dsouza
2020-09-16 17:31 ` Kenneth Dsouza
2020-09-19 16:33 ` J. Bruce Fields
2020-09-19 16:40 ` J. Bruce Fields
[not found] ` <12298172-f830-4f22-8612-dfbbc74b8a40@gmch.uk>
2020-09-20 19:32 ` J. Bruce Fields
2020-09-21 14:40 ` Chris Hall
2020-09-23 14:40 ` J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f7b9c8b4-29a6-2f28-b1d9-739c546fd557@gmch.uk \
--to=linux-nfs@gmch.uk \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.