Bug 206705 - mount.nfs returns success after a failed mount
Summary: mount.nfs returns success after a failed mount
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: nfs-utils (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Ben Levenson
URL:
Whiteboard: bzcl34nup
Keywords:
: 206208 216153 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-09-15 19:53 UTC by Jeff Moyer
Modified: 2008-05-07 14:08 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-07 00:50:59 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
return errors from failed mounts (973 bytes, patch)
2006-09-15 19:53 UTC, Jeff Moyer
no flags Details | Diff

Description Jeff Moyer 2006-09-15 19:53:19 UTC
+++ This bug was initially created as a clone of Bug #206704 +++

Description of problem:
# mount -t nfs
sol10-nfs.rhts.boston.redhat.com:/export/cthon_automount/export1/a
/root/foo/autofs/autofs-tests/connectathon/mnt/iparse/a
mount: sol10-nfs.rhts.boston.redhat.com:/export/cthon_automount/export1/a
failed, reason given by server: No such file or directory
# echo $?
0

This causes problems for autofs, which will then allow access to the "mounted"
directory.

Version-Release number of selected component (if applicable):
I first tried with the version shipped in RHEL 5 Alpha 1, then upgraded to
rawhide.  The problem exists both places.

# rpm -q nfs-utils
nfs-utils-1.0.9-3.fc6


How reproducible:
100%

I've attached a patch, but I haven't been able to test it due to build
dependency problems.  Please take a look and let me know what you think.

Thanks.

-- Additional comment from jmoyer@redhat.com on 2006-09-15 15:51 EST --
Created an attachment (id=136384)
return mount errors

Comment 1 Jeff Moyer 2006-09-15 19:53:19 UTC
Created attachment 136386 [details]
return errors from failed mounts

Comment 2 Steve Dickson 2006-09-18 13:22:15 UTC
The patch in Comment #1 looks resonable... Feel free to apply it... 

Comment 3 Jeff Moyer 2006-09-25 21:48:49 UTC
OK, I walked through the error paths in mount and mount.nfs (and let me tell
you, it's hairy).  I'm not sure that returning -1 from mount.nfs is a good idea,
as that error can be used as the return code from the mount process.  Take a
look at do_mount_all, for example.  It does this:

	for (mc = cp->mec; mc; mc = mc->nxt) {
		status |= mount_one (mc->m.mnt_fsname,
				     mc->m.mnt_dir,
				     mc->m.mnt_type,
				     mc->m.mnt_opts,
				     options, 0, 0);
	}

Thus, if mount.nfs returns -1, that status can be propagated to this function,
which then essentially sets status to -1.  Since -1 is not a documented return
code for mount, I think it should be avoided.  This is especially true since the
return code is a bitmask, so a program checking for errors would find all error
flags set.

I think it's harmless, but it could lead to user confusion.  If I'm reading the
code improperly, please let me know.  Steve, could you please take a look at
this and let me know what the correct behaviour is?

Comment 4 Steve Dickson 2006-09-27 00:38:53 UTC
Looking at the mount man pages the expect return code is
is basically a int 32 value (or EX_FAIL). So as long as mount.nfs
and mount.nfs4 exit with that value on failed mounts, we
continue to be consistent with the man page...

The above patch was added to  nfs-utils-1.0.9-8



Comment 5 Karel Zak 2006-09-27 19:41:02 UTC
*** Bug 206208 has been marked as a duplicate of this bug. ***

Comment 8 Karel Zak 2006-11-21 13:22:42 UTC
*** Bug 216153 has been marked as a duplicate of this bug. ***

Comment 11 Bug Zapper 2008-04-03 18:13:43 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-07 00:50:56 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

Comment 13 Jeff Moyer 2008-05-07 14:08:28 UTC
This bug was actually fixed.


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