LinuxQuestions.org - eject command only works as root...

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - eject command only works as root... (https://www.linuxquestions.org/questions/slackware-14/eject-command-only-works-as-root-4175457297/)

eject command only works as root...

I have 2 drives which are /dev/sr0 and /dev/sr1. Oddly enough /dev/sr1 will open with the eject command but for /dev/sr0 I get the following error when run as ordinary user:

Code:

andrew@skamandros~$ eject -v /dev/sr0

eject: device name is `/dev/sr0'

eject: expanded name is `/dev/sr0'

eject: `/dev/sr0' is not mounted

eject: `/dev/sr0' is not a mount point

eject: `/dev/sr0' is not a multipartition device

eject: trying to eject `/dev/sr0' using CD-ROM eject command

eject: CD-ROM eject command failed

eject: trying to eject `/dev/sr0' using SCSI commands

eject: SCSI eject failed

eject: trying to eject `/dev/sr0' using floppy eject command

eject: floppy eject command failed

eject: trying to eject `/dev/sr0' using tape offline command

eject: tape offline command failed

eject: unable to eject, last error: Inappropriate ioctl for device

But ejects just fine when run as root:

Code:

root@skamandros/home/andrew# eject -v /dev/sr0

eject: device name is `/dev/sr0'

eject: expanded name is `/dev/sr0'

eject: `/dev/sr0' is not mounted

eject: `/dev/sr0' is not a mount point

eject: `/dev/sr0' is not a multipartition device

eject: trying to eject `/dev/sr0' using CD-ROM eject command

eject: CD-ROM eject command failed

eject: trying to eject `/dev/sr0' using SCSI commands

eject: SCSI eject succeeded

Love some direction on this one...

I just attached the second DVD/CD-ROM drive to my machine. The `eject' command opens the second tray. The `eject -v /dev/sr0' command opens the first tray. The `eject -v /dev/sr1' command opens the second tray. I tried all those commands as a regular user (not root). I am sorry that my answer is not helpful but it seems that there is something wrong with your system and that is not some typical error.

Thanks for looking :). Looks like this is a fairly well known problem:

http://www.linuxquestions.org/questi...ct-4175425297/

What a pain.....

Just curious, try temporarily setting /usr/bin/eject as suid (chmod 4755 rather than 0755) and then try as non root.

Quote:

Originally Posted by Woodsman (Post 4927689)

Just curious, try temporarily setting /usr/bin/eject as suid (chmod 4755 rather than 0755) and then try as non root.

So far this seems to have done the trick, thanks :)

Great, but on the other hand, suid should not be needed. :( I've seen that needed only in one instance, while testing the new hardware libraries in Trinity, but that (currently) is a development environment. Try some different desktop environments. If the problem disappears and other desktops handle device ejections with a normal 0755 /usr/bin/eject, then the problem is that particular desktop environment.

Interesting, I am using Fluxbox, I shall investigate others...

andrew.46,

Recently I ran into the same suid problem. I can repeat your problem description here. All from the command line. I don't know why the problem occurs for some Slackware users and not others. :scratch:

Do you know how to compile packages? If yes I ran across a patch that helps. If not I'll post a full package for Slackware 14.

The original patch is available here, but needs to be updated for Slackware. My updated version is here.

Please let me know. I want to see the patch work for a second person before nagging Pat. :)

Also, without the patch, try the following:

mount a CD/DVD
unmount the disk
eject -rv

If you see the following error message then the patch probably will help you:

eject: unable to eject, last error: Input/output error

By the way, I notice the eject failure occurs only after mounting and then unmounting an optical disk. Without mounting I can toggle my tray all day with or without the patch. I need the patch to eject after mounting/unmounting.

Quote:

Originally Posted by Woodsman (Post 4932713)

Also, without the patch, try the following:

mount a CD/DVD
unmount the disk
eject -rv

If you see the following error message then the patch probably will help you:

eject: unable to eject, last error: Input/output error

