Bug 199777 - autofs-5.x breaks on automount entries with unsupported mount options
autofs-5.x breaks on automount entries with unsupported mount options
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ian Kent
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-21 17:36 EDT by Jeff Bastian
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-05 15:21:21 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 to ignore autofs specific mount options (3.38 KB, patch)
2006-09-14 02:22 EDT, Ian Kent
no flags Details | Diff

  None (edit)
Description Jeff Bastian 2006-07-21 17:36:57 EDT
Description of problem:
I recently upgraded to autofs-5.0.1-0.rc1.5 on my FC6 Test 1 system and I can no
longer mount directories that have mount options listed in the automount maps. 
I.E., if auto_mnt contains an entry like
   foo server:/path/to/foo
I can get to /mnt/foo just fine, but if the same map contains
   bar -ro server:/path/to/bar
then I get an error
   ls: /mnt/bar: No such file or directory

Version-Release number of selected component (if applicable):
autofs-5.0.1-0.rc1.5

How reproducible:
Every time

Steps to Reproduce:
1. Upgrade to autofs-5.0.1-0.rc1.5
2. Try to 'ls' an automounted directory with special mount options in the map
  
Actual results:
It fails with "no such file or directory"

Expected results:
It should mount the directory and show me the files

Additional info:
I've tested on both a NIS and LDAP client and it fails the same way on both.
SELinux policies were upgraded to selinux-policy-2.3.3-6 and set back to
enforcing, but the same error happens if I disable SELinux.
Comment 1 Ian Kent 2006-07-24 08:09:13 EDT
I've tested with my current version and it seems to work
OK.

I'll let you know after I apply the patch.
Comment 2 Jeff Bastian 2006-07-26 15:30:15 EDT
I just upgraded to autofs-5.0.1-0.rc1.6 and it's still broken.

