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.
I've tested with my current version and it seems to work OK. I'll let you know after I apply the patch.
I just upgraded to autofs-5.0.1-0.rc1.6 and it's still broken. Jeff
(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.
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
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?
(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.
(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?
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?
(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.
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.
(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.
(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?
(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...
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?
(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.
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?
(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
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?
I just opened a BZ on util-linux and the sloppy option being ignored: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=206208
(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
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
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.
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.
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
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!