+++ This bug was initially created as a clone of Bug #465979 +++

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 -s bz249909 -n 1
  
Actual results:
log messages above

Expected results:
proper return codes returned so that autofs doesn't retry with -f.

--- Additional comment from jlayton on 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...

--- Additional comment from jmoyer on 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?

--- Additional comment from jlayton on 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...

--- Additional comment from jlayton on 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.

--- Additional comment from jlayton on 2008-10-08 11:54:06 EDT ---

Created an attachment (id=319761)
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...

--- Additional comment from jlayton on 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