because you're running it as a user.

the output is the command you've entered. i.e. ps is telling you that you ran it, and piped it's result to grep which looked for "gvfsd-cdd" (whatever that is). the only result it found was you looking for "gvfsd-cdd".

1 members found this post helpful.

Thank you rkelson

EDDY1 and rkelson: I think you may have missed the first command of the two in my original message. I think it is an attempt to find out what process if any is locking the drive.

This command

will tell you what processes are using the drive. Of course, you need to put the right device node there if it isn't /dev/sr0.

Anyhow, you didn't answer my previous question:

rkelsen No, I didn't know how to do that. I've now looked it up and I've got a few ideas for commands to try:

umount /dev/sr0 (you mentioned sr0)
umount /dev/scd0 (scd0 appears in fstab)
umount /media/cdrom0 (cdrom0 appears in fstab)

Apart from once, it has been working today, but I'll try next time it gets stuck. The software is obviously trying to eject as I can hear it, would the software try to eject a disk even though it knew it was mounted, that seems illogical?

I've given some thought to cause and effect - I think that if the disk has something wrong with it the software gets locked into a loop which it can't get out of. Even after I have rebooted and removed the disk manually it will still be a problem. It seems to resolve itself spontaneously.

I will also go through my DVD-RWs and format them and chuck out any dodgy ones, which should lessen the problem in future, but may prompt the problem to happen now.

You can't eject a disc which is still mounted.

Modern GUI interfaces will do both steps (i.e. umount and eject) with one click (eg: KDE's device notifier widget), but the drive will ignore it's eject button while a disc is mounted.
Part of your problem is that you don't know what device you're using. You need to figure that out. There are a gazillion ways of doing this.

The first 3 that come to mind:
Look at the output of dmesg
Look under /dev/
Look under /sys/block

I'd ignore anything in fstab, since that file is ignored for removable media. It could contain anything really.

It's just got stuck again trying to eject an empty tray using K3B, so I tried unmounting it using the following commands:

I then used a paperclip to open the tray, then loaded a DVD-RW (that I had previously formatted successfully) and tried to write a file onto it with K3B. It errorred with this debugging output:

I then ejected the disk with K3B without problem!
As a further test I:
- removed the disk.
- closed the empty tray with K3B - success.
- ejected the empty tray with K3b - stuck again!

umount won't eject the disc. You need to use umount, then eject.

That output makes me think you might have a permissions problem.

Is your user in the cdrom group? Find out by running this command:

Also, please post the output of this command:

And this one too:

I realised that (too late of course!), but it possibly still proved that the problem was not caused by the disk being mounted. I have just done the unmount and eject commands with all three objects I mentioned above - it sticks.

I then tried:
chris@Asus:~$ groups
chris cdrom floppy audio dip video plugdev netdev bluetooth scanner
chris@Asus:~$
I think this means that I have the permissions so it's not a permissions problem.

I then tried:
chris@Asus:~$ ls -la /usr/bin/wodim
-rwxr-xr-x 1 root root 359108 Oct 18 2010 /usr/bin/wodim
chris@Asus:~$
and:
root@Asus:/home/chris# ls -la /dev/sr0
brw-rw----+ 1 root cdrom 11, 0 Feb 8 01:32 /dev/sr0
root@Asus:/home/chris#

This is an earlier suggestion of yours:
root@Asus:/home/chris# fuser /dev/sr0
root@Asus:/home/chris#

From that output, we can conclude that your user does have correct permissions over the device. BUT your burning utility (wodim) isn't properly set up to burn discs as a user.

Log in as root (or switch user) and do this:

Then it should let you burn discs properly.

As to your ejecting problem, I've done some reading and it seems that HAL polling can disrupt the normal operation of some drives. If you want to try disabling it, you need to run this command:

If that doesn't solve the problem, then you can re-enable polling with this:

root@Asus:/home/chris# chmod +s /usr/bin/wodim
root@Asus:/home/chris#

I assumed you'd want me to check the results:
root@Asus:/home/chris#
ls -la /usr/bin/wodim
-rwsr-sr-x 1 root root 359108 Oct 18 2010 /usr/bin/wodim
root@Asus:/home/chris#
I understand that this is changing permissions although I'm not quite sure what.

I also did the hal command, I've reset that though because after rebooting twice it worked with a disk in but then refused to eject an empty tray. Could the empty tray be relevant?

It gives the wodim command escalated privileges so that it can communicate directly with the drive without requiring you to log in as root.
I dunno. I wouldn't rule out the possibility that you may have damaged the drive with a paperclip after all that.

lol! No it's not damaged it - there's a solid lump of plastic there. I'm sure it's a software problem for several reasons:
- it works most of the time
- it works without the ribbon cable
- I've had it before with a different PC and a different drive
- it happens mostly with an empty drive

How is the drive jumpered? Is it on "Cable Select"? That can cause these kinds of odd behaviours. If so, try putting the jumper on Master and using the end connector of the ribbon cable.

Edit: If that doesn't work, I got nuthin' else.

rkelson: I've taken out the cable select cable, put in a plain one and altered the drive jumpers from cable select to master and slave. I've also realised that I missed your message 21. I'll follow your suggestions therein.