Description of problem: When attempting to mount a hierarchy, either using the format given in the autofs.5 manual page, or by explicitly listing each entry the autofs fails to mount subdirectories. Version-Release number of selected component (if applicable): autofs-5.0.1-0.rc2.43.0.2 How reproducible: Always. Steps to Reproduce: 1. echo /test/autofs >> /etc/auto.master 2. echo "a --bind :/test/a" > /etc/auto.test 3. echo "a/b --bind :/test/b" >> /etc/auto.test 4. mkdir -p /test/a /test/b 5. service autofs reload 6. ls -la /test/autofs/a/b At this point you will see that directory b does not exist. You can verify that a was correctly mounted, but not b with the command: ls -la /test/autofs Actual results: The automount should performs the equivalent of the following: mkdir -p /test/autofs/a mount --bind /test/a /test/autofs/a Expected results: The automount should perform the equivalent of the following: mkdir -p /test/autofs/a/b mount --bind /test/a /test/autofs/a mount --bind /test/b /test/autofs/a/b Additional info:
(In reply to comment #0) > Description of problem: > > When attempting to mount a hierarchy, either using the format given in the > autofs.5 manual page, or by explicitly listing each entry the autofs fails to > mount subdirectories. > > Version-Release number of selected component (if applicable): > > autofs-5.0.1-0.rc2.43.0.2 > > How reproducible: > > Always. > > Steps to Reproduce: > 1. echo /test/autofs >> /etc/auto.master This produces an invalid entry in auto.master. How does automount know where to get the information to perform the mounts? > 2. echo "a --bind :/test/a" > /etc/auto.test Don't use "--bind", autofs will do this for you. > 3. echo "a/b --bind :/test/b" >> /etc/auto.test This is an invalid entry also. An indirect map like this may have only a single directory component as the map key. > 4. mkdir -p /test/a /test/b > 5. service autofs reload > 6. ls -la /test/autofs/a/b > At this point you will see that directory b does not exist. And the automounter probably didn't start since your maps are invalid but you didn't provide any log output so we don't know for sure. > > You can verify that a was correctly mounted, but not b with the command: > ls -la /test/autofs > > Actual results: > > The automount should performs the equivalent of the following: > mkdir -p /test/autofs/a > mount --bind /test/a /test/autofs/a Why? This is not a format I've ever seen used for automounter maps in Linux, Solaris, IRIX or AIX. There are a couple of ways to do this. First, use an autofs indirect mount map with offsets in the map entry, usually often called a multi-mount map entry when talking about the Linux automounter. In /etc/auto.master /test /etc/auto.indirect.test In /etc/auto.indirect.test autofs /a :/test/a \ /a/b :/test/b Or this if you want directories in /test to still be visible (as /test will be over mounted). In /etc/auto.master /test/autofs /etc/auto.indirect.test In /etc/auto.indirect.test a / :/test/a \ /b :/test/b Note that you can't use a direct map for this because of the nesting of mount points, you need to use an indirect map with offsets because this is the way automounters handle nested maps. Further, if you wish to see the automount mount points in the directory then you can use the "browse" option like: /test /etc/auto.indirect.test browse Note that the options are last in master map entries whereas they are the second field in maps themselves. Ian
Sorry about the typo. That should have been: 1. echo "/test/autofs /etc/auto.test" >> /etc/auto.master I will try the way you suggest and see if it has the same problem.
Same problem... [root@docbill001 html]# grep -v '^#' /etc/auto.master /misc /etc/auto.misc /net -hosts /test/autofs /etc/auto.test +auto.master [root@docbill001 html]# grep -v '^#' /etc/auto.test a / :/test/a \ /b :/test/b [root@docbill001 html]# service autofs restart Stopping automount: [ OK ] Starting automount: [ OK ] [root@docbill001 html]# ls -la /test total 32 drwxr-xr-x 5 root root 4096 Jun 28 14:43 . drwxr-xr-x 26 root root 4096 Jun 28 14:43 .. drwxr-xr-x 2 root root 4096 Jun 28 14:40 a drwxr-xr-x 3 root root 0 Jun 28 14:44 autofs drwxr-xr-x 2 root root 4096 Jun 28 14:41 b [root@docbill001 html]# ls -la /test/autofs/a/b ls: /test/autofs/a/b: No such file or directory [root@docbill001 html]# ls -la /test/autofs total 16 drwxr-xr-x 3 root root 0 Jun 28 14:44 . drwxr-xr-x 5 root root 4096 Jun 28 14:43 .. drwxr-xr-x 2 root root 4096 Jun 28 14:40 a
(In reply to comment #3) > Same problem... > > [root@docbill001 html]# grep -v '^#' /etc/auto.master > /misc /etc/auto.misc > /net -hosts > /test/autofs /etc/auto.test > +auto.master > [root@docbill001 html]# grep -v '^#' /etc/auto.test > a / :/test/a \ > /b :/test/b Yep, that's all good. > > [root@docbill001 html]# service autofs restart > Stopping automount: [ OK ] > Starting automount: [ OK ] > [root@docbill001 html]# ls -la /test > total 32 > drwxr-xr-x 5 root root 4096 Jun 28 14:43 . > drwxr-xr-x 26 root root 4096 Jun 28 14:43 .. > drwxr-xr-x 2 root root 4096 Jun 28 14:40 a > drwxr-xr-x 3 root root 0 Jun 28 14:44 autofs > drwxr-xr-x 2 root root 4096 Jun 28 14:41 b Yep, that's all good. > [root@docbill001 html]# ls -la /test/autofs/a/b > ls: /test/autofs/a/b: No such file or directory Yep, I checked this and your right, it's is a bug. autofs should be creating the mount point directory in this case because it's not a remote file system (don't ask me why I require remote mount point directories to pre-exist, it's another story) but it isn't. The check for a local directory must be at fault. I'll check and see what I can come up with. Ian
As a workaround, is there a way to force autofs to use NFS over loopback? Whenever I try it converts the mount to a bind, even if I explicitly to -fstype=nfs. Bill
(In reply to comment #5) > As a workaround, is there a way to force autofs to use NFS over loopback? > Whenever I try it converts the mount to a bind, even if I explicitly to -fstype=nfs. That wouldn't help in this case. Even if this was possible the mount will fail in both cases unless /test/a/b exists prior to starting autofs. Ian
Created attachment 158191 [details] Patch to fix offset mount point directory creation Can you give this patch a try please.
Created attachment 158194 [details] Patch to fix offset mount point directory creation (5.0.1 version) Sorry, this patch should apply to RHEL-5 autofs. I've only checked it using the current version of autofs in CVS so let me know if there are any problems.
Sorry. I do not know how to build this. I tried the following: rpm -i autofs-5.0.1-0.rc2.43.0.2.src.rpm cd /usr/src/redhat/SOURCES; ls -lad autofs* What I found was a bunch of patch files as a autofs-5.0.1-rc2.tar.bz2 file. So I did: tar xvvfj autofs-5.0.1-rc2.tar.bz2 cd autofs-5.0.1 for i in ../*.patch ; do patch -p1 < $i ; done However, the result of this many HUNK FAILED messages. So obviously there is a special order in which I need to apply the patches, but I have no idea what that order is. I could just do an rpmbuild, but I can not find an option to allow me to apply a new patch to the source while building... Bill
I figured out a way to get the source with the patches applied: rpmbuild --recompile autofs-5.0.1-0.rc2.43.0.2.src.rpm cd /usr/src/redhat/BUILD/autofs-5.0.1 However, the patch did not successfully apply. I am attaching the *.rej file for reference.
Created attachment 158436 [details] autofs-5.0.1/daemon/automount.c.rej
Created attachment 158437 [details] autofs-5.0.1/daemon/automount.c.orig
OK. The patch was against the latest RHEL-5 CVS. I was hoping that it would apply. Since your not familiar with building rpms I'll need to provide this some other way. I'll grab the 0.rc2.43.0.2 revision and check. Ian
I also find with the manually applied patch autofs is now always reporting failure when I stop it: [root@docbill001 autofs-5.0.1]# service autofs restart Stopping automount: failed. Starting automount: done. [root@docbill001 autofs-5.0.1]# service autofs restart Stopping automount: failed. Starting automount: done.
I guess this is a more complicated problem than I thought. I took a few of my own stabs to fix this, but I am guessing the main reason for the check for mount type is to avoid recursive mount loops. I did come-up with a workaround that does what I wanted to do. Basically, I just use a script to mount all the respective submounts. It isn't pretty, but it works for both RHEL5 and Fedora 7. Basically, I just wanted to be able to have customized subdirectories based on what OS I boot to. Having, Fedora7 and RHEL5 use the same .kde, .gnome, ... directories causes endless problems. [root@d490f7x64 ~]# grep -v ^# /etc/auto.master /misc /etc/auto.misc /net -hosts /autohome /etc/auto.home +auto.master [root@d490f7x64 ~]# cat /etc/auto.home #!/bin/bash source="/home/$1" destination="/autohome/$1" name=Fedora7-$(uname -m) if [ -d "$source" ] then if [ ! -d "$destination" ] then mkdir "$destination" mount --make-shared --bind "$source" "$destination" fi s="$source/$name" if [ -d "$s" ] then for i in "$s"/* "$s"/.[^.]* ; do if [ -d "$i" -a ! -L "$i" ] then d="$destination/$(basename "$i")" if [ -d "$d" ] then umount "$d" 2>>/dev/null rmdir "$d" fi if [ ! -d "$d" ] then mkdir "$d" chown --reference="$source" "$d" chmod 700 "$d" fi if [ -d "$d" ] then mount --make-shared --bind "$i" "$d" 2>>/dev/null fi fi done fi # echo "--make-shared,bind :$source" fi
(In reply to comment #15) > I guess this is a more complicated problem than I thought. I took a few of my > own stabs to fix this, but I am guessing the main reason for the check for > mount type is to avoid recursive mount loops. Sorry, but it's more that I'm working on another really difficult problem at the moment. Actually the reason for the change was more complicated but the bottom line is that we require remote (eg NFS) filesystems contain the mount points they need. autofs will not create them and that has to remain the case. But due to a mistake in version 5 development this has stopped the bind mounts from working as well and that's what the patch is meant to fix. If I wish to make a RHEL-5 updated package available for testing I need to have checked the change into CVS but there's essentially a freeze on new work for due to the QA for 5.1 at the moment so I can't check in the patch. I can however update the F7 package and you could test that on F7 and RHEL. Of course you would be using an unsupported package for a while, but then we have the bug here for you to report back. To re-build the F7 package you can use: rpmbuild --rebuild autofs-<version>.src.rpm and the grab the binary rpms from /usr/src/redhat/RPMS<arch> and install them as usual. Would this help? Ian
autofs-5.0.1-17 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.
Works for me. :) Now if we can just get this back ported to RHEL.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
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 the 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. http://rhn.redhat.com/errata/RHBA-2008-0354.html