Bug 505018 - nfs mounts no longer negotiate protocol with older servers
Summary: nfs mounts no longer negotiate protocol with older servers
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: nfs-utils
Version: 11
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 505773 (view as bug list)
Depends On:
Blocks: 516998
TreeView+ depends on / blocked
 
Reported: 2009-06-10 11:54 UTC by Tom Horsley
Modified: 2010-06-28 12:51 UTC (History)
9 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2010-06-28 12:51:46 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Tom Horsley 2009-06-10 11:54:08 UTC
Description of problem:

I've been using lines much like this for years and years to mount remote
filesystems from various older systems with older NFS servers:

dino:/tt/carbon /tt/carbon nfs rw,bg,soft,intr,rsize=8192,wsize=8192 0 0

This has always worked up to and including fedora 10, but with fedora 11,
I get a mount error saying an illegal option was specified. That error
is apparently a wild goose chase, but after much poking around, I found
that if I add an additional option "proto=udp" to the options list, the
mount seems to work fine. So it seems like the ability to negotiate with
the server for what protocol to support has disappeared in the fedora 11
nfs mount process.

The specific error looks like:

mount.nfs: an incorrect mount option was specified

Version-Release number of selected component (if applicable):
nfs-utils-1.1.5-6.fc11.i586
system-config-nfs-docs-1.0.6-1.fc11.noarch
system-config-nfs-1.3.44-1.fc11.noarch
nfs-utils-lib-1.1.4-6.fc11.i586


How reproducible:
every time

Steps to Reproduce:
1.see above
2.
3.
  
Actual results:
mount.nfs: an incorrect mount option was specified


Expected results:
figure out the server only talks udp and mount that way.

Additional info:

Comment 1 Steve Dickson 2009-06-10 12:12:52 UTC
Just curious as to why your server only take UDP mounts, since
TCP is a much better protocol to use.

Comment 2 Tom Horsley 2009-06-10 12:28:48 UTC
Because it is a really really old system running an NFS from before NFS
ever heard of TCP. (Personally I can't imagine what was running through
the brains of the original NFS developers when they picked UDP as the
original protocol to use, but that's a different question :-). We need
to run these old systems to support software on them.

Comment 3 Fedora Update System 2009-06-10 13:34:04 UTC
nfs-utils-1.2.0-2.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/nfs-utils-1.2.0-2.fc11

Comment 4 Steve Dickson 2009-06-10 13:38:19 UTC
In my testing nfs-utils-1.2.0-2.fc11 seem to fix the problem.
Could you please install this updated nfs-utils package to
see if it resolve the problem.

Comment 5 Tom Horsley 2009-06-10 14:34:55 UTC
Actually, I'm now confused. I just installed fedora 11 on my desktop and
also installed all updates, and even though the nfs-utils version
still says it is 1.1.5-6, something else that came in with the updates
seems to have made it work. I don't have proto=udp, but I can mount
the older systems and the output from just typing "mount" shows that
it is indeed using udp protocol. (With 365MB of updates, I'm not sure
which bit might have had an effect :-).

I'll give 1.2.0-2 a whirl on one of the other systems I haven't updated
when I get a chance.

Comment 6 Tom Horsley 2009-06-10 15:19:59 UTC
More confused than ever: I tried nfs-utils-1.2.0-2.fc11.i586 on a system
where I haven't installed any updates, and I still get the incorrect
mount option message.

I noticed that the mount command itself was in an updated package, so
I also updated util-linux-ng to util-linux-ng-2.14.2-9.fc11.i586, but that
still doesn't work.

In case some server was involved that needed restarting, I rebooted the
system, and it still can't mount the filesystem.

Yet over on my desktop, will all available updates loaded, mounting
the same filesystem works fine without the proto=udp option. So some
existing update apparently fixes the problem, I just can't figure out
which one it is :-).

Comment 7 Steve Dickson 2009-06-10 15:42:11 UTC
Yes this is a bit bizarre.... 

So in the end, neither nfs-utils-1.2.0-2 or nfs-utils-1.1.5-6 
exhibit the problem after updating some unknown package, which
means the problem is solved??

Comment 8 Tom Horsley 2009-06-10 15:54:19 UTC
I guess so, I just don't have the patience to install the updates one at
a time to figure out which one did it :-).

Comment 9 Steve Dickson 2009-06-10 16:31:49 UTC
Now that totally understandable!!! :-) 

I'm going to close this as not a NOTBUG but please
feel free to reopen it if the problem comes back..

thanks for using Fedora 11!

Comment 10 Daniel Roesen 2009-06-13 18:35:58 UTC
*** Bug 505773 has been marked as a duplicate of this bug. ***

Comment 11 Daniel Roesen 2009-06-13 18:38:06 UTC
Same problem here, against RH9 NFS server. Pending update nfs-utils-1.2.0-3.fc11.i586.rpm does NOT fix the problem, the suggested workaround -o proto=udp works though, even with the current official version 1.1.5-6

Comment 12 Tom Horsley 2009-06-13 20:25:18 UTC
Just curious, did you do a "yum update" to get all the day zero updates
loaded on the fedora 11 system? That fixed it for me, though none of the
individual packages involved looked as though they were related, so I
have no idea which one triggered the fix. Maybe it is something silly
like some library routine doing the parsing of options that was broken
and a library update fixed it?

Comment 13 Daniel Roesen 2009-06-13 21:13:48 UTC
Yes, system has all the official released updates applied.

Comment 14 Fedora Update System 2009-06-16 01:22:34 UTC
nfs-utils-1.2.0-3.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update nfs-utils'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-5985

Comment 15 Hugh Caley 2009-07-02 19:37:59 UTC
nfs-utils-1.2.0-3.fc11 doesn't fix this for me.  I still have to specify proto=udp to mount from an older NFS server.

Comment 16 Bryan Che 2009-09-06 03:21:27 UTC
I have this same error mounting an older NFS server as well--I needed to specify proto=udp

Comment 17 Tom Horsley 2009-10-07 15:48:31 UTC
I just updated my desktop fedora 11 system at work where I first saw this
bug many moons ago, and it is back again, but this time the error I get
is:

mount.nfs: requested NFS version or transport protocol is not supported

The same work-around fixes it, explicitly giving the proto=udp option
on the mount command. Seems like if it can go to the trouble of printing
an error, it could also go to the trouble of trying udp :-).

Possibly relevant packages I just picked up when I updated today:

nfs-utils-1.2.0-5.fc11.x86_64
kernel-2.6.30.8-64.fc11.x86_64

Comment 18 Frank Cox 2009-10-07 17:03:29 UTC
I just discovered that I have the same problem here.  This computer is supposed
to mount two fileservers.  One of the fileservers runs Centos 5 and the other
is an Intel SS-4000E (a dedicated fileserver that runs its own embedded Linux).

The Centos 5 fileserver server mounted fine, just like it did before, but the Intel fileserver failed.

My fstab is set up as follows:

fileserver:/nas/NASDisk-00002/files/ /mnt/fileserver         nfs
defaults        0 0

After rebooting my computer last night when it finished updating to
nfs-utils-1.2.0-5.fc11.x86_64 the fileserver failed to mount.  I found out
about it this morning when my overnight backup to the fileserver failed to work.

Running the mount command from the commandline tells me this:

QUOTE:
[root@mutt frankcox]# mount fileserver:/nas/NASDisk-00002/files/ /mnt/fileserver

mount.nfs: requested NFS version or transport protocol is not supported
END OF QUOTE:

Using the suggested option "-o proto=udp", it mounted fine.

QUOTE:
[root@mutt frankcox]# mount -o proto=udp fileserver:/nas/NASDisk-00002/files/ /mnt/fileserver
END OF QUOTE

That worked and my Intel fileserver is now present on this computer again.

Comment 20 Bug Zapper 2010-04-27 14:43:46 UTC
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

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 prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 21 Bug Zapper 2010-06-28 12:51:46 UTC
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 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.

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.