Up until Fedora 14 I was successfully using cdctl to enable/disable the CD/DVD eject button on my laptop (Thinkpad T410). Sadly it has stopped working now.

I've consulted the methods discussed in these 2 questions:

None of which have worked for me. So I turn back to cdctl to see if we can't fix what's broken with it, since it's worked for so long.

Debugging the issue

So starting with cdctl switches I notice that most things seem to work just fine.


These things work.

ejects the drive

$ cdctl -e

list capabilities

$ cdctl -k
Tray close             : 1
Tray open              : 1
Can disable eject      : 1
Selectable spin speed  : 1
Is a jukebox           : 0
Is multisession capable: 1
Can read the MCN (UPC) : 1
Can report media change: 1
Can play audio discs   : 1
Can do a hard reset    : 1
Can report drive status: 1

According to that list cdctl even thinks that it can enable/disable the eject button.

Can disable eject      : 1

So I continue on with debugging the issue.

Debugging cdctl

So I figure lets do an strace on cdctl to see if it can shed some light on what's going on.

$ strace cdctl -o1
brk(0)                                  = 0x1371000
open("/dev/cdrom", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
open("/dev/cd", O_RDONLY|O_NONBLOCK)    = -1 ENOENT (No such file or directory)
open("/dev/scd0", O_RDONLY|O_NONBLOCK)  = -1 ENOENT (No such file or directory)
open("/dev/sr0", O_RDONLY|O_NONBLOCK)   = 3
ioctl(3, CDROM_LOCKDOOR, 0x1)           = 0
close(3)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

Curiously it seems like cdctl thinks it's disabling the button.

$ strace cdctl -o1
ioctl(3, CDROM_LOCKDOOR, 0x1)           = 0

$ strace cdctl -o0
ioctl(3, CDROM_LOCKDOOR, 0)             = 0

NOTE: If I understand this right, the return of a 0 means it was successful.

One thing that caught my eye here was the list of devices that cdctl is attempting to interact with. So I thought "what if I try these devices with eject"?

eject command

One of the other commands I used to use years ago was the eject command to interact with the CD/DVD device. I noticed that this command also now has a similar named switch:

$ eject --help
 -i, --manualeject <on|off>  toggle manual eject protection on/off


$ eject -i 1 /dev/sr0
eject: CD-Drive may NOT be ejected with device button

$ eject -i 0 /dev/sr0
eject: CD-Drive may be ejected with device button

So eject too thinks that it's disabling the button, yet it isn't either. Using strace here I see the same system calls:

$ strace eject -i 1 /dev/sr0 |& grep ioctl
ioctl(3, CDROM_LOCKDOOR, 0x1)           = 0

$ strace eject -i 0 /dev/sr0 |& grep ioctl
ioctl(3, CDROM_LOCKDOOR, 0)             = 0

So now I'm wondering if UDEV or something else is potentially blocking or taking ownership of device?


  • 1
    I also have a T410, and often find myself hitting the CD drive eject button when I don't mean to. I'll be interested to see if this gets resolved. Dec 12, 2013 at 4:11
  • Is the button still working when the Disk in that drive is mounted? Dec 12, 2013 at 5:24
  • 1
    I feel you pain, I had the same problem: Lock CD/DVD drive (prevent eject). I found no solution and ended up removing the drive physically, since it was too annoying to have the drive pop out a dozen times per day. Good luck…
    – Marco
    Dec 12, 2013 at 15:40
  • @Marco - see the answer!
    – slm
    Dec 12, 2013 at 22:35
  • @WhiteHotLoveTiger - see the answer!
    – slm
    Dec 12, 2013 at 22:35

2 Answers 2


Thanks to @Affix's answer which gave me the right direction to head, I've figured out the solution to the problem.

The problem is definitely caused by UDEV as you've guessed. The issue is this line that is in most UDEV files related to the cdrom drive.


On Fedora 19 there is the following file, /usr/lib/udev/rules.d/60-cdrom_id.rules. In this file is the following line which is co-opting the eject button for CD/DVD devices.

ENV{DISK_EJECT_REQUEST}=="?*", RUN+="cdrom_id --eject-media $devnode", GOTO="cdrom_end"

You can work around the issue and disable UDEV's ability to co-opt the eject button by doing the following:

  1. Make a copy of the file 60-cdrom_id.rules

    $ sudo cp /usr/lib/udev/rules.d/60-cdrom_id.rules /etc/udev/rules.d/.
  2. Edit this copied version of the file and comment out the line containing the string, DISK_EJECT_REQUEST.

    $ sudoedit /etc/udev/rules.d/60-cdrom_id.rules
  3. Save the file and the change should be noticeable immediately!

The above solution fixes the problem for both eject and cdctl. So now the following commands work as expected:

lock the drive

$ eject -i on /dev/sr0
eject: CD-Drive may NOT be ejected with device button


$ cdctl -o1

unlock the drive

$ eject -i off /dev/sr0
eject: CD-Drive may be ejected with device button


$ cdctl -o0
  • @Marco - I'm confused what you're asking me, I didn't change the /lib/ rule. I copied it to /etc/udev/rules.d/ and made my own overriding version.
    – slm
    Feb 1, 2014 at 14:24
  • @Marco - NP, there's ample places to get confused and make mistakes 8-)
    – slm
    Feb 1, 2014 at 14:31
  • Thanks for this. Confirmed in current Debian stable (8/Jessie). Commenting out that line instantly removed my ability to, e.g., accidentally eject a Bluray while it's mounted or even playing. Gotta love how udev overrides expected behaviour elsewhere in Linux... But now I can let KDE handle deliberate ejection and stop worrying about accidents. Oct 6, 2015 at 18:13

Add the line:


to the CD ROM udev rules. This will enable you to lock with:

eject -i
  • 1
    The line actually needed to be removed, at least in my case on Fedora 19.
    – slm
    Dec 12, 2013 at 22:37
  • Same here. Even so: Add it to which file? between which other lines? Is that the entire line? Surely that's not syntactically valid for udev? etc. - poor answer. Oct 6, 2015 at 18:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.