Bug 1049032

I have discovered that using nfsvers=3 does work, but I am also absolutely positive that the reason I was using proto=udp instead of nfsvers=3 is because when nfs-utils first changed to require extra args to talk to old servers that I tried nfsvers=3 at that time and it wouldn't work, only proto=udp worked.

I also never figured out why it changed to require extra args since the servers do indeed identify themselves and it used to be able to mount without nfsvers or proto options being given.

What does "rpcinfo <your-server-here>" say?

It might also be useful to fire up wireshark and watch the client<->server traffic during the mount in each of these cases.

I certainly have no idea what this listing says, but here is rpcinfo for the "dino" server in the example above:

   program version netid     address                service    owner
    100000    4    tcp6      ::.0.111               portmapper superuser
    100000    3    tcp6      ::.0.111               portmapper superuser
    100000    4    udp6      ::.0.111               portmapper superuser
    100000    3    udp6      ::.0.111               portmapper superuser
    100000    4    tcp       0.0.0.0.0.111          portmapper superuser
    100000    3    tcp       0.0.0.0.0.111          portmapper superuser
    100000    2    tcp       0.0.0.0.0.111          portmapper superuser
    100000    4    udp       0.0.0.0.0.111          portmapper superuser
    100000    3    udp       0.0.0.0.0.111          portmapper superuser
    100000    2    udp       0.0.0.0.0.111          portmapper superuser
    100000    4    local     /var/run/rpcbind.sockÿ! portmapper superuser
    100000    3    local     /var/run/rpcbind.sockÿ! portmapper superuser
    100024    1    tcp       0.0.0.0.131.65         status     29
    100024    1    udp       0.0.0.0.156.67         status     29
    100024    1    udp6      ::.172.159             status     29
    100024    1    tcp6      ::.168.192             status     29
    100021    1    udp       0.0.0.0.144.103        nlockmgr   superuser
    100021    3    udp       0.0.0.0.144.103        nlockmgr   superuser
    100021    4    udp       0.0.0.0.144.103        nlockmgr   superuser
    100021    1    tcp       0.0.0.0.159.24         nlockmgr   superuser
    100021    3    tcp       0.0.0.0.159.24         nlockmgr   superuser
    100021    4    tcp       0.0.0.0.159.24         nlockmgr   superuser
    100021    1    udp6      ::.149.95              nlockmgr   superuser
    100021    3    udp6      ::.149.95              nlockmgr   superuser
    100021    4    udp6      ::.149.95              nlockmgr   superuser
    100021    1    tcp6      ::.222.84              nlockmgr   superuser
    100021    3    tcp6      ::.222.84              nlockmgr   superuser
    100021    4    tcp6      ::.222.84              nlockmgr   superuser
    100007    2    udp       0.0.0.0.3.213          ypbind     superuser
    100007    1    udp       0.0.0.0.3.213          ypbind     superuser
    100007    2    tcp       0.0.0.0.3.216          ypbind     superuser
    100007    1    tcp       0.0.0.0.3.216          ypbind     superuser

Strange--that rpcinfo output looks more like what I'd expect from an nfs client.

The server should also show entries for the nfs and mountd services.  Are you positive the nfs service was actually running on dino at the time you ran "rpcinfo dino"?

Yep, I've got a filesystem mounted from dino, so it must be serving it. I'm sure dino is also acting as a client for things it mounts as well. It is extremely antique though. /etc/redhat-release says:

Red Hat Linux release 8.0 (Psyche)

If I do a ps, I see these running:

  767 ?        SW   145:27 [nfsd]
  768 ?        SW   142:55 [nfsd]
  769 ?        SW   143:11 [nfsd]
  770 ?        SW   144:07 [nfsd]
  771 ?        SW   143:23 [nfsd]
  772 ?        SW   146:20 [nfsd]
  773 ?        SW   143:14 [nfsd]
  774 ?        SW   148:46 [nfsd]
  780 ?        S      4:07 rpc.mountd

Well, that's strange server behavior.  But I guess that's a side issue, the "incorrect mount option" error is reproduceable against any server.  The problem is that mount is now defaulting to attempting NFS version 4 first--and NFSv4 supports only TCP.

I'm not sure what the correct behavior is: it's certainly unhelpful for a previously-working mount line to stop working on upgrade.  The version-negotiation logic is supposed to prevent that by allowing mount to automatically fall back to lower NFS versions on failure.  But the mount command is (understandably) assuming that -EINVAL is a fatal error that wouldn't be fixed by downgrading the NFS version.

This is a problem upstream as well--could you possibly summarize the situation in a mail to linux-nfs.org and see what the other upstream developers have to say?

For now using nfsvers=3 as you're doing now is probably the correct thing to do.  We don't generally recommend using udp if it can be avoided.

Here's the mail archive entry for the mail I sent:

http://www.spinics.net/lists/linux-nfs/msg41209.html

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.