Description of problem:
My NFS entries in /etc/fstab have been working forever, but now I'm getting the marvelously useful error "an incorrect mount option was specified".
Going through the options 1 at a time and trying to manually mount shows that it apparently hates the "proto=udp" option now, but that is absolutely the only way I can mount filesystems from old machines that don't have a clue about stream connections. How the heck do I talk to old servers now?
If I leave off proto=udp, it says "backgrounding mount" then never actually mounts the filesystem.
Here's one example line that fails:
dino:/ada/denmark /ada/denmark nfs proto=udp,rw,bg,soft,intr,rsize=8192,wsize=8192 0 0
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.try to mount filesystem from antique server
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 firstname.lastname@example.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:
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
Thank you for reporting this bug and we are sorry it could not be fixed.