Nautilus can't eject cdroms. An error appears stating the cdrom is busy. I think
fam is monitoring the drive and should only be in read only mode.
It applies to floppies too.
This bug was present in RHL9 beta too. How can these be stopped from recurring?
This works for me... do you have a window open with the cd's mountpoint (or a
shell with cwd under the cd's mount point)?
No. lsof|grep floppy shows only fam using it.
This seems to be fixed in FC3, at least with cdroms. I don't use floppys that much.
I think I know how to reproduce this bug (or, at least, a very similar one).
I have a single test file in a "mp3" directory on a Flash drive. Today I plugged
the drive in a Windows box and, without telling me, it wrote two pictures in the
same directory (one for the song, one for the album, I think). I checked the
pictures using the command "eog /mnt/flash/mp3". After I quit eog, it wouldn't
let me unmount the disk, because it was apparently busy.
After some investigation, the "fuser" command pointed to the culprit: fam, which
still had /mnt/flash/mp3 open. I am confident that, besides mounting, I had made
no other accesses whatsoever to /mnt/flash or /mnt/flash/mp3. I just reproduced
it once more: mount, use only eog to access the directory -> fam keeps it open.
The only way out is to actually delete the directory (renaming it isn't enough).
It looks as if eog doesn't withdraw its notification request AND fam doesn't
notice that eog has quit leaving requests pending (I am not sure if it is
supposed to notice that kind of things, but it'd likely be more robust if it
No, i think its an actual bug in fam where it somehow leaks the monitor, or at
least the open fd on the dir. Fam should detect clients that disconnect and free
the clients monitors.
There are some other bugs in bugzilla related to this to i think.
*** Bug 107174 has been marked as a duplicate of this bug. ***
..possibly a duplicate?? (I get nothing relating to fam from fuser)
This seems NOT TO BE FIXED in FC3. The fam server block unmounting of cdroms. I
saw sam behavior in RHL 9. Severity CRITICAL for lame desktop users (like me :) ).
*** Bug 108030 has been marked as a duplicate of this bug. ***
This bug is still persistent in Fedora Core Release 1 (Yarrow).
I see this too.
Forgot... I see this too in Fedora Core 1. Sometimes I close the
nautilus window that is showing the cdrom folder and I can't eject the
cdrom until I "service xinetd restart" as root.
Will somebody fix unmounting bug in the next releases of Fedora or
even better in upodates of fam and others stuff?
In addition I wonder why the Gnome use its own automounting utulity,
KDE using own while there are three lower level tools like autofs,
automount ant somethikg else (I don't remember the name of). I think
it shoulb be OS not window manager case to mount and unmount devices.
Actual way of doing it makes mess and problems.
Is there a howto describing config of autofs and HOW TO DISABLE window
manager automounting functionality in Gnome and KDE?
In nautilus-monitor.c:135 one can read this:
* Don't monitor URIs on a read-only volume.
* This is a hack to avoid FAM keeping open fds to CD-ROMs,
* causing unmount/eject to fail.
This clearly isn't working.
Besides this I'm thinking that this may be caused by nautilus not
releasing a monitor before trying to unmount. This bug has annoyed me
to the point of making me dig through nautilus source, not an easy
task for someone not familiar with it. But this bug is biting me every
Even if it were working, it is not enough.
USB memory sticks should not be monitored either.
The thing is they are and should be monitored, in fact everything
should be monitored. The only exceptions are stuff on a read-only
volume, so this isn't really a hack, it's side effect is the hack. The
problem is that there is a bug somewhere making nautilus sometimes
think that a volume is read-write when it is not and another making
nautilus keep monitors alive after the views that were showing them
Provided that the two supposed bugs above are eliminated (or whatever
is causing this anomalous behavior) the only this that remains is the
impossibility to unmount volumes from anywhere but nautilus while a
nautilus view is open on them but that shouldn't really be a problem
as the users can easily perceive a nautilus view as the cause of the
I just hope someone with a deep knowledge in nautilus/gnome-vfs fixes
Oh, anyway. Nautilus does not seem to be the culprit,
opening and closing a nautilus window still allows the
volume to be unmounted.
But after opening a file there (using ggv or gpdf, IIRC)
the volume can't be unmounted.
IIRC these problems were earlier caused by monitoring the
recent file list in panel.
Actually, I've had some occasions where I mounted the volume (the
cdrom) navigated through it a bit and then I couldn't unmount it.
Aditionally, lsof shows fam as having a handle to a directory (mostly
/mnt/cdrom but sometimes some directory below /mnt/cdrom). I'm not
saying here that nautilus is the culprit but I'm also not saying that
it isn't as this is a transient and difficult to reproduce bug (it
could be a race, or a corner case or something, I'm not going to
elaborate on that as I don't know how nautilus works in sufficient
Your reference to the recent files list gave me an idea and I found a
way to reproduce this deterministically (it is a rather long list of
steps but not too tricky):
1. remove the ~/.recently_used file and logoff and login to clean the
recently open files list
2. now mount a cd which has a tar.gz somewhere
3. navigate to that directory and double-click the file to open it
4. the file is added to the "Open Recent..." list in the gnome menu
5. close everything (nautilus and file-roller)
6. unmount the cdrom (you can't, it is busy - if you can unmount it
just keep reading)
7. open a terminal, "su" to root and "service xinetd restart"
8. unmount the cdrom (you can now and as fam was restarted the recent
files list isn't updated to remove the file that has been opened on
10. just to prove a point login in the console and umount the cdrom to
make sure you can and then mount it again
11. log back on
12. the cdrom is mounted so unmount it (you can't, it is busy)
What can we conclude from steps 10. and 12? It is the recent files
list that is grabbing the cdrom.
I think that the recent files list is trying to be too smart here,
only the list should be monitored not the items themselves, am I
Created attachment 96641 [details]
Prevent the recent files menu from monitoring its files
One can read this in the gnome-panel package changelog:
"remove recent-monitor patch now upstream"
It doesn't look like it is so I reapplied the patch. It appears to work ok.
I've submitted a bug report in the GNOME bugzilla which is at
http://bugzilla.gnome.org/show_bug.cgi?id=129684 and one reply says
that this problem does not happen in nautilus >= 2.4.1 and fam >=
2.7.0 (hint, hint).
*** Bug 112545 has been marked as a duplicate of this bug. ***
*** Bug 114231 has been marked as a duplicate of this bug. ***
*** Bug 109984 has been marked as a duplicate of this bug. ***
*** Bug 109687 has been marked as a duplicate of this bug. ***
This is a complicated issue. Fam is often blamed because some app has
a monitor open on some directory, but killing that app makes fam
release the monitor. Such a problem is really not the fault of fam.
However, there *is* a bug in the dnotify code in fam that sometimes
made it forget that it had a monitor on a directory, so you had to
kill fam itself (as root) to fix it. This is really bad, but I finally
sat down and tracked down the bug. The fix is in fam-2.6.10-1, which
will be in rawhide shortly.
No doubt there are still ways to get fam to lock unmounts, however
thats not the fault of fam anymore, so i'm closing this bug.
Just an idea - what if fam had an option (turned on by default), that
made it look into fstab and ONLY open mountpoints who is'nt "noauto",
such as cdroms, floppies, and USB stics (why aren't these in the
fstab by default?). I know it is done on NFS volumes...
Hate telling my users to "always copy your documents of your floppy
etc. before opening them, and remember to copy them back afterwards.
And remember to unmount". We are talking second-time-linux-users who
has been so lucky to get an account on my scools LDAP/NFS server...
Most of them don't event try to use floppies on linux, and some asks
"can you surf the internet from Linux? Where is the big, blue, E icon
Hmmm... Downloaded the fam-2.6.10-3.i386 from some site (the rpm
claims it was built by redhat), and tried to upgrade.
When I insert an DVD (which for some reason don't get automounted?!?)
, and I browse the webpage on it with Mozilla (could be mozilla's
fault as well?), and when I then try to unmount it, it won't do it.
The message is that the device is busy.
Opening OpenOffice documents is no problem then (as far as I have
Here is some info:
[root@kyrre root]# rpm -qi fam
Name : fam Relocations: (not
Version : 2.6.10 Vendor: Red Hat, Inc.
Release : 3 Build Date: ons
25-02-2004 22:56:39 CET
Install Date: tir 09-03-2004 22:34:15 CET Build Host: porky.
Group : SystemmiljÃ¸/Demoner Source RPM: fam-2.6.10-3.
Size : 189284 License: GPL/LGPL
Signature : (none)
Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL : http://oss.sgi.com/projects/fam/
Summary : FAM, en filendringsovervÃ¥ker.
FAM, the File Alteration Monitor, provides a daemon and an API which
applications can use for notification of changes in specific files or
[root@kyrre root]# lsof | grep cdrom
fam 2481 kyrre 32r DIR 22,64 4096 264192
Maybee the bug should be reopened?
Are e.g. no nautilus windows open on the cdrom, or e.g. the recent
files issue can be cause this sort of thing. If something tells fam to
monitor the device it will, thats not a bug in fam itself.
I have looked again. The real reason for this is that
the gnome-panel in FC1 has an old copy of egg-recent that
attempts to monitor all entries in the recent file list.
gnome-panel in current CVS (so something like the upcoming 2.6
release) has this fixed.
There was a similar problem with a vfat usb filesystem connected as
a scsi device.
The computer: FC3 workstation in use since June 2005, some updates applied,
kernel version 2.6.9-1.667, currently up for 77 days.
The symptoms: In Jan 2006 suddenly unmounting /media/usbdrive stopped
working "almost always". Following the advice found here, used
lsof which shows open files on the drive.
Below the username and filenames that are irrelevant are replaced with
<username> and <filename> respectively. The lsof output shows
either an open DIR entry for /media/usbdrive/.Trash-<username> held by
gam_server or, after a file was deleted using nautilus, an open REG entry held
nautilus 16480 <username> 26r REG 8,17 24889 59021
An update from gamin-0.0.15-1 to gamin-0.1.1-3 did not solve
the problem. Killing the holding process, i.e. gam_server or nautilus
respectively helps. Either gam_server or nautilus get themselves
restarted immediatedly, but the device is not held any more.