LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 04-07-2013, 09:57 PM   #1
andrew.46
Member
 
Registered: Oct 2007
Distribution: Slackware
Posts: 646

Rep: Reputation: 90
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...
 
Old 04-07-2013, 10:17 PM   #2
w1k0
Senior Member
 
Registered: May 2008
Location: Poland
Distribution: Slackware, Mint
Posts: 1,240

Rep: Reputation: 196Reputation: 196
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.
 
Old 04-07-2013, 10:39 PM   #3
andrew.46
Member
 
Registered: Oct 2007
Distribution: Slackware
Posts: 646

Original Poster
Rep: Reputation: 90
Thanks for looking . Looks like this is a fairly well known problem:

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

What a pain.....
 
Old 04-08-2013, 12:44 PM   #4
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Rep: Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534
Just curious, try temporarily setting /usr/bin/eject as suid (chmod 4755 rather than 0755) and then try as non root.
 
1 members found this post helpful.
Old 04-12-2013, 08:22 PM   #5
andrew.46
Member
 
Registered: Oct 2007
Distribution: Slackware
Posts: 646

Original Poster
Rep: Reputation: 90
Quote:
Originally Posted by Woodsman View Post
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
 
Old 04-12-2013, 08:44 PM   #6
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Rep: Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534
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.
 
Old 04-13-2013, 08:17 AM   #7
andrew.46
Member
 
Registered: Oct 2007
Distribution: Slackware
Posts: 646

Original Poster
Rep: Reputation: 90
Interesting, I am using Fluxbox, I shall investigate others...
 
Old 04-16-2013, 05:08 PM   #8
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Rep: Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534
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.

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.
 
1 members found this post helpful.
Old 04-16-2013, 05:49 PM   #9
astrogeek
Senior Member
 
Registered: Oct 2008
Distribution: Slackware: 12.1, 13.1, 14.1, 64-14.1, -current, FreeBSD-10
Posts: 1,952

Rep: Reputation: 725Reputation: 725Reputation: 725Reputation: 725Reputation: 725Reputation: 725Reputation: 725
Quote:
Originally Posted by Woodsman View Post
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

Last edited by astrogeek; 04-16-2013 at 05:51 PM.
 
Old 04-16-2013, 06:36 PM   #10
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Rep: Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534
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.
 
Old 04-16-2013, 07:05 PM   #11
GazL
Senior Member
 
Registered: May 2008
Posts: 3,424

Rep: Reputation: 936Reputation: 936Reputation: 936Reputation: 936Reputation: 936Reputation: 936Reputation: 936Reputation: 936
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.
 
Old 04-16-2013, 07:09 PM   #12
astrogeek
Senior Member
 
Registered: Oct 2008
Distribution: Slackware: 12.1, 13.1, 14.1, 64-14.1, -current, FreeBSD-10
Posts: 1,952

Rep: Reputation: 725Reputation: 725Reputation: 725Reputation: 725Reputation: 725Reputation: 725Reputation: 725
Quote:
Originally Posted by Woodsman View Post
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.
 
Old 04-16-2013, 07:13 PM   #13
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Rep: Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534
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.
 
Old 04-17-2013, 07:59 AM   #14
GazL
Senior Member
 
Registered: May 2008
Posts: 3,424

Rep: Reputation: 936Reputation: 936Reputation: 936Reputation: 936Reputation: 936Reputation: 936Reputation: 936Reputation: 936
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.

Last edited by GazL; 04-17-2013 at 08:31 AM.
 
Old 04-17-2013, 09:37 AM   #15
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Rep: Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
how to eject a removable device in a software way, but not by "eject"command viktor2000 Linux - Newbie 13 10-14-2011 04:40 AM
Command not working in cron job, but works fine in root Roosta21 Linux - Software 4 11-22-2007 08:08 AM
uptime command only works for root user thoron! *BSD 6 09-08-2007 04:23 PM
Can't eject iPod as normal user, but works as root FreeThinkerJim Linux - Hardware 3 11-18-2005 08:19 PM
CD Won't Eject With "eject" Command Dr. Ephemeron Slackware 13 11-13-2003 12:27 AM


All times are GMT -5. The time now is 04:58 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration