Bug 206705

Summary: mount.nfs returns success after a failed mount
Product: [Fedora] Fedora Reporter: Jeff Moyer <jmoyer>
Component: nfs-utilsAssignee: Steve Dickson <steved>
Status: CLOSED RAWHIDE QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: jmbastia, kzak, tao, triage
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: bzcl34nup
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: ---
Description Flags
return errors from failed mounts none

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
mount: sol10-nfs.rhts.boston.redhat.com:/export/cthon_automount/export1/a
failed, reason given by server: No such file or directory
# echo $?

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

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

How reproducible:

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.


-- 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,
				     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:

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:

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