Jeff
Comment 3 Ian Kent 2006-07-27 04:35:34 EDT
(In reply to comment #2)
> I just upgraded to autofs-5.0.1-0.rc1.6 and it's still broken.

Get me a debug log please.
This works fine for me so lets see what's going on.
Comment 4 Jeff Bastian 2006-07-27 09:08:05 EDT
Ahh, I should have looked at the debug logs earlier.  It's complaining that some
of the mount options in our maps are unsupported; it looks like the options are
specific to Solaris.

Jul 27 08:00:28 millipede automount[29729]: >> Unsupported nfs mount option: r
Jul 27 08:01:20 millipede automount[29840]: >> Unsupported nfs mount option:
nobrowse

Some of our automount map entries have -r in the mount options which is a valid
Solaris option for mounting read-only, but it looks like autofs has previously
just silently ignored it (and mounted it rw!).  Any chance of having autofs
convert '-r' to '-ro'?

The nobrowse option is for the Solaris automounter to disable browsing (or
ghosting) of indirect automount maps.  I believe it's only supposed to be in the
auto.master map, but it looks like it's been copied-and-pasted into individual
mount entries that want to override the mount options that get inherited from
auto.master.  It looks like we need to do some map cleanup on our end for this
option.

Jeff
Comment 5 Jeff Bastian 2006-07-27 11:06:28 EDT
I've audited all of our automount maps and in addition to the 'r' and 'nobrowse'
options, I've found one more option that autofs-5.0.1-0.rc1.6 doesn't like: grpid.

On Solaris, grpid is a valid mount option for NFS mounts.  It gives similar
behavior to the setgid bit on directories.  From the Solaris mount_nfs(1M) man page:
           grpid By default, the  GID  associated  with  a  newly
                 created  file  will obey the System V semantics;
                 that is, the GID is set to the effective GID  of
                 the   calling  process.  This  behavior  may  be
                 overridden on a per-directory basis  by  setting
                 the set-GID bit of the parent directory; in this
                 case, the GID of a newly created file is set  to
                 the GID of the parent directory (see open(2) and
                 mkdir(2)). Files created on  file  systems  that
                 are  mounted with the grpid option will obey BSD
                 semantics independent of whether the set-GID bit
                 of the parent directory is set; that is, the GID
                 is unconditionally inherited from  that  of  the
                 parent directory.

Can you have autofs-5.x also accept 'grpid' as a valid option?

Or, maybe have a flag that tells autofs to not check for and enforce valid mount
options?
Comment 6 Ian Kent 2006-07-27 11:15:10 EDT
(In reply to comment #4)
> Some of our automount map entries have -r in the mount options which is a valid
> Solaris option for mounting read-only, but it looks like autofs has previously
> just silently ignored it (and mounted it rw!).  Any chance of having autofs
> convert '-r' to '-ro'?

That should be fairly straight forward.

> 
> The nobrowse option is for the Solaris automounter to disable browsing (or
> ghosting) of indirect automount maps.  I believe it's only supposed to be in the
> auto.master map, but it looks like it's been copied-and-pasted into individual
> mount entries that want to override the mount options that get inherited from
> auto.master.  It looks like we need to do some map cleanup on our end for this
> option.

Ah yes. I thought that was a master map only option.
Comment 7 Ian Kent 2006-07-27 11:17:34 EDT
(In reply to comment #5)
> I've audited all of our automount maps and in addition to the 'r' and 'nobrowse'
> options, I've found one more option that autofs-5.0.1-0.rc1.6 doesn't like: grpid.
> 
> On Solaris, grpid is a valid mount option for NFS mounts.  It gives similar
> behavior to the setgid bit on directories.  From the Solaris mount_nfs(1M) man
page:
>            grpid By default, the  GID  associated  with  a  newly
>                  created  file  will obey the System V semantics;
>                  that is, the GID is set to the effective GID  of
>                  the   calling  process.  This  behavior  may  be
>                  overridden on a per-directory basis  by  setting
>                  the set-GID bit of the parent directory; in this
>                  case, the GID of a newly created file is set  to
>                  the GID of the parent directory (see open(2) and
>                  mkdir(2)). Files created on  file  systems  that
>                  are  mounted with the grpid option will obey BSD
>                  semantics independent of whether the set-GID bit
>                  of the parent directory is set; that is, the GID
>                  is unconditionally inherited from  that  of  the
>                  parent directory.
> 
> Can you have autofs-5.x also accept 'grpid' as a valid option?

I've removed the "-s" sloppy option so that autofs will get fails
back for bad mounts. A more correct implementation.

So I'll have a look at this also.
> 
> Or, maybe have a flag that tells autofs to not check for and enforce valid mount
> options?

Comment 8 Jeffrey Moyer 2006-07-27 11:20:36 EDT
Ian, I think it's a bad idea to get rid of the sloppy option.  Can you please
give some justification for it?  Honestly, do you really want to map between
*every* other UNIX's mount options and ours?
Comment 9 Ian Kent 2006-07-27 11:26:28 EDT
(In reply to comment #8)
> Ian, I think it's a bad idea to get rid of the sloppy option.  Can you please
> give some justification for it?  Honestly, do you really want to map between
> *every* other UNIX's mount options and ours?

Not really but then a raft of tests in the Connectathon will fail
to fail such as bad protocol and version options.

I think it's a good idea to fail when important options are wrong,
so perhaps I could put something in to check for them and their
variations instead.
Comment 10 Jeffrey Moyer 2006-07-27 11:30:22 EDT
Hmm, sticky problem.  My main concern is that people are going to run into
problems moving to v5.  I'll defer to your judgement on this one, as no solution
seems particularly compelling.
Comment 11 Ian Kent 2006-07-27 12:55:46 EDT
(In reply to comment #10)
> Hmm, sticky problem.  My main concern is that people are going to run into
> problems moving to v5.  I'll defer to your judgement on this one, as no solution
> seems particularly compelling.

I'll put it back and make a temporary define or something for
the testing.
Comment 12 Jeff Bastian 2006-07-27 13:30:53 EDT
(In reply to comment #7)
> I've removed the "-s" sloppy option so that autofs will get fails
> back for bad mounts. A more correct implementation.

You've removed the sloppy option from autofs?  The mount command in FC6 Test 1
still has the -s option (at least the man page claims it does).  Is that going
to be removed from the mount command?
Comment 13 Jeff Bastian 2006-07-27 13:36:22 EDT
(In reply to comment #10)
> Hmm, sticky problem.  My main concern is that people are going to run into
> problems moving to v5.  I'll defer to your judgement on this one, as no solution
> seems particularly compelling.

Agreed.  You don't really want to build hooks into autofs for every flavor of
*nix and the various mount options (like grpid on Solaris) that Linux doesn't
support, but without a sloppy mount option, it makes it difficult to share
automount maps in a heterogenous environment.

What if instead of using a sloppy mount option, autofs strips the options that
don't apply on Linux and have it leave a warning in the logs?

In fact, this might be a useful feature because when I audited our maps this
morning, I found a couple of typos like 'rsize32768' instead of 'rsize=32768'. 
This typo was probably in that map for years but we never noticed it because
nothing complained and the end users could get to their data...
Comment 16 Jeff Bastian 2006-08-08 12:41:45 EDT
On the sloppy mount option, it looks like the '-s' flag isn't honored anymore by
the mount command.  I tried manually mounting the directory and it failed the
same way as the debug log showed:

# mount -t nfs -s \
     -o ro,intr,timeo=600,retrans=2,vers=3,proto=tcp,suid,nobrowse,retry=100 \
     nfssrv1:/vol/vol5/apps_10/free/x86_64/Linux/rhel_4.0 /mnt
Unsupported nfs mount option: nobrowse

I have util-linux-2.13-0.36 installed.  Maybe a BZ needs to be opened against
this package instead?
Comment 21 Ian Kent 2006-08-08 13:24:07 EDT
(In reply to comment #19)
> Created an attachment (id=133809) [edit]
> auto_apps
> 
> hostnames have been changed to protect the innocent  :)

Yep. Nothin unusual in these.
mount(8) bahh.

Maybe I'm not getting the right return code.
I'll check.
Comment 22 Jeff Bastian 2006-09-11 13:54:37 EDT
I updated my FC6 box this morning to the latest packages and I'm now running
   kernel-2.6.17-1.2630.fc6
   autofs-5.0.1-0.rc2.1

I still cannot get into directories with unsupported mount options, and I'm
still seeing LDAP queries for keys of 'free/sudo'.

Would you like the latest debug logs?

Comment 24 Ian Kent 2006-09-12 00:29:18 EDT
(In reply to comment #23)
> Created an attachment (id=136027) [edit]
> debug log for unsupported mount options (5.0.1-0.rc2.1)
> 
> Just in case, I'm attaching the debug logs.  :)
> 
> The log encompasses
>   service autofs start
>   df -h /apps/free/.
>   df -h /apps/free/sudo/.
>   service autofs stop
> 

I thought adding back the "-s" would resolve this.

I've had a brief look at the log.

Can you tell me if the mount, with the reported "unsupported mount
option" actually gets mounted. mount(8) reports that it has but if
it actually hasn't been mounted this could cause the exact issue
that your seeing. I tried the same invalid options but didn't see
this myself so I'm puzzled by it.

However I do it it's absolutely essential that I return accurate
mount status back to the kernel.

Ian

Comment 25 Jeff Bastian 2006-09-12 17:47:22 EDT
No, it's not getting mounted:

[root@millipede ~]# df -h /apps/free/.
Filesystem            Size  Used Avail Use% Mounted on
-                        0     0     0   -  /apps
[root@millipede ~]# grep free /etc/mtab
[root@millipede ~]# grep free /proc/mounts 
[root@millipede ~]#

This may actually be a problem (or two problems) with the mount command.  If I
run it by hand, the mount command returns 0 which indicates success. 
Furthermore, the -s option is being passed to mount, but it ignores it:

[root@millipede ~]# mount -t nfs -s -o
ro,intr,timeo=600,retrans=2,vers=3,proto=tcp,suid,nobrowse,retry=100
nfssrv2:/vol/vol5/apps_10/free/i686/Linux/rhel_4.0 /apps/free; echo $?
Unsupported nfs mount option: nobrowse
0

Should I open a new BZ on the util-linux package?  Or do you want to do that?
Comment 26 Jeff Bastian 2006-09-12 17:58:20 EDT
I just opened a BZ on util-linux and the sloppy option being ignored:
  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=206208
Comment 27 Ian Kent 2006-09-12 23:13:06 EDT
(In reply to comment #25)
> No, it's not getting mounted:
> 

Great, that clears that up.
Well see what feedback we get from the BZ on util-linux.

In the meantime I'm going to add stuff to ignore the autofs
specific options (browse/nobrowse) which seems the sensible
thing to do anyway. I would have done this already but I
had a buch of trouble updating my FC6 instance.

Ian
Comment 28 Ian Kent 2006-09-14 02:22:55 EDT
Created attachment 136237 [details]
Patch to ignore autofs specific mount options

This patch should at least resolve the problem you have
with the "nobrowse" option.

Ian
Comment 34 Jeff Bastian 2006-09-27 12:55:37 EDT
I upgraded to
   autofs-5.0.1-0.rc2.1
   nfs-utils-1.0.9-7.fc6
   util-linux-2.13-0.42
this morning and now the automounter is happily mounting directories with
unsupported mount options again.

I tried manually testing with and without the -s option and that appears to be
mostly working.  It still does not return an error, though, with unsupported
mount options and no -s flag:
   # mount -o ro,nobrowse server:/some/path /mnt; echo $?
   Unsupported nfs mount option: nobrowse
   0
The automounter is expecting $? to be non-zero to indicate an error.

I updated BZ 206208 (my duplicate) because BZ wouldn't let me update 205038.

Comment 35 Jeffrey Moyer 2006-09-27 12:58:21 EDT
Jeff, see bz #206704 and 206705 (same issue).  I filed those bugs and proposed a
patch to address the issue of mount not returning an error when it should.
Comment 36 Jeff Bastian 2006-10-05 15:00:08 EDT
Since the automounter is now stripping certain mount options that are known to
be autofs specific (e.g., nobrowse), and since you have other BZs open dealing
with mount not returning an error code, I think we can close this BZ now.

Thanks!
Jeff
Comment 37 Jeffrey Moyer 2006-10-05 15:21:21 EDT
Jeff, feel free to simply close the bugs.  We'll re-open them if we disagree.  =)

We're really happy that you've made such an effort to test and help us debug
through the betas.  Thanks for all of your help!

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