Bug 246111 - multi-mount maps fail, can not map a hierarchy
multi-mount maps fail, can not map a hierarchy
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: autofs (Show other bugs)
5.0
All Linux
low Severity low
: ---
: ---
Assigned To: Ian Kent
Brock Organ
:
Depends On:
Blocks: 425884
  Show dependency treegraph
 
Reported: 2007-06-28 12:05 EDT by Bill C. Riemers
Modified: 2008-05-21 10:37 EDT (History)
2 users (show)

See Also:
Fixed In Version: RHBA-2008-0354
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-21 10:37:25 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 fix offset mount point directory creation (5.92 KB, patch)
2007-06-29 06:14 EDT, Ian Kent
no flags Details | Diff
Patch to fix offset mount point directory creation (5.0.1 version) (5.82 KB, patch)
2007-06-29 07:15 EDT, Ian Kent
no flags Details | Diff
autofs-5.0.1/daemon/automount.c.rej (542 bytes, text/plain)
2007-07-03 09:19 EDT, Bill C. Riemers
no flags Details
autofs-5.0.1/daemon/automount.c.orig (33.62 KB, text/plain)
2007-07-03 09:20 EDT, Bill C. Riemers
no flags Details

  None (edit)
Description Bill C. Riemers 2007-06-28 12:05:07 EDT
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:
Comment 1 Ian Kent 2007-06-28 13:51:20 EDT
(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
Comment 2 Bill C. Riemers 2007-06-28 14:39:20 EDT
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.


Comment 3 Bill C. Riemers 2007-06-28 14:45:59 EDT
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
Comment 4 Ian Kent 2007-06-28 15:17:04 EDT
(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
Comment 5 Bill C. Riemers 2007-06-28 17:14:15 EDT
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
Comment 6 Ian Kent 2007-06-28 23:59:09 EDT
(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
Comment 7 Ian Kent 2007-06-29 06:14:21 EDT
Created attachment 158191 [details]
Patch to fix offset mount point directory creation

Can you give this patch a try please.
Comment 8 Ian Kent 2007-06-29 07:15:54 EDT
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.
Comment 9 Bill C. Riemers 2007-07-03 09:06:34 EDT
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

Comment 10 Bill C. Riemers 2007-07-03 09:17:35 EDT
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.
Comment 11 Bill C. Riemers 2007-07-03 09:19:18 EDT
Created attachment 158436 [details]
autofs-5.0.1/daemon/automount.c.rej
Comment 12 Bill C. Riemers 2007-07-03 09:20:00 EDT
Created attachment 158437 [details]
autofs-5.0.1/daemon/automount.c.orig
Comment 13 Ian Kent 2007-07-03 09:26:59 EDT
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
Comment 14 Bill C. Riemers 2007-07-03 09:41:47 EDT

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.
Comment 15 Bill C. Riemers 2007-07-10 09:41:11 EDT
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

Comment 16 Ian Kent 2007-07-10 10:43:38 EDT
(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
Comment 17 Fedora Update System 2007-07-16 12:53:52 EDT
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.
Comment 18 Bill C. Riemers 2007-07-19 11:11:03 EDT
Works for me. :)  Now if we can just get this back ported to RHEL.

Comment 19 RHEL Product and Program Management 2007-10-15 23:56:10 EDT
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.
Comment 26 errata-xmlrpc 2008-05-21 10:37:25 EDT
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

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