When a CD is mounted, the eject button on the CD-ROM drive is disabled (usually). Which is nice (or not, according to personal taste). So...

Q: How can I disable the eject button on my CD-ROM drive when there's NO disc in the drive?

The first person to come up with a simple software solution gets to smack my head and say "Doh!"

There are several possibilities:

* have the optical device mount via fstab and restrict umount to root
* rename, remove, or restrict to root the "eject" command
* some optical drives have a jumper which prevent ejection of media
* remove the eject switch from the drive itself

None of these methods will prevent ejection by a paperclip. To prevent that put a plastic or steel plate in front of the drive in question.

Well, I was thinking that since Linux can disable the eject button when a CD is mounted, the availability of the eject button must be under software control.

I've tried a few utilities (such as setcd and cdctrl) with no luck. Next on the list is cdctl, whose --lockdoor option looks promising...

KimVette:
* have the optical device mount via fstab and restrict umount to root
as you know: you cannot mount an optical drive, only a file system on the optical media inserted into the drive. This suggestion will prevent removal of media - but the question asks for disabling the eject button when there is no media present.

* rename, remove, or restrict to root the "eject" command
this will prevent soft ejection - but the eject button will still work

* some optical drives have a jumper which prevent ejection of media
this is hardware control of the eject button for security purposes. This would dsable the eject button while still allowing eject from software - nice but a software locking was wanted. (This may actually acheive the original aim though...)

* remove the eject switch from the drive itself


I think I'd be interested in how the various apps disable the eject button.
If a fs is mounted, then the eject button don't work - presumably it is possible to do this without mounting. So - how does mount disable/lock the cd-drive hard eject?

There's always a semantics-nazi isn't there. . .

Not if the filesystem is mounted (well, automounting aside)

Again: chmod, etc.

I can now report that cdctl's --lockdoor option works, i.e. it locks the eject button even when no CD is present (and therefore no filesystem is mounted). Download the source code and take a look!

setcd can (supposedly) do the opposite and enable the eject button even when a CD is mounted. Could be useful for ex-Windows users.

It doesn't prevent people opening the door with the override - that little hole you stick a paperclip down

There is a final solution for poor semantics ... just a quick shower? :>
... but there were two parts to that - which is to point out that original question...... specified that no CD-ROM be present. but the proposed solution required a CD-ROM to be present. A newbie coming upon this thread may not spot this since you specified mounting the "drive" where nobber specified mounting the "CD".

The last of your suggestions would actually have had the desired effect though. So this would be a neat workaround for someone who wanted to be security conscious.

I do find it difficult to think of some circumstance where a software solution would be better than this ... (say if you wanted to be able turn the lock on and off without a soldering iron? But why? The only circumstances I can think of are already taken care of?). There is always the never-ending quest for abstract knowledge of course - and it is desirable to understand ones machines lest they take over... they're multiplying you know... they are getting smarter... we must keep an eye on them... bad semantics is the first sign of impending moral collapse into the machine state!!!!! <gibber>

OK I'm better now.

I suppose the secret would be to set the drive status to "busy" - this would lock the drawer regardless of the content of the drive (as if a filesystem on media were mounted, right?)

So - where is the drive status stored? How would one go about changing drive status from within, say, a bash shell or a perl script?

phil.d.g: surely the only way of disabling that (the override hole) would be to plug it up?

yep, my point was a simple software solution is not possible.

I would expect the best thing to do is disable the manual override either by blocking it up or removing the mechanism and use software to disable the button.

Or if you do not need the CD drive and its obvious you don't want others using it, then just whip it out the computer - you don't have to disable something thats not there

OK, let's clear things up a bit here by explaining my motives for seeking this solution!

My system case rests on the floor, which means buttons not flush with the case are an easy target for my 18-month-old son. Until recently he'd have great fun powering my computer on (and more annoyingly, off) and opening and closing the DVD-ROM drawer - but not any more! A switching power supply and ACPI handling takes care of the power button (unless he keeps it pressed in for several seconds, but there's not much I can do about that), and now cdctl makes the DVD-ROM eject button useless. Hurrah!

Thankfully, my son hasn't yet figured out how to use a paperclip and the little hole. I hope I can trust all present here not to tell him about it...

Nobber>

In your case, get an antec or chieftec dragon or supermicro case with a locking door over the external 5.25" bays.

Simon Bridge>
*grin* great reply!

I agree with Kim, There is no software solution for toddlers... I have a 4yr old boy and he has filled my car stereo with peanut shell... I am teaching him to be respectfull or our CDROMS and DVD's but It's a hit a miss prop...

I agree... Just lock it out and make it unavailble... That is your only option... Kids will find a way...

KC

Hah! My box is behind a playpen-side out of reach. I'm luck tho - little Corwin (2.33) has learned to "be gentle"

I keep my tower off the floor, so only our notebooks are in (imminent) danger from our 9-month-old. Our older two (7 and 4) have always been surprisingly respectful of our computers.