Description of problem:
Version-Release number of selected component (if applicable):
probably hal-0.5.11-2.fc9.i386 from F9 testing repo, build date 12-Jun-2008,
and/or udev-124-1.fc9.i386 from same source
when ejecting CD/DVD medium - by "eject /dev/sr0" cmd or by Nautilus - then
immediately after is ejected is dragget back into drive. No matter when it is
blank, valid iso or damaged iso medium.
Additionaly, device permission are 0640 (root:disk) even for blank media,
and k3b then cannot access to it.
Steps to Reproduce:
1. Update to hal & udev from F9 testing repo
2. try burn with k3b or mount some CD/DVD
3. eject these with Nautilus or eject command
medium is after ejection immediately reinserted into drive.
medium stay ejected
(In reply to comment #0)
> Additionaly, device permission are 0640 (root:disk) even for blank media,
> and k3b then cannot access to it.
What's the output of 'getfacl /dev/sr0'?
Sorry, this output I should add to report first.
After computer reboot and user (hanzlik) log-in, "getfacl /dev/sr0" print:
getfacl: Removing leading '/' from absolute path names
# file: dev/sr0
# owner: root
# group: disk
But after inserting media, no matter when blank or with ISO image,
"getfacl /dev/sr0" output is:
getfacl: Removing leading '/' from absolute path names
# file: dev/sr0
# owner: root
# group: disk
user rights are thus stripped by effective rights mask, which was changed.
Blank medium is at desktop properly displayed as blank, and ISO medium is
While changing mask for ISO image probably isn't too constrictive (but what if I
will wish add another session to multisession CD?), it perhaps disable burn to
As the output says you have an RW ACL for /dev/sr0 ... the "#effective:r--"
_comment_ is misleading because of the fact that /dev/sr0 is a read only device
(but you can still do ioctl's on it, that's the way cd burning works).
So I believe this is simply a bug in cdrkit (that is used in n-c-b and other
burning tools). So reassigning; cdrkit maintainers: Feel free to assign back if
you can explain I'm wrong. Thanks.
Frantisek: For the reinsertion issue please file a new bug report against hal
(and in the future please don't report multiple bugs in a single bug report).
After some fiddling I thing problem is definitely in udev-124-1.fc9.i386.
Dowgrading hal to previous version (hal-libs-0.5.11-1.fc9, hal-0.5.11-1.fc9,
hal-info-20080508-1.fc9, hal-devel-0.5.11-1.fc9) not solved problem.
But after dowgrading udev-124-1.fc9.i386 to original
udev-120-5.20080421git.fc9.i386 all works fine (even I upgrade hal-* again) -
when I eject medium, then it stay ejected, effective rights mask is always
"rw-", k3b startup environment test is
satisfied too (with effective rights mask "r--" k3b at start write:
No write access to device /dev/sr0
K3b needs write access to all the devices to perform certain tasks. Without it
you might encounter problems with TSSTcorp - CDDVDW SH-S203P
Solution: Make sure you have write access to /dev/sr0. In case you are not using
devfs or udev K3bSetup is able to do this for you.
It really appear as some udev-124 problem.
Frantisek: why did you reassign the bug to me? Please stop doing that.
I too am experiencing this problem, and can certainly pinpoint it to the
udev-124 release. Starting with a stick F9 system just updating udev will cause
this problem to show up.
David had me change the timing of the pam_console rules from 95 to 89, but that
change had no apparent effect upon the problem.
Triggering the issue is as simple as booting (to GNOME), then inserting media,
or removing already inserted media. The permissions of the device will resort
back to rw-r-- which imposes a permission mask upon the ACLs preventing the user
from doing anything.
Reassigning back to HAL until we finds the culprit.
Looks like this is the same issue as
well, what sets mode 660 to /dev/sr0 ?? udev sets 0640 initially.
and in udev-124 the "change" event is also processed, which resets /dev/sr0 to 0640.
pam_console does not cover cdrom anymore, btw
see also http://thread.gmane.org/gmane.linux.hotplug.devel/12758
I'm not sure what sets it to 660, but that's what it needs to be. When it's not
660, if group only has read access, that sets a mask upon any file system ACLs
that might get set, by the likes of policykit. The net results is that non-root
users are unable to write to the device for things like CD burning.
So maybe the bug here is that the change processing is finally setting things to
what udev thinks they should be, but we've been operating on an assumption that
udev 'thought' it should be 660, and we need to reflect that assumption now.
Created attachment 310962 [details]
Don't reset permissions on media change
The attached patch fixes it by reverting the upstream change that broke it ..
it isn't the cleanest solution but better than breaking cd burning for
everybody. Please consider adding this to an update until a "real" solution is
(In reply to comment #13)
> Created an attachment (id=310962) 
> Don't reset permissions on media change
> The attached patch fixes it by reverting the upstream change that broke it ..
> it isn't the cleanest solution but better than breaking cd burning for
> everybody. Please consider adding this to an update until a "real" solution is
> found upstream.
NAK. This is going to break DeviceKit-disks (soon to land in Rawhide) and other
things. The real fix is to not mess around with the permissions on 'change' events.
back to udev btw
the fix is wrong, because we need "change" events for other devices
*** Bug 454066 has been marked as a duplicate of this bug. ***
(In reply to comment #15)
> back to udev btw
hmm, udev upstream wants the app, which applied 0660, to apply it again on
change events... so? hal/consolekit?
The options are: make udev not to change permissions on "change" events, or let
the stuff that applies ACL's do the same thing on "change" as on "add" events.
I think the second option is the right thing to do, because "change" could mean
anything in a device context, including a making a different decision for
granting device access to users. But I'm open any reasonable argument.
Let me know. Thanks!
*** Bug 454082 has been marked as a duplicate of this bug. ***
udev-124-1.fc9.2 has been submitted as an update for Fedora 9
*** Bug 453591 has been marked as a duplicate of this bug. ***
udev-124-1.fc9.2 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
Okay, the new update fixes the problem with the permissions for reading cd and
dvd media. But the problem with the closing tray is the same.
When ejecting CD/DVD medium, then immediately after is ejected is dragget back
> When ejecting CD/DVD medium, then immediately after is ejected is dragget back
> into drive.
The happens here. I do not know how to remove the disk out of the computer...
I'm also still seeing the problem with the disk tray closing immediately after
eject. Occurs with DVD-Video, DVD-ROM, blanks, etc, regardless of if I use the
eject button on the front of the drive, use the eject command from Nautilus
desktop, or use the umount and eject commands in sequence from the console.
It does seem to eject correctly immediately following a successful burn by
Oh, and it also ejects normally if there's nothing current in the drive. It
only ejects and then immediately closes again (after reaching its full extension
briefly) if there is some media in the drive.
Does seem to duplicate bug 453095 but there seems to be more information on this
I am having a problem - I cannot mount and open my camera (a Nikon D300).
If I try to do so (using USB-PTP), mount it, and then try to open it (with
gThumbImageViewer of FSpot), I get the error:
An error occurred in the io-library ('Could not lock the device'): Camera is
already in use.
This started happening yesterday. Coincidentally, that was the same date that
udev was upgraded from 124-1.fc9.1 to 124-1.fc9.2 .
*** Bug 454122 has been marked as a duplicate of this bug. ***
(In reply to comment #29)
> Oh, and it also ejects normally if there's nothing current in the drive. It
> only ejects and then immediately closes again (after reaching its full extension
> briefly) if there is some media in the drive.
The same problem happens on my machine. I've tested a little bit with different
versions of the hal daemon and udev and it looks like that the problem is
triggered definitively by udevd:
- installing different versions of hal daemon: no change
- installing F9 release version of udev (udev-120-5.20080421git.fc9.i386.rpm):
problem does _not_ happen any more
I think this bug should be closed as permissions are fixed in latest udev
update. The separate bug 453095 is about tray beiing closed immediately.
I am currently running F9 with the latest updates and am seeing this issue. I do not believe it is fixed.
I may actually be seeing this (https://bugzilla.redhat.com/show_bug.cgi?id=423641 ) bug or these may be related bugs somehow.
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '9'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 9's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 9 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.