CD Eject after burning disc?

Latest response

RHEL 5.11, using the built-in nautilus disc burning tool... the app's eject disc button does not work unless you are root. The physical button works, but we'd like to have the SW eject when finished burning.

Is there something we're missing here?

Thanks.

Responses

Sorry, I don't have an immediate answer regarding the eject feature in that gui. I often run the eject command via command line. That being said, one possibility, (an end around...)

You could script it with cdrecord (or some other command line bit) and then run the command line 'eject' in the script. I can post an example later this week.

Hi Larry, unfortunately I'm in the same boat a Remmele in that I don't have an answer.

Are you able to eject the CD from other parts of Nautilus (like the file browser)? I'm struggling at this point whether to look at the OS permissions (group membership, udev rules, etc...) or GDM/Nautilus permissions.

If eject works from the CLI and other parts of Nautilus as a non-root user, it seems like the disc-burning tool is to blame and we can go that direction. Unfortunately it's been a looongg time since I have used RHEL 5 on the desktop ;-)

I ran # strace eject and I did not see any files being accessed (open/read) that helped. Then I thought I would look at the actual file perms themselves and the udev rules

# ls -l /dev/cdrom
lrwxrwxrwx 1 root root 3 Feb 10 02:32 /dev/cdrom -> sr0
# ls -l /dev/sr0
brw-rw---- 1 root disk 11, 0 Feb 10 02:32 /dev/sr0
# grep disk /etc/group
disk:x:6:root
# grep cdrom /etc/udev/rules.d/*
/etc/udev/rules.d/50-udev.rules:KERNEL=="sr[0-9]*",     SYMLINK+="cdrom cdrom-%k"
/etc/udev/rules.d/50-udev.rules:KERNEL=="scd[0-9]*",        SYMLINK+="cdrom cdrom-%k"
/etc/udev/rules.d/50-udev.rules:KERNEL=="pcd[0-9]*",        SYMLINK+="cdrom cdrom-%k"
/etc/udev/rules.d/50-udev.rules:KERNEL=="hd[a-z]", BUS=="ide", SYSFS{removable}=="1", SYSFS{device/media}=="cdrom", SYMLINK+="cdrom cdrom-%k"
/etc/udev/rules.d/50-udev.rules:KERNEL=="hd[a-z]", BUS=="ide", SYSFS{removable}=="1", PROGRAM=="check-cdrom.sh %k DVD", SYMLINK+="dvd dvd-%k"
/etc/udev/rules.d/50-udev.rules:KERNEL=="sr[0-9]*", BUS=="scsi", PROGRAM=="check-cdrom.sh %k DVD", SYMLINK+="dvd dvd-%k"
/etc/udev/rules.d/50-udev.rules:KERNEL=="hd[a-z]", BUS=="ide", SYSFS{removable}=="1", PROGRAM=="check-cdrom.sh %k CD-R", SYMLINK+="cdwriter cdwriter-%k cdrw cdrw-%k"
/etc/udev/rules.d/50-udev.rules:KERNEL=="sr[0-9]*", BUS=="scsi", PROGRAM=="check-cdrom.sh %k CD-R", SYMLINK+="cdwriter cdwriter-%k cdrw cdrw-%k"
/etc/udev/rules.d/50-udev.rules:KERNEL=="hd[a-z]", BUS=="ide", SYSFS{removable}=="1", PROGRAM="check-cdrom.sh %k DVD-R", SYMLINK+="dvdwriter dvdwriter-%k dvdrw dvdrw-%k"
/etc/udev/rules.d/50-udev.rules:KERNEL=="sr[0-9]*", BUS=="scsi", PROGRAM=="check-cdrom.sh %k DVD-R", SYMLINK+="dvdwriter dvdwriter-%k dvdrw dvdrw-%k"
/etc/udev/rules.d/50-udev.rules:BUS=="ide", DRIVER!="ide-cdrom", SYSFS{removable}=="1", GOTO="persistent_end"

Looking a littel further...

# lshal | grep -A20 cdrom | grep exec
  org.freedesktop.Hal.Device.Storage.method_execpaths = {'hal-storage-eject', 'hal-storage-closetray'} (string list)
# locate hal-storage-eject
/usr/libexec/hal-storage-eject
# ls -l /usr/libexec/hal-storage-eject
-rwxr-xr-x 1 root root 16616 Aug 13  2012 /usr/libexec/hal-storage-eject

Still nothing pops out at me as to what might be wrong at the OS level, which makes me think it's the Desktop Environment or Application preventing this. gconf-editor might help chase down the setting - it may be a boolean to allow non-root to mount/umount CDroms - I just don't have a machine handy to look though.

We received the following error message today while attempting to eject from the terminal as a non-root user:

"execl() error, error=13"

ls -l of /usr/libexec/hal-storage-eject shows the same permissions you show.

We also have the following entry in /etc/fstab which we are required as part of an update disk to be used upon deployment

/dev/cdrom  /mnt/updates    auto    defaults,rw,users   0 0

Sorry - I almost forgot that I had response to contribute.

I was going to suggest commenting out the CDrom entry in /etc/fstab (to test). If that allows your application to function normally, you might consider using the UUID of your "update cdrom" in the fstab so that it only mounts that specific device when necessary, which would not impact the functionality of the cdrom, in general.

You can get the UUID by running the command

blkid

Then you could update the fstab with

UUID=41c22818-fbad-4da6-8196-c816df0b7aa8  /mnt/updates     auto   defaults,rw,users 0 0

Hrm... the only issue I could potentially see there is the UUID.... the discs won't always be the same (the update discs will probably change over time and be re-issued), therefore won't they have different UUID's?

That is correct. I believe there is an option to mount by label also - but.. that would likely change as well (although you could actually control this aspect when you create the iso image).

excerpt from manpage for mount

       The device indication.
              Most devices are indicated by a file name (of a block special device), like /dev/sda1, but there are
              other   possibilities.   For   example,  in  the  case  of  an  NFS  mount,  device  may  look  like
              knuth.cwi.nl:/dir.  It is possible to indicate a block special device using its filesystem LABEL  or
              UUID  (see  the  -L and -U options below) and partition PARTUUID or PARTLABEL (partition identifiers
              are supported for example for GUID Partition Table (GPT) partition tables).

Mounting by labels might work, (assuming we're the ones controlling the creation of the update disk... something i'm not sure about.)

As it stands this is just a minor nuisance, since we can still eject from the physical button, but thanks for the suggestions and input. If I think of any additional questions i'll be sure to ask them.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.