Red Hat Bugzilla – Bug 465979
mount.cifs exits with incorrect error code
Last modified: 2009-09-02 07:54:52 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
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 firstname.lastname@example.org -s bz249909 -n 1
log messages above
proper return codes returned so that autofs doesn't retry with -f.
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...
> 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?
> 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
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...
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:
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.
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...
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
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
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.