Bug 123416 - nfs mounts by default using v3
Summary: nfs mounts by default using v3
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: nfs-utils
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Steve Dickson
QA Contact:
URL:
Whiteboard: bzcl34nup
Depends On:
Blocks: FC5Blocker
TreeView+ depends on / blocked
 
Reported: 2004-05-18 11:15 UTC by Olivier Crête
Modified: 2008-05-06 23:59 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-05-06 23:59:04 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Olivier Crête 2004-05-18 11:15:44 UTC
the nfs mount in core2 uses nfs v3 by default.. This breaks mounting
with older version and with systems running other distributions that
only support v2... Ahh and also, the nfs(5) man page says that v2 is
the default.. while this is clearly not the case on core2.

Comment 1 Alan Cox 2004-05-22 00:11:57 UTC
The man page needs fixing. Mounting nfsv3 by default makes a lot of
sense as v2 cannot handle large files.


Comment 2 Olivier Crête 2004-05-22 10:24:42 UTC
might be nice if the mounting still worked if the server doesnt handle
v3 (like most current linux distributions....)

Comment 3 Elliot Lee 2004-05-26 22:46:27 UTC
(It seems like it defaults to whatever the running kernel will support
-  could be 2, 3, or 4.)

Patch added to CVS for the next util-linux package.

Comment 4 Huw Lynes 2004-07-15 15:53:21 UTC
Any chance of a new util-linux SRPM in development now that FC3-test1
has shipped?

Thanks,
Huw

Comment 5 Steve Dickson 2004-08-31 12:06:03 UTC
The nfs mount command is broken. Starting up a RH server
with the --no-nfs-version 3 mountd argument causes the mount
command to fail instead of "dialing down" to version 2 as it
should.

It turns out there are two problems. Although mountd is not
accepting v3 requests, the kernel is still advertising a v3 service
(because it still registers the v3 service with the portmapper).
So the mount cmd will rpc ping the v3 server which will work, but
fail with it tries to get a v3 filehandle from mountd (which causes
the entire mount to fail). So the mount command should handle this
type of failure and the server should not be advertising v3 service
when its mound is not.

Comment 6 Matthew Miller 2005-04-26 15:02:51 UTC
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

Comment 7 Warren Togami 2006-03-08 20:57:07 UTC
Status update from steved?


Comment 8 David Lawrence 2006-04-18 20:07:33 UTC
NEEDINFO_ENG has been deprecated in favor of NEEDINFO or ASSIGNED. Changing
status to ASSIGNED for ENG review.

Comment 9 Matthew Miller 2006-06-30 02:50:40 UTC
Uh, this seems like it's still an active issue as of at least March 2006. Moving
release to "devel" so someone can sort out if it's been resolved. (I think not,
the man page in util-linux-2.13-0.28 from rawhide right now still specifies v2
as the default.)

Comment 10 Steve Dickson 2006-07-18 18:26:25 UTC
This should be fixed in the latest version of util-linux

Comment 11 Bug Zapper 2008-04-03 15:35:00 UTC
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 12 Bug Zapper 2008-05-06 23:59:02 UTC
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp


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