By the way, I notice the eject failure occurs only after mounting and then unmounting an optical disk. Without mounting I can toggle my tray all day with or without the patch. I need the patch to eject after mounting/unmounting.

@Woodsman

I was having this problem as well (-current, 32 bit).

I just confirmed that my problem matched your description of only failing after mount/umount.

I modified the slackbuild from current to apply your patch and confirm that it now works after mount/umount.

Thanks!

My slackbuild modification is:

Code:

patch -p1 --verbose <$CWD/eject-2.1.5-unlock-2.patch

Well, the patch is not mine. I only tweaked the patch for Slackware --- but thanks. :)

I wish we knew why only some people are affected and not everybody.

Hmm, Is arbitrarily unlocking the drive like that safe? If anything it seems like it should be the unmount operation that unlocks it, rather than eject.

Quote:

Originally Posted by Woodsman (Post 4932749)

Well, the patch is not mine. I only tweaked the patch for Slackware --- but thanks. :)

I wish we knew why only some people are affected and not everybody.

Are you sure that only certain people are affected, or is it possible that only certain people are aware that they are affected?

In my own case, I do not often (ever) use the eject command directly on my main machine, a Toshiba laptop. But I have been setting up a newer desktop machine with -current and ran into the problem.

I noticed it on the desktop for several reasons:

1. The drive is a less convenient reach than the keyboard - so I eject instead pressing the button.
2. On the laptop my usage has tended to use cdrecord -eject instead. On the desktop I am not usually in a recording session so eject was more convenient.
3. I find optical media to be troublesome anyway, so if I had seen it happen before now I would likely have attributed it to the drive itself and pressed the button without further thought.

So if I had the problem before now I would not likely have recognized it. The coincidence of installing the new box and seeing this thread jolted the old brain cell into focus.

I don't know, but for somebody who has to live with a broken eject command, which seems to affect only some people, the point becomes somewhat academic. :)

It affects me to, though I tend to just push the button on the front rather than type eject.

As for the root/non-root issues. On my system it seems like it works like this

eject -r only works when the tray is empty. It doesn't matter if you are root or not. If the tray has a disk in it (even if it has never been mounted) then I get a.

Code:

ioctl(3, CDROMEJECT, 0x6057bc) = -1 EIO (Input/output error)

If you don't specify the -r option, then after trying and failing the above, eject will fall through to the next mechanism it has available and try the scsi command instead (eject -s), but it looks like non-root users can't issue the scsi command and get a:

Code:

ioctl(3, SG_IO, {'S', SG_DXFER_NONE, cmd[6]=[1e, 00, 00, 00, 00, 00], mx_sb_len=32, iovec_count=0, dxfer_len=0, timeout=2000, flags=0}) = -1 EFAULT (Bad address)

Anyway, looking a little deeper, /usr/src/linux/Documentation/ioctl/cdrom.txt:

Code:

CDROM_LOCKDOOR                  lock or unlock door



        usage:



          int lock;

          ioctl(fd, CDROM_LOCKDOOR, lock);



        inputs:

          Door lock flag, 1=lock, 0=unlock



        outputs:        none



        error returns:

          EDRIVE_CANT_DO_THIS  Door lock function not supported.

         EBUSY                Attempt to unlock when multiple users

                                have the drive open and not CAP_SYS_ADMIN



        notes:

          As of 2.6.8.1, the lock flag is a global lock, meaning that

          all CD drives will be locked or unlocked together.  This is

          probably a bug.



          The EDRIVE_CANT_DO_THIS value is defined in <linux/cdrom.h>

          and is currently (2.6.8.1) the same as EOPNOTSUPP

that seems to suggest that when run by root the unlock might not be safe as it won't care whether other users have the drive open or not.
this bit is also interesting.

It all feels a bit messy, and there's a few things to think about here. Given this, I get the feeling that CDROM_LOCKDOOR is best avoided all-round. I wonder how easy it would be to patch this out of udev/udisks or whatever is leaving the lock enabled (which seems like a bug to me)

