mount.nfs4 and logging

mount.nfs4 and logging

[Chris Hall]

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

Re: mount.nfs4 and logging

[Steve Dickson]

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.

Re: mount.nfs4 and logging

[Chris Hall]

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

Re: mount.nfs4 and logging

[Kenneth Dsouza]

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 <kdsouza@redhat.com>
---
 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 <linux-nfs@gmch.uk> 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
>

Re: mount.nfs4 and logging

[Kenneth Dsouza]

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 <kdsouza@redhat.com>
---
 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 <linux-nfs@gmch.uk> 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
>

Re: mount.nfs4 and logging

[Kenneth Dsouza]

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 <kdsouza@redhat.com>
---
 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 <linux-nfs@gmch.uk> 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
>

Re: mount.nfs4 and logging

[J. Bruce Fields]

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.

Re: mount.nfs4 and logging

[J. Bruce Fields]

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.

Re: mount.nfs4 and logging

[J. Bruce Fields]

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".

Re: mount.nfs4 and logging

[Chris Hall]

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

Re: mount.nfs4 and logging

[J. Bruce Fields]

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.