Bug 64426 - umount gives erroneous device is busy, nautilus-1.0.6-15
Summary: umount gives erroneous device is busy, nautilus-1.0.6-15
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: fam (Show other bugs)
(Show other bugs)
Version: 7.2
Hardware: i386 Linux
Target Milestone: ---
Assignee: Daniel Veillard
QA Contact:
Depends On:
Blocks: 67218 79579 CambridgeTarget
TreeView+ depends on / blocked
Reported: 2002-05-04 18:04 UTC by Ted Kaczmarek
Modified: 2007-04-18 16:42 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-08 16:57:26 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Ted Kaczmarek 2002-05-04 18:04:35 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.1 (X11; Linux i686; U;) Gecko/20020417

Description of problem:
I installed an old 20 gig drive I had laying around.
/dev/hdb1   *         1        10     80293+  83  Linux
/dev/hdb2            11       137   1020127+  83  Linux
/dev/hdb3           138       647   4096575   83  Linux
/dev/hdb4           648      2434  14354077+   5  Extended
/dev/hdb5           648       902   2048256   83  Linux
/dev/hdb6           903       953    409626   83  Linux
/dev/hdb7           954      1001    385528+  83  Linux
/dev/hdb8          1002      1030    232911   82  Linux swap
/dev/hdb9          1031      2434  11277598+  83  Linux

I mounted all the partitons that were mountable as /mnt/hdb1,2 etc.
I am unable to unmount /dev/hdb9, all the other partitions unmounted no problem.
fuser -u /mnt/hdb9
No process references; use -v for the complete list
fuser -v /mnt/hdb9
                     USER        PID ACCESS COMMAND
/mnt/hdb9            root     kernel mount  /mnt/hdb9

The box also has an 18gig scsi, 89 gig ide and two ide cdroms.
The cdroms are not presently mounted.
/dev/sda7              1004024    324236    628784  35% /
/dev/sda1                46636     15323     28905  35% /boot
/dev/sda3              2016044    817884   1095748  43% /home
none                    257212         0    257212   0% /dev/shm
/dev/sda8               774040     17628    717056   3% /tmp
/dev/sda2             11551080   3113368   7850940  29% /usr
/dev/sda5              1209572    358128    790000  32% /var
/dev/hda1              4031656    118468   3708392   4% /mnt/hda1
/dev/hda2              3780056    450360   3137672  13% /mnt/hda2
/dev/hda3             70973608  37052028  30316244  55% /mnt/hda3
/dev/hdb9             11100384   9112516   1423992  87% /mnt/hdb9

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

How reproducible:
Didn't try

Additional info:

I will try to reproduce, trying to figure out a workaround for know. More to follw.

Comment 1 Ted Kaczmarek 2002-05-04 18:29:16 UTC
With MHarris tip of using lsof, I found a .Trash file that was their. I removed
it and was still unable to umount the parttion. Went to init 1 and was able to
umount it. Mounted all the partitions again, and a different partiton that had a 
.trash is doing the same thing.
I will delete that .trash go to init 1 and run the same test again.
I am using nautilus-1.0.6-15, think this has nothing to do with the kernel :-).

Comment 2 Ted Kaczmarek 2002-05-04 18:35:36 UTC
Strange, I reproduced the device busy on a different partiton. Again I found a
.Trash with lsof. But this time after removing the directory I was able to
umount the partiton. I will try the same test again. Mount all the partitions
then try
umounting them.

Comment 3 Ted Kaczmarek 2002-05-04 18:51:27 UTC
If I create the .Trash on /dev/hbd9 which is mounted as /mnt/hdb9 and create the
.Tash with Nautilus I then can't unmount it. I created a .Trash in /mnt/hdb3 and
did an rm -r on the dir and am again not able to umount the partiton.

Hope this will be useful to someone.


Comment 4 Arjan van de Ven 2002-05-04 18:53:52 UTC
Yes this looks like nautilus...

Comment 5 Arjan van de Ven 2002-05-04 18:55:59 UTC
However it would be interesting to find out why not everybody+dog sees this...

Comment 6 Havoc Pennington 2002-07-06 22:29:37 UTC
Probably FAM. 

We also need to be sure right-clicking a removable media icon on the desktop and
choosing unmount works.

Comment 7 Alexander Larsson 2002-08-30 11:42:18 UTC
This could potentially be fixed in nautilus 2.0.5-4, which would mean this is a
dup of bug 70667.

Comment 8 Brent Fox 2002-10-19 00:52:41 UTC
Ted, can you try the fam and nautlius RPMS that shipped in 8.0 to see if that
fixes the problem?

Comment 9 Ted Kaczmarek 2002-10-19 12:45:10 UTC
Newer nautilus seems to have resolved this issue, when testing gnome2 from ximian
this problem has never shown up with them. Nautilus 2.0.X and up. Also have 8.0
running and not seen it as well.

Comment 10 Ted Kaczmarek 2003-07-31 01:38:49 UTC
Thanks for staying on top of this, would seem to make sense to close as upstream :-)

Comment 11 Havoc Pennington 2003-08-05 20:21:47 UTC
Yes, seems to be fixed in latest (RHL 9 and upstream)

Comment 12 Gary Lerhaupt 2004-03-05 20:56:16 UTC
This issue can be reproduced in RHEL3 gold by mounting a USB floppy, 
deleting a file from it using nautilus, emptying the trash, and then 
attempting to umount the usb floppy.  At this point it is still 
saying that the device is busy.  

An `lsof /mnt/floppy` implicates fam as holding onto 
a /mnt/floppy/.Trash directory and if you kill the pid, you can then 
unmount the drive.  Perhaps there is a USB edge case which was not 
resolved when this was closed or perhaps this is a separate bug?  
Reopening...please advise.  

Comment 13 Ted Kaczmarek 2004-06-02 11:08:50 UTC
This seems to have reappeared in FC2 as well, it is espescially touchy
with samba mounts, killing fam does fix it.

Comment 14 David Lehman 2004-07-26 20:57:34 UTC
I've been reproducing this on RHEL3-U2 with a regular floppy disk.
Once there is a .Trash-root directory on the floppy's fs it gets
picked up automatically on mount by nautilus/gnome-vfs/fam for
monitoring, and so can only be unmounted using nautilus, since
/bin/mount doesn't know to cancel the monitor on
/mnt/floppy/.Trash-root. This is especially aggravating if you mount
it from the commandline and then cannot unmount from the commandline.

It has something to do with the virtual trash URI in gnome-vfs/eel2 as
used by nautilus. I'm having a hard time tracking down the source of
the problem, but it's got something todo with the virtual trash folder
and use of dnotify by fam for monitors. 

As a (probably annoying) note, the problem disappears for me if I
rebuild fam without dnotify.

Comment 15 Daniel Veillard 2004-07-27 14:30:13 UTC
dnotify kernel API requires to open() the file to monitor. This is
a very bad kernel API side-effect. This can be worked around at the
eel/gnome-vfs level by not using the FAM API, or could be fixed by
using a better kernel API like inotify and the gamin library replacing
fam. Getting the right kernel API is the ultimate fix, this is a
work in progress at this point.


Comment 22 Daniel Veillard 2004-09-06 09:47:03 UTC
gamin now obsolete fam in Rawhide and the upcoming Fedora Core 3.
I believe that the current fixes at the gamin level and nautilus
fixes bugs of this kind.


Comment 23 Gary Lerhaupt 2004-09-08 16:08:45 UTC
Is this resolved in RHEL4?  Please reclose issue if it is.

Comment 24 Daniel Veillard 2004-09-08 16:57:26 UTC
This should be closed in RHEL4 for the same reason, you should
double-check the RHEL4 betas and reopen this bug if for some
reason it doesn't work. But this should work.


Comment 25 Gary Lerhaupt 2004-09-08 21:51:02 UTC
I just replicated this on FC2.  Is there a way this wouldn't be fixed 
in fc2 but still somehow be fixed in RHEL4?  Perhaps we should re-

Comment 26 Daniel Veillard 2004-09-08 21:56:28 UTC
FC2 does not have gamin. FC3 will, Rawhide does. That's normal.


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