update:
After looking at how the udev code handles this sort of thing. it seems like 'eject' has pretty much been undermined (at least for use with cdroms). Seems one has to use:

Code:

udisks --eject /dev/sr0

Stop the Linux!.. I wanna get off. :(

Quote:

Are you sure that only certain people are affected, or is it possible that only certain people are aware that they are affected?

You could be correct, especially after reading GazL's post. :)

Quote:

It affects me to, though I tend to just push the button on the front rather than type eject.

I use the physical button too, but I noticed the problem because my main office system case is several feet from my chair. Long ago I created a desktop shortcut to toggle the tray with eject -T. Yes, I still have to leave my chair to retrieve the disk, but the techie in me liked the idea of the eject shortcut. Moreso, programmatic ejection is important to me because I have an HTPC.

The eject -T command stopped working with Slackware 14.0 --- and remains broken. Slackware 14.0 was the first release without HAL, replaced by udisks(2).

My first experience with the broken eject command came soon after 14.0 was released.

I did not immediately update my systems to 14.0, doing so several months after the release. After I moved all of my systems to 14.0, I again noticed peculiarities with the eject command. I posted a query to find a way to determine the state of the tray. Pat responded with a short C snippet, after which you then responded to improve the crappy timeout method used in the original eject code.

The eject command breakage occurred with the transition away from HAL to udisks(2). I don't think the eject command sources are maintained anymore and like so much in free/libre software, most people no longer care.

As not all Slackers are using 14.0, that too probably contributes to people not noticing the breakage because previous releases have HAL, under which eject works.

Quote:

udisks --eject /dev/sr0

That command does not always work. :(

One example is the command is not a toggle like the original eject -T command. When there is no disk in an optical drive the udisks command fails with the following:

Eject failed: No media in drive

The command also does not work when the tray is open. Same error message. The udisks command is not a replacement for eject -T.

This thread prompted to investigate again because I use the Trinity desktop. Controlling removable devices in a HAL-less system required a new hardware detection method in Trinity, of which I am helping to test.

As a result of that testing, I probably am a tad more familiar with the eject breakage. I have tried several ways to dependably eject an optical disk or toggle the tray. The bottom line is the eject command is broken.

To replace the broken eject -T command, I now use a script wrapper around the basic C detection snippet Pat created. That wrapper script and C snippet work well, regardless of eject or udisks. Yet through my recent testing for Trinity I again stumbled across the fact that eject is broken in a HAL-less system. Without the patch the eject -T command now works only one way and no longer toggles. With the patch the eject -T command works both ways.

The only dependable method I found to fix the broken eject command is to suid /usr/bin/eject. Then the eject command works much better. Yet that is not the default installation permissions and along with my testing for Trinity and the above referenced thread, I again investigated.

The patch I found needed to be modified ever-so-slightly because of the patch you created to fix the eject command's tray detection status. :)

The patch linked in this thread works.

I don't know the appropriate strategy for handling the unlocking mechanism. I see the point in a multi-user system, but I am not concerned much about that in the broader scope because most Linux based systems these days, even with multiple users logged on to them, more than likely don't have such issues. That is, whoever is using the optical disk tray is the only person likely to want to eject the disk and not other users concurrently logged in. I understand the problem in a mainframe-like environment, but then again, optical drives are unlikely to be remotely used and controlled. I suppose somebody could SSH into a box, unlock a drive being used, and irritate the user, but discussing these corner cases seems academic.

In the end, the patch helps fix the eject command. :)

Conclusions?

* The eject command is funky in a HAL-less system.
* The udisks eject method works only when a disk is in the tray and is not a toggle.
* Setting /usr/bin/eject suid is an uncomfortable work-around.
* The patch in this thread helps avoid that work-around.
* My testing was not based upon any rigid scientific protocols.
* I'm no expert on any of this. :)