Bug 164433

Summary: autofs removed all files in mounted directory!
Product: Red Hat Enterprise Linux 4 Reporter: Jeff Moyer <jmoyer>
Component: autofsAssignee: Jeff Moyer <jmoyer>
Status: CLOSED ERRATA QA Contact: Brock Organ <borgan>
Severity: high Docs Contact:
Priority: medium    
Version: 4.0CC: cfeist, jmoyer
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2005-657 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-10-05 16:59:34 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:
Bug Depends On:    
Bug Blocks: 156322    

Description Jeff Moyer 2005-07-27 21:11:55 UTC
+++ 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 Jeff Moyer 2005-07-27 21:16:13 UTC
A fix for this was built into autofs-4.1.3-151.

Comment 2 Kiersten (Kerri) Anderson 2005-07-27 21:24:09 UTC
Clone of the same defect in RHEL3 as 163620.  Dev ACK.

Comment 4 Jay Turner 2005-08-02 18:42:23 UTC
QE ack to prevent regressions with respect to RHEL3.

Comment 7 Red Hat Bugzilla 2005-10-05 16:59:34 UTC
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