Red Hat Bugzilla – Bug 1163957
Autofs unable to mount indirect after attempt to mount wildcard
Last modified: 2015-07-22 02:51:21 EDT
Description of problem: When an "ls *" is done of the root of an indirect mount, autofs will attempt to literally mount the key '*'. If this occurs before a valid mount key, autofs will fail on any further mount attempts inside the mountpoint, valid or not. Version-Release number of selected component (if applicable): automount version 5.0.5-109.el6 RHEL 6.6 How reproducible: easy Steps to Reproduce: 1. mkdir -p /auto_test/dir{1,2} 2. echo "/auto_test/mounts /etc/auto.test" > /etc/auto.master 3. echo "* -fstype=bind :/auto_test/&" > /etc/auto.test 4. /etc/init.d/autofs restart 5. ls -ld /auto_test/mounts/* 6. ls -ld /auto_test/mounts/dir{1,2} Actual results: # ls -ld /auto_test/mounts/* ls: cannot access /auto_test/mounts/*: No such file or directory # ls -ld /auto_test/mounts/dir{1,2} ls: cannot access /auto_test/mounts/dir1: No such file or directory ls: cannot access /auto_test/mounts/dir2: No such file or directory Expected results: # ls -ld /auto_test/mounts/* ls: cannot access /auto_test/mounts/*: No such file or directory # ls -ld /auto_test/mounts/dir{1,2} drwxr-xr-x 2 root root 4096 Nov 13 18:02 /auto_test/mounts/dir1 drwxr-xr-x 2 root root 4096 Nov 13 18:02 /auto_test/mounts/dir1 # ls -ld /auto_test/mounts/* drwxr-xr-x 2 root root 4096 Nov 13 18:02 /auto_test/mounts/dir1 drwxr-xr-x 2 root root 4096 Nov 13 18:02 /auto_test/mounts/dir2 Additional info: This problem only occurs when the wildcard ("*") is attempted before a successful automount occurs. Other invalid keys will give the expected "No such file or directory" error, but valid mounts will still succeed afterwards. Once a valid mount occurs, the wildcard failure will produce the error, but valid mounts will continue to work.
Yes, that's not good. I'll investigate and see what I can do about it. Ian
(In reply to Ian Kent from comment #2) > Yes, that's not good. > I'll investigate and see what I can do about it. Looks like the wildcard is being added as a negative cache entry which prevents any further wildcard lookup matching. I'll make a patched rpm for testing.
Created attachment 958895 [details] Patch - make negative cache update consistent for all lookup modules
Created attachment 958896 [details] Patch - ensure negative cache isn't updated on remount
Created attachment 958897 [details] Patch - dont add wildcard to negative cache
An autofs build with the above three patches is available at: http://people.redhat.com/~ikent/autofs-5.0.5-110.el6/ This should resolve the problem seen here. Please test in your environment.
I can confirm it works with the new package: # cd * -bash: cd: *: No such file or directory # cd test1 # pwd /home2/test1 Before the new package: # cd * -bash: cd: *: No such file or directory # cd test1 -bash: cd: test1: No such file or directory
Reproduced on RHEL-6.6-20140926.0, with autofs with autofs-5.0.5-112, results like following: :: [ BEGIN ] :: Running 'ls -ld /automount/*' ls: cannot access /automount/*: No such file or directory :: [ PASS ] :: Command 'ls -ld /automount/*' (Expected 2, got 2) :: [ BEGIN ] :: Running 'ls -ld /automount/dir{1,2}' ls: cannot access /automount/dir1: No such file or directory ls: cannot access /automount/dir2: No such file or directory :: [ FAIL ] :: Command 'ls -ld /automount/dir{1,2}' (Expected 0, got 2) Verified on RHEL-6.7-20150304.0, with autofs-5.0.5-112, covers i386, x86_64, s390x, ppc64, results like following: [04:53:42 root@ ~~]# ls -ld /automount/* ls: cannot access /automount/*: No such file or directory :: [ PASS ] :: Running 'ls -ld /automount/*' (Expected 2, got 2) -------------------------------------------------------------------------------- [04:53:42 root@ ~~]# ls -ld /automount/dir{1,2} drwxr-xr-x. 2 root root 4096 Mar 12 04:53 /automount/dir1 drwxr-xr-x. 2 root root 4096 Mar 12 04:53 /automount/dir2 :: [ PASS ] :: Running 'ls -ld /automount/dir{1,2}' (Expected 0, got 0) Also run regression/bugzillas/stress tests for autofs-5.0.5-112, works fine. So I change this bug status to be VERIFIED.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-1344.html