Bug 1049032 - mount.nfs: an incorrect mount option was specified
Summary: mount.nfs: an incorrect mount option was specified
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: nfs-utils
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-06 20:11 UTC by Tom Horsley
Modified: 2015-02-17 19:51 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-17 19:51:14 UTC
Type: Bug


Attachments (Terms of Use)

Description Tom Horsley 2014-01-06 20:11:38 UTC
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):
nfs-utils-1.2.8-6.0.fc19.x86_64

How reproducible:
every time

Steps to Reproduce:
1.try to mount filesystem from antique server
2.get error
3.

Actual results:
no mount

Expected results:
mount

Additional info:

Comment 1 Tom Horsley 2014-01-06 23:26:26 UTC
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.

Comment 2 J. Bruce Fields 2014-01-07 15:09:42 UTC
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.

Comment 3 Tom Horsley 2014-01-07 15:52:03 UTC
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

Comment 4 J. Bruce Fields 2014-01-07 16:30:47 UTC
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"?

Comment 5 Tom Horsley 2014-01-07 17:15:25 UTC
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

Comment 6 J. Bruce Fields 2014-01-08 17:05:05 UTC
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@vger.kernel.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.

Comment 7 Tom Horsley 2014-01-09 01:14:37 UTC
Here's the mail archive entry for the mail I sent:

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

Comment 8 Fedora End Of Life 2015-01-09 21:04:48 UTC
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.

Comment 9 Fedora End Of Life 2015-02-17 19:51:14 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.