I have a client and server configured for nfs4 only.
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
Wireshark does not detect any attempt by the client to talk to the server.
I get the same result if I do mount.nfs4 directly.
Can I wind up the logging for mount.nfs4 ? Or otherwise find a way to
discover why the "Protocol not supported" message is being issued ?
Thanks,
Chris
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...
I'm thinking that is a good direction to go towards
so maybe we make this configuration the default??
>
> 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... ;-(
>
> Wireshark does not detect any attempt by the client to talk to the server.
>
> I get the same result if I do mount.nfs4 directly.
>
> Can I wind up the logging for mount.nfs4 ?
What server are you using?
> Or otherwise find a way to discover why the "Protocol not supported" message is being issued ?
Does rpcdebug -m nfs -s mount and mount -vvv show anything?
steved.
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
I had come across a similar issue in the past.
I had debugged the issue by checking what mount options were passed by
doing the below:
# LIBMOUNT_DEBUG=0xffff mount -t nfs nfs-server:/example /mnt -o
vers=4.0 | less
:
19709: libmount: CXT: [0x556249623030]: fixed options [rc=0]:
vfs: 'rw' fs: 'vers=4.0,mountvers=4' user: '(null)', optstr:
'rw,vers=4.0,mountvers=4' <----
19709: libmount: CXT: [0x556249623030]: preparing source path
19709: libmount: CXT: [0x556249623030]: preparing target path
19709: libmount: CXT: [0x556249623030]: final target '/mnt'
19709: libmount: CXT: [0x556249623030]: FS type: nfs [rc=0]
mount.nfs: Protocol not supported <----
The mountvers option is only applicable for nfsv3 and is not supported
for nfsv4. Whenever mount command is called explicitly with mount.nfs4
or vers=4.0,4.1 or 4.2 it will fail.
I finally removed the setting from /etc/nfsmount.conf to fix the issue.
I had a patch to add debugging to make the end user aware of what was
going wrong.
[PATCH] mount.nfs: Do not retry if Mountd related options are passed for nfs4
When Mountd related options are passed with mount.nfs4
or -t nfs vers=4 we fallback and retry with below version.
As these options are not supported we should fail at first
try and error out.
This patch also adds mountport to the unsupported list for NFSv4.
Signed-off-by: Kenneth D'souza <[email protected]>
---
utils/mount/stropts.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/utils/mount/stropts.c b/utils/mount/stropts.c
index 901f995a..cad64bd8 100644
--- a/utils/mount/stropts.c
+++ b/utils/mount/stropts.c
@@ -86,6 +86,7 @@ extern int nfs_mount_data_version;
extern char *progname;
extern int verbose;
extern int sloppy;
+int failure =0;
struct nfsmount_info {
const char *spec, /* server:/path */
@@ -756,13 +757,19 @@ static int nfs_do_mount_v4(struct nfsmount_info *mi,
if (po_contains(options, "mounthost") ||
po_contains(options, "mountaddr") ||
po_contains(options, "mountvers") ||
+ po_contains(options, "mountport") ||
po_contains(options, "mountproto")) {
/*
* Since these mountd options are set assume version 3
* is wanted so error out with EPROTONOSUPPORT so the
* protocol negation starts with v3.
*/
+ if (verbose) {
+ printf(_("%s: Unsupported nfs4 mount option passed '%s'\n"),
+ progname, *mi->extra_opts);
+ }
errno = EPROTONOSUPPORT;
+ failure = 1;
goto out_fail;
}
@@ -892,6 +899,8 @@ static int nfs_autonegotiate(struct nfsmount_info *mi)
int result, olderrno;
result = nfs_try_mount_v4(mi);
+ if (failure == 1 && errno == EPROTONOSUPPORT)
+ goto fall_back;
check_result:
if (result)
return result;
--
On Wed, Sep 16, 2020 at 6:09 AM Chris Hall <[email protected]> wrote:
>
> 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
>
I had come across a similar issue in the past.
I had debugged the issue by checking what mount options were passed by
doing the below:
# LIBMOUNT_DEBUG=0xffff mount -t nfs nfs-server:/example /mnt -o
vers=4.0 | less
:
19709: libmount: CXT: [0x556249623030]: fixed options [rc=0]:
vfs: 'rw' fs: 'vers=4.0,mountvers=4' user: '(null)', optstr:
'rw,vers=4.0,mountvers=4' <----
19709: libmount: CXT: [0x556249623030]: preparing source path
19709: libmount: CXT: [0x556249623030]: preparing target path
19709: libmount: CXT: [0x556249623030]: final target '/mnt'
19709: libmount: CXT: [0x556249623030]: FS type: nfs [rc=0]
mount.nfs: Protocol not supported <----
The mountvers option is only applicable for nfsv3 and is not supported
for nfsv4. Whenever mount command is called explicitly with mount.nfs4
or vers=4.0,4.1 or 4.2 it will fail.
I finally removed the setting from /etc/nfsmount.conf to fix the issue.
I had a patch to add debugging to make the end user aware of what was
going wrong.
[PATCH] mount.nfs: Do not retry if Mountd related options are passed for nfs4
When Mountd related options are passed with mount.nfs4
or -t nfs vers=4 we fallback and retry with below version.
As these options are not supported we should fail at first
try and error out.
This patch also adds mountport to the unsupported list for NFSv4.
Signed-off-by: Kenneth D'souza <[email protected]>
---
utils/mount/stropts.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/utils/mount/stropts.c b/utils/mount/stropts.c
index 901f995a..cad64bd8 100644
--- a/utils/mount/stropts.c
+++ b/utils/mount/stropts.c
@@ -86,6 +86,7 @@ extern int nfs_mount_data_version;
extern char *progname;
extern int verbose;
extern int sloppy;
+int failure =0;
struct nfsmount_info {
const char *spec, /* server:/path */
@@ -756,13 +757,19 @@ static int nfs_do_mount_v4(struct nfsmount_info *mi,
if (po_contains(options, "mounthost") ||
po_contains(options, "mountaddr") ||
po_contains(options, "mountvers") ||
+ po_contains(options, "mountport") ||
po_contains(options, "mountproto")) {
/*
* Since these mountd options are set assume version 3
* is wanted so error out with EPROTONOSUPPORT so the
* protocol negation starts with v3.
*/
+ if (verbose) {
+ printf(_("%s: Unsupported nfs4 mount option passed '%s'\n"),
+ progname, *mi->extra_opts);
+ }
errno = EPROTONOSUPPORT;
+ failure = 1;
goto out_fail;
}
@@ -892,6 +899,8 @@ static int nfs_autonegotiate(struct nfsmount_info *mi)
int result, olderrno;
result = nfs_try_mount_v4(mi);
+ if (failure == 1 && errno == EPROTONOSUPPORT)
+ goto fall_back;
check_result:
if (result)
return result;
--
On Wed, Sep 16, 2020 at 6:09 AM Chris Hall <[email protected]> wrote:
>
> 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
>
I had come across a similar issue in the past.
I had debugged the issue by checking what mount options were passed by
doing the below:
# LIBMOUNT_DEBUG=0xffff mount -t nfs nfs-server:/example /mnt -o
vers=4.0 | less
:
19709: libmount: CXT: [0x556249623030]: fixed options [rc=0]:
vfs: 'rw' fs: 'vers=4.0,mountvers=4' user: '(null)', optstr:
'rw,vers=4.0,mountvers=4' <----
19709: libmount: CXT: [0x556249623030]: preparing source path
19709: libmount: CXT: [0x556249623030]: preparing target path
19709: libmount: CXT: [0x556249623030]: final target '/mnt'
19709: libmount: CXT: [0x556249623030]: FS type: nfs [rc=0]
mount.nfs: Protocol not supported <----
The mountvers option is only applicable for nfsv3 and is not supported
for nfsv4. Whenever mount command is called explicitly with mount.nfs4
or vers=4.0,4.1 or 4.2 it will fail.
I finally removed the setting from /etc/nfsmount.conf to fix the issue.
I had a patch to add debugging to make the end user aware of what was
going wrong.
[PATCH] mount.nfs: Do not retry if Mountd related options are passed for nfs4
When Mountd related options are passed with mount.nfs4
or -t nfs vers=4 we fallback and retry with below version.
As these options are not supported we should fail at first
try and error out.
This patch also adds mountport to the unsupported list for NFSv4.
Signed-off-by: Kenneth D'souza <[email protected]>
---
utils/mount/stropts.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/utils/mount/stropts.c b/utils/mount/stropts.c
index 901f995a..cad64bd8 100644
--- a/utils/mount/stropts.c
+++ b/utils/mount/stropts.c
@@ -86,6 +86,7 @@ extern int nfs_mount_data_version;
extern char *progname;
extern int verbose;
extern int sloppy;
+int failure =0;
struct nfsmount_info {
const char *spec, /* server:/path */
@@ -756,13 +757,19 @@ static int nfs_do_mount_v4(struct nfsmount_info *mi,
if (po_contains(options, "mounthost") ||
po_contains(options, "mountaddr") ||
po_contains(options, "mountvers") ||
+ po_contains(options, "mountport") ||
po_contains(options, "mountproto")) {
/*
* Since these mountd options are set assume version 3
* is wanted so error out with EPROTONOSUPPORT so the
* protocol negation starts with v3.
*/
+ if (verbose) {
+ printf(_("%s: Unsupported nfs4 mount option passed '%s'\n"),
+ progname, *mi->extra_opts);
+ }
errno = EPROTONOSUPPORT;
+ failure = 1;
goto out_fail;
}
@@ -892,6 +899,8 @@ static int nfs_autonegotiate(struct nfsmount_info *mi)
int result, olderrno;
result = nfs_try_mount_v4(mi);
+ if (failure == 1 && errno == EPROTONOSUPPORT)
+ goto fall_back;
check_result:
if (result)
return result;
--
On Wed, Sep 16, 2020 at 6:09 AM Chris Hall <[email protected]> wrote:
>
> 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
>
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.
On Sat, Sep 19, 2020 at 12:33:53PM -0400, J. Bruce Fields wrote:
> 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.
Looking at the code, it looks correct--I see mountd starting those
listeners only when v2 or v3 are configured.
The documentation could be better, though.
--b.
On Sun, Sep 20, 2020 at 10:56:28AM +0100, Chris Hall wrote:
> On 19/09/2020 17:40, J. Bruce Fields wrote:
> >On Sat, Sep 19, 2020 at 12:33:53PM -0400, J. Bruce Fields wrote:
> >>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.
>
> >Looking at the code, it looks correct--I see mountd starting those
> >listeners only when v2 or v3 are configured.
>
> Well, on the machine in question, after a reboot I have:
>
> [root@cerberus ~]# netstat ...
> Proto Local Address Foreign Address State PID/Prog
> tcp 10.25.54.61:1022 0.0.0.0:* LISTEN 767/sshd
> tcp 10.25.54.61:1022 79.xx.xx.xx:57456 ESTAB. 770/sshd root
> [root@cerberus ~]# pstree
> systemd─┬─agetty
> ├─atd
> ├─auditd───{auditd}
> ├─crond
> ├─dbus-broker-lau───dbus-broker
> ├─gssproxy───5*[{gssproxy}]
> ├─mcelog
> ├─rngd───4*[{rngd}]
> ├─rsyslogd───2*[{rsyslogd}]
> ├─sshd───sshd───sshd───bash───pstree
> ├─systemd-homed
> ├─systemd-journal
> ├─systemd-logind
> └─systemd-udevd
>
> where the only port which is open is the "obscure" sshd.
>
> Then I start nfs-server and:
>
> [root@cerberus ~]# systemctl start nfs-server
> [root@cerberus ~]# netstat ...
> Proto Local Address Foreign Address State PID/Prog
> tcp 10.25.54.61:1022 0.0.0.0:* LISTEN 767/sshd
> tcp 79.xx.xx.xx:1001 0.0.0.0:* LISTEN -
> tcp 0.0.0.0:46921 0.0.0.0:* LISTEN 817/rpc.statd
> tcp 0.0.0.0:111 0.0.0.0:* LISTEN 1/systemd
> tcp 10.25.54.61:1022 79.xx.xx.xx:57456 ESTAB. 770/sshd:
> tcp6 :::35545 :::* LISTEN 817/rpc.statd
> tcp6 :::111 :::* LISTEN 1/systemd
> udp 0.0.0.0:54902 0.0.0.0:* 817/rpc.statd
> udp 0.0.0.0:111 0.0.0.0:* 1/systemd
> udp 0.0.0.0:62840 0.0.0.0:* 815/rpcbind
> udp6 :::61316 :::* 815/rpcbind
> udp6 :::111 :::* 1/systemd
> udp6 :::58536 :::* 817/rpc.statd
> [root@cerberus ~]# pstree
> systemd─┬─agetty
> ├─atd
> ├─auditd───{auditd}
> ├─crond
> ├─dbus-broker-lau───dbus-broker
> ├─gssproxy───5*[{gssproxy}]
> ├─mcelog
> ├─nfsdcld
> ├─rngd───4*[{rngd}]
> ├─rpc.idmapd
> ├─rpc.mountd
> ├─rpc.statd
> ├─rpcbind
> ├─rsyslogd───2*[{rsyslogd}]
> ├─sshd───sshd───sshd───bash───pstree
> ├─systemd-homed
> ├─systemd-journal
> ├─systemd-logind
> └─systemd-udevd
>
> Where nfsdcld, rpc.idmapd and rpc.mountd have indeed been started
> but are not bound to any ports.
That looks good. (And rpc.mountd does still serve a purpose in the
NFSv4 case, answering requests from the kernel for information related
to exported filesystems.)
> But rpc.statd and rpcbind have also been started, and various ports
> have been opened, including port 111 which is bound to systemd. Is
> there a way to inhibit that for nfs4 only ?
Unlike rpc.mountd, there's no reason for those to be running at all.
You can mask thoe corresponding systemd units.
It'd be nice if there was a way to make that happen automatically if v2
and v3 are configured out in the configuration files, but I don't know
how to make that happen.
--b.
>
> The /etc/nfs.conf says:
>
> [nfsd]
> debug=0
> threads=8
> host=cerberus
> port=1001
> udp=n
> tcp=y
> vers2=n
> vers3=n
> vers4=y
> vers4.0=y
> vers4.1=y
> vers4.2=y
>
> And nothing else. And yes, the port is intended to be "obscure".
On 20/09/2020 20:32, J. Bruce Fields wrote:
> On Sun, Sep 20, 2020 at 10:56:28AM +0100, Chris Hall wrote:
...
>> Where nfsdcld, rpc.idmapd and rpc.mountd have indeed been started
>> but are not bound to any ports.
> That looks good. (And rpc.mountd does still serve a purpose in the
> NFSv4 case, answering requests from the kernel for information related
> to exported filesystems.)
>> But rpc.statd and rpcbind have also been started, and various ports
>> have been opened, including port 111 which is bound to systemd. Is
>> there a way to inhibit that for nfs4 only ?
> Unlike rpc.mountd, there's no reason for those to be running at all.
> You can mask thoe corresponding systemd units.
I tried masking all of: rpcbind.socket, rpcbind.service, statd.service
and statd-notify.service. systemctl start nfs-server.service
(eventually) gives, according to the logging:
nfs-mountd.service: start operation timed out. Terminating.
nfs-mountd.service: State 'stop-sigterm' timed out. Killing.
nfs-mountd.service: Killing process x (rpc.mountd) with signal SIGKILL.
nfs-mountd.service: Control process exited, code=killed, status=9/KILL
If I unmask rpcbind.service, I can start nfs-server. It no longer
starts rpc.statd. But I still have rpcbind running and port 111 open.
> It'd be nice if there was a way to make that happen automatically if v2
> and v3 are configured out in the configuration files, but I don't know
> how to make that happen.
It would and me neither.
Thanks,
Chris
On Mon, Sep 21, 2020 at 03:40:01PM +0100, Chris Hall wrote:
> On 20/09/2020 20:32, J. Bruce Fields wrote:
> >On Sun, Sep 20, 2020 at 10:56:28AM +0100, Chris Hall wrote:
> ...
> >>Where nfsdcld, rpc.idmapd and rpc.mountd have indeed been started
> >>but are not bound to any ports.
>
> >That looks good. (And rpc.mountd does still serve a purpose in the
> >NFSv4 case, answering requests from the kernel for information related
> >to exported filesystems.)
>
> >>But rpc.statd and rpcbind have also been started, and various ports
> >>have been opened, including port 111 which is bound to systemd. Is
> >>there a way to inhibit that for nfs4 only ?
>
> >Unlike rpc.mountd, there's no reason for those to be running at all.
> >You can mask thoe corresponding systemd units.
>
> I tried masking all of: rpcbind.socket, rpcbind.service,
> statd.service and statd-notify.service. systemctl start
> nfs-server.service (eventually) gives, according to the logging:
>
> nfs-mountd.service: start operation timed out. Terminating.
> nfs-mountd.service: State 'stop-sigterm' timed out. Killing.
> nfs-mountd.service: Killing process x (rpc.mountd) with signal SIGKILL.
> nfs-mountd.service: Control process exited, code=killed, status=9/KILL
Huh, that suggests rpc.mountd is trying to contact rpcbind, but if
you've got v2/v3 turned off in the configuration files, it shouldn't be
trying to register anything.
Looking at the code.... I wonder if the problem is the unregistration
added by 849b7072a049 "mountd: Clear mountd registrations at start up"?
> If I unmask rpcbind.service, I can start nfs-server. It no longer
> starts rpc.statd. But I still have rpcbind running and port 111
> open.
>
> >It'd be nice if there was a way to make that happen automatically if v2
> >and v3 are configured out in the configuration files, but I don't know
> >how to make that happen.
>
> It would and me neither.
I suppose they could check the configuration and exit on startup if they
see they're not needed. Will systemd notice they died and try to
restart them or something?
--b.