Bug 227303 - accesses fail after umounting the mount point manually
accesses fail after umounting the mount point manually
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: autofs (Show other bugs)
4.4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Moyer
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-04 21:49 EST by wengang wang
Modified: 2007-11-16 20:14 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-02-05 11:12:22 EST
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 autofs manually umount problem. (1.93 KB, text/plain)
2007-02-04 21:49 EST, wengang wang
no flags Details

  None (edit)
Description wengang wang 2007-02-04 21:49:31 EST
Description of problem:

For auto.net,  If one umount the mount point mounted by autofs(automount)
manually, automount don't mount it again and after the umount even a new
accesses come, accessings under that mount point fail.

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

all version all release.

How reproducible:

100% reproducible.

Steps to Reproduce:
1. umount the mount point mounted by autofs(automount) mannually,
2. access under that just umounted mount point. 
3.
  
Actual results:

accessings fail.

Expected results:

accessings succeed.

Additional info:

a patch aganst kernel-2.6.9-34.0.1 is made as attached. please get this included
in update 5.
Comment 1 wengang wang 2007-02-04 21:49:31 EST
Created attachment 147336 [details]
patch to fix autofs manually umount problem.
Comment 2 Ian Kent 2007-02-04 22:21:57 EST
What happens if the mount point is not in the top level
directory? Won't this fail to return the needed dentry?

Ian
Comment 3 Ian Kent 2007-02-04 22:33:23 EST
And what happens if the user space daemon removes the directory
while you're using it?

Ian
Comment 4 Jeff Moyer 2007-02-05 11:12:22 EST
Autofs version 4 mounts each multimount hierarchy as a single unit.  What this
means is that autofs cannot determine that a leaf node in this hierarchy was
unmounted.  As such, this problem can only be fixed for non-hierarchical mounts.
 Fixing the problem for only that case will cause inconsistent behaviour, so I
do not believe the change is warranted.

Further, one should not unmount autofs managed mount points by hand.  You can
send SIGUSR1 to the daemon to tell it to unmount currently mounted shares.

Version 5 of the automounter takes steps to address this problem, though
unmounting shares by hand is not recommended.
Comment 5 wengang wang 2007-02-07 02:52:35 EST
hi Ian and Jeffrey,

to Ian:
I think what you metioned should be solved by user space program specified in
master map, like auto.master, if there are problems.

to Jeffrey:
yes, the change takes no effect on multimount hierarchy, because the upper level
mounted FS receives the request and autofs won't be notified.
Sometimes users don't rules and they like their convenient way. It's better we
make autofs robuster.
will autofs version 5 be included in RHEL4.5?

wengang.
Comment 6 Jeff Moyer 2007-02-07 12:08:47 EST
wengang,

I agree that autofs should be made more robust, and v5 accomplishes this.  I'm
not sure when autofs v5 will be available in RHEL 4, but it will be available at
some point.

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