Bug 164433 - autofs removed all files in mounted directory!
autofs removed all files in mounted directory!
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: autofs (Show other bugs)
4.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jeffrey Moyer
Brock Organ
:
Depends On:
Blocks: 156322
  Show dependency treegraph
 
Reported: 2005-07-27 17:11 EDT by Jeffrey Moyer
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version: RHBA-2005-657
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-05 12:59:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jeffrey Moyer 2005-07-27 17:11:55 EDT
+++ This bug was initially created as a clone of Bug #150116 +++

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041217 Galeon/1.3.19

Description of problem:
This may be a duplicate of 134399.  That bug was unclear about whether
the dir was being removed before or after it was unmounted.

On a network of machines I have /home/<dirs> being automounted with
the following yp auto.master and auto.home maps (respectively):

# ypcat -k auto.master
/home yp:auto.home
/misc yp:auto.misc

# ypcat -k auto.home
* -rw,soft,intr srv0:/export/home/&

Boy was I surprised to find my home directory (/home/brian) completely
empty at some point yesterday and get emptied of any new files I put
in it every 60 seconds.

Through a thorough investigation I came to discover that it was
automount on a number (but far from all) of the hosts that was
emptying my home directory.

From looking at the code it was obvious that umount_multi() that was
doing this "cleaning out" in this block of code:

    if (left == 0) {
        if ((!ap.ghost) ||
            (ap.state == ST_SHUTDOWN_PENDING ||
             ap.state == ST_SHUTDOWN))
            rm_unwanted(path, incl, 1);
        else if (ap.ghost && (ap.type == LKP_INDIRECT))
            rm_unwanted(path, 0, 1);
    } 

"left" is given a value just prior to that block of code depending on
whether the filesystem being mounted was found in the /etc/mtab file
and if it was successful in unmounting the shared filesystem if it was
found in the /etc/mtab file.

When i looked at the mount table on one of the hosts doing the
cleaning it was clear that /home/brian was indeed still mounted from
the server.  So either the block of code that was enumerating the the
/etc/mtab file or the block of code trying to do the unmount has a
defect in it that made automount believe that the filesystem was
either not mounted or was successfully unmounted.

This indeed is a very evil chunk of code if it goes wrong!

I have currently built and installed the -99 release of the autofs
package from rawhide along with a safety plug that does not actually
remove any found files in the tree.

Version-Release number of selected component (if applicable):
autofs-4.1.3-28

How reproducible:
Couldn't Reproduce

Steps to Reproduce:
Unknown as of yet.

Additional info:
Comment 1 Jeffrey Moyer 2005-07-27 17:16:13 EDT
A fix for this was built into autofs-4.1.3-151.
Comment 2 Kiersten (Kerri) Anderson 2005-07-27 17:24:09 EDT
Clone of the same defect in RHEL3 as 163620.  Dev ACK.
Comment 4 Jay Turner 2005-08-02 14:42:23 EDT
QE ack to prevent regressions with respect to RHEL3.
Comment 7 Red Hat Bugzilla 2005-10-05 12:59:34 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-2005-657.html

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