Bug 121959
Summary: | Autofs squashes directories when submounts are in NIS | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Ken VanDine <ken> |
Component: | autofs | Assignee: | Jeff Moyer <jmoyer> |
Status: | CLOSED DUPLICATE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | thomas.duffy.99 |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-04-11 20:16:11 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Ken VanDine
2004-04-29 11:03:32 UTC
I notice this as well at our setup. We have an NIS map that mounts /usr/dist. I have had to sed out this map from /etc/init.d/autofs to make the machine happy again. The map looks like this: $ ypcat -k auto_direct /usr/dist -ro,bg,noquota,intr sd-umpk12-01.sfbay,sd-umpk12-02.sfbay,sd-umpk18-01.sfbay,sd-umpk18-02.sfbay,mi-umpk14-01.sfbay,mi-umpk14-02.sfbay,sd-umpk15-01.sfbay,sd-umpk15-02.sfbay,mi-umpk17-01.sfbay,mi-umpk17-02.sfbay,mf-umpk10-01.sfbay,mf-umpk10-02.sfbay,mf-umpk16-01.sfbay,mf-umpk16-02.sfbay:/usr/dist As a workaround for my setup, I have patched the initscript: --- /etc/init.d/autofs.4.19.04 2004-04-19 15:25:51.000000000 -0700 +++ /etc/init.d/autofs 2004-04-19 15:27:12.000000000 -0700 @@ -203,7 +203,8 @@ if [ "$UNDERSCORETODOT" = "0" ] ; then map=`basename $map | sed 's^//^/^g'` else - map=`basename $map | sed -e s/^auto_home/auto.home/ -e s/^auto_mnt/auto.mnt/` +# map=`basename $map | sed -e s/^auto_home/auto.home/ -e s/^auto_mnt/auto.mnt/` + map=`basename $map | sed -e s/^auto_direct//` fi fi fi Direct mounts take over from the second from top level directory. So, if you have a direct mount specified for /usr/local/mounts, then autofs will take ownership and mount over /usr. This is how it was designed, and there should be a note about this in the README.direct file. For the initial bug reporter, if you are not using direct maps, please attach a copy of your auto.master and the map file which causes you problems. Thanks! But this works fine in Solaris. From: Ian Kent To: Jeff Moyer Subject: Re: autofs and 2.6 Date: Fri, 26 Mar 2004 10:37:56 +0800 (WST) On Thu, 25 Mar 2004, Jeff Moyer wrote: > > One unrelated issue, how are direct mounts designed to work? I thought > they would not take over a directory. So, if you had a /var/spool > directory, and you wanted /var/spool/mail to be a direct mount, that should > still allow visibility into /var/spool/cron for example. > > At any rate, it seems the current autofs is not designed that way. And, in > fact, if you configure /var/spool/mail as a direct map, autofs takes over > /var! Here is a Red Hat bugzilla on said subject: Yes. That's right on both points. A sore point with me and something I have needed at work for a long time and still have not done it. There are a couple of reasons it's that way. It minimises the number of anonymous mounts needed. Was previously a problem with 2.4 even with the mone-unamed patch as sites with reasonable sized direct maps would quickly use the 1200 available mounts. For example we have between 550 and 600 entries in our direct mount map. It retains compatibility with previous autofs versions. Lame one this. And the big one. It's hard to do within the current design! The current design uses a filesystem and works on the base of the tree for detecting mounts and so obsures the underlying fs. So to do this a redirection layer is needed on top of autofs. I have loopback filesystem (aka striped down wrapfs, www.filesystems.org) I can use but haven't started work on it yet. I don't want to start on this until the current work makes it into the kernel because it will be hard to maintain multiple branches as well as being to much to swallow in one go for the kernel maintainers. Mike Waychison and Tim Hocking have made a proposal that will cover all these issues but I expect they will not have a procuct for some time(2.7 or 2.8 time frame). In the meantime I have decided to persevere with the current design and take it as far as I can. Sorry, I can't be much help on this yet. Ian |