Bug 465979 - mount.cifs exits with incorrect error code
mount.cifs exits with incorrect error code
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: samba (Show other bugs)
5.3
All Linux
medium Severity medium
: rc
: ---
Assigned To: Simo Sorce
BaseOS QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-07 11:27 EDT by Jeff Moyer
Modified: 2009-09-02 07:54 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-02 07:54:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch: fix mount.cifs return codes (3.07 KB, patch)
2008-10-08 11:54 EDT, Jeff Layton
no flags Details | Diff

  None (edit)
Description Jeff Moyer 2008-10-07 11:27:21 EDT
Description of problem:
mount(8) states that an exit code of 16 means that the mtab file could not be updated.  However, we get this error if mount.cifs is unable to perform a mount.  The following is a snippet of the autofs debug log.  There are autofs problems lurking in here, but let's focus on the cifs stuff:

mount_mount: mount(generic): calling mount -t cifs -s -o no-slashify-colons,user=autofs,password=autofs //dell-pe800-01.rhts.bos.redhat.com/3020/autofs /cifs/bar
>> retrying with upper case share name
>> mount error 6 = No such device or address
>> Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
spawn_mount: mount failed with error code 16, retrying with the -f option

So, the return code we got from the mount command above was 16.  So, we retry with -f so that we can update the mtab:

>> unknown mount option f
>> Usage:  /sbin/mount.cifs <remotetarget> <dir> -o <options>

This may be a util-linux problem, I'm not sure.  Is it not supposed to pass the -f option to the file system specific mount commands?

Version-Release number of selected component (if applicable):
samba-client  	 3.0.32  	 3.5.el5  	 x86_64 

How reproducible:
Not sure, but probably is reproducible.

Steps to Reproduce:
Run the automounter rhts tests:

autofs_workflow.py -a x86_64 -f RedHatEnterpriseLinuxServer5 -T INSTALLS -S rhts.redhat.com -u youremail@your.tld -s bz249909 -n 1
  
Actual results:
log messages above

Expected results:
proper return codes returned so that autofs doesn't retry with -f.
Comment 1 Jeff Layton 2008-10-08 08:50:00 EDT
I think that might be a problem with the generic mount command. It looks like when the kernel returns -ENXIO on a mount() call, the mount.cifs program returns -1. I assume that the generic mount program is converting that to a return code of 16 for some reason.

Unfortunately, there doesn't seem to be much info on how mount helpers are supposed to exit in error conditions, so it's possible we're doing something wrong in mount.cifs...
Comment 2 Jeff Moyer 2008-10-08 09:21:36 EDT
> I think that might be a problem with the generic mount command. It looks like
> when the kernel returns -ENXIO on a mount() call, the mount.cifs program
> returns -1. I assume that the generic mount program is converting that to a
> return code of 16 for some reason.

Looking at the code for mount, it seems that it just returns the exit status of the mount.cifs (in this case) command.  Are you sure mount.cifs is returning -1?

> Unfortunately, there doesn't seem to be much info on how mount helpers are
> supposed to exit in error conditions, so it's possible we're doing something
> wrong in mount.cifs...

From reading the source, it looks pretty clear.  Just return the exit code as documented in mount(8).  Right?
Comment 3 Jeff Layton 2008-10-08 10:27:42 EDT
> Looking at the code for mount, it seems that it just returns the exit status of
> the mount.cifs (in this case) command.  Are you sure mount.cifs is returning
> -1?

It certainly looks that way from when I reproduce mount() returning -ENXIO. I don't see /sbin/mount returning 16 in that situation, but instead returning 255. It says that the mount return is expected to be a bitfield though, so maybe it's not actually returning 16 and is just returning with the 16 bit set?

> From reading the source, it looks pretty clear.  Just return the exit code as
> documented in mount(8).  Right?

It looks that way in the code, but the results I'm seeing are strange...
Comment 4 Jeff Layton 2008-10-08 10:41:08 EDT
Ahh ok, I think I see what the deal is. check_special_mountprog() does this:

*status = (WIFEXITED(st) ? WEXITSTATUS(st) : EX_SYSERR);

...from wait(2) manpage:

       WEXITSTATUS(status)
              returns the exit status of the  child.   This  consists  of  the
              least  significant  8 bits of the status argument that the child
              specified in a call to exit(3) or _exit(2) or  as  the  argument
              for  a  return  statement  in main().  This macro should only be
              employed if WIFEXITED returned true.

...so the -1 is getting converted to 0xff, which == 255. The mount.cifs exit status is a bit of a mess. I'll see about patching it up to do the right thing.
Comment 5 Jeff Layton 2008-10-08 11:54:06 EDT
Created attachment 319761 [details]
patch: fix mount.cifs return codes

This seems to fix the reproducer, and should fix some other problems based on a cursory look over the code.

I'll go ahead and commit this to upstream samba git trees tomorrow unless anyone has objections...
Comment 6 Jeff Layton 2008-10-09 11:21:42 EDT
Slightly modified patch pushed to upstream git tree. I'll put this on the 5.4 proposed list and clone it and see if we can get it for 4.8
Comment 7 Jeff Layton 2008-10-09 11:27:01 EDT
Reassigning back to Simo. Let me know if you need me to backport the patch, but the one in v3-0-test ought to be OK for this.

RHEL4 bug is bug 466285
Comment 12 errata-xmlrpc 2009-09-02 07:54:52 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1416.html

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