nfs mounts no longer negotiate protocol with older servers

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:

Just curious as to why your server only take UDP mounts, since
TCP is a much better protocol to use.

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.

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

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.

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.

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 :-).

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??

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 :-).

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!

*** Bug 505773 has been marked as a duplicate of this bug. ***

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

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?

Yes, system has all the official released updates applied.

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

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.

I have this same error mounting an older NFS server as well--I needed to specify proto=udp

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

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.

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

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.