This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 206705 - mount.nfs returns success after a failed mount
mount.nfs returns success after a failed mount
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: nfs-utils (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Dickson
Ben Levenson
bzcl34nup
:
: 206208 216153 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-15 15:53 EDT by Jeffrey Moyer
Modified: 2008-05-07 10:08 EDT (History)
4 users (show)

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


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

  None (edit)
Description Jeffrey Moyer 2006-09-15 15:53:19 EDT
+++ 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 Jeffrey Moyer 2006-09-15 15:53:19 EDT
Created attachment 136386 [details]
return errors from failed mounts
Comment 2 Steve Dickson 2006-09-18 09:22:15 EDT
The patch in Comment #1 looks resonable... Feel free to apply it... 
Comment 3 Jeffrey Moyer 2006-09-25 17:48:49 EDT
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-26 20:38:53 EDT
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 15:41:02 EDT
*** Bug 206208 has been marked as a duplicate of this bug. ***
Comment 8 Karel Zak 2006-11-21 08:22:42 EST
*** Bug 216153 has been marked as a duplicate of this bug. ***
Comment 11 Bug Zapper 2008-04-03 14:13:43 EDT
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 20:50:56 EDT
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 Jeffrey Moyer 2008-05-07 10:08:28 EDT
This bug was actually fixed.

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