Red Hat Bugzilla – Bug 206705
mount.nfs returns success after a failed mount
Last modified: 2008-05-07 10:08:28 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
Created attachment 136386 [details] return errors from failed mounts
The patch in Comment #1 looks resonable... Feel free to apply it...
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?
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
*** Bug 206208 has been marked as a duplicate of this bug. ***
*** Bug 216153 has been marked as a duplicate of this bug. ***
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.
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
This bug was actually fixed.