+++ 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:
A fix for this was built into autofs-4.1.3-151.
Clone of the same defect in RHEL3 as 163620. Dev ACK.
QE ack to prevent regressions with respect to RHEL3.
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