Bug 505018

Summary: nfs mounts no longer negotiate protocol with older servers
Product: [Fedora] Fedora Reporter: Tom Horsley <horsley1953>
Component: nfs-utilsAssignee: Steve Dickson <steved>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 11CC: bche, chuck.lever, dkovalsk, dr, hughc, jlayton, rwheeler, steved, theatre
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-06-28 08:51:46 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 516998    

Description Tom Horsley 2009-06-10 07:54:08 EDT
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):

How reproducible:
every time

Steps to Reproduce:
1.see above
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 08:12:52 EDT
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 08:28:48 EDT
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 09:34:04 EDT
nfs-utils-1.2.0-2.fc11 has been submitted as an update for Fedora 11.
Comment 4 Steve Dickson 2009-06-10 09:38:19 EDT
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 10:34:55 EDT
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 11:19:59 EDT
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 11:42:11 EDT
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 11:54:19 EDT
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 12:31:49 EDT
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 14:35:58 EDT
*** Bug 505773 has been marked as a duplicate of this bug. ***
Comment 11 Daniel Roesen 2009-06-13 14:38:06 EDT
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 16:25:18 EDT
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 17:13:48 EDT
Yes, system has all the official released updates applied.
Comment 14 Fedora Update System 2009-06-15 21:22:34 EDT
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 15:37:59 EDT
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-05 23:21:27 EDT
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 11:48:31 EDT
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

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:

Comment 18 Frank Cox 2009-10-07 13:03:29 EDT
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:

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

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

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

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

That worked and my Intel fileserver is now present on this computer again.
Comment 20 Bug Zapper 2010-04-27 10:43:46 EDT
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: 
Comment 21 Bug Zapper 2010-06-28 08:51:46 EDT
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.