I tried to burn a CD and got the "cdrecord has no permission to open the device" message, this was after I recently upgraded to 12.10.

So I ran K3bSetup to re-establish permissions for the 'burning' group and after that was able to burn a CD, though the disk I first tried to burn is now unusable.

My questions are these:

- why do the permissions get reset after updating to 12.10?

- when I first tried to burn a CD, with incorrect permissions, why was K3b able to render the CD unusable even though it (cdrecord) had "no permission to open the device"?

It would be helpful if K3b reported "sorry I don't have permissions to do this" BEFORE it destroys a disk!

The reset of the permissions was likely the fault of your distribution packages - either your user is not in the appropriate groups, or the distribution is not setting permissions/groups/etc properly.

As for why K3b does not warn you - some distributions do things differently to how K3b sets it up and it is very difficult / impossible to determine if the operation will fail due to permission problems until it actually attempts (at which point it is too late).

As for why the disk was rendered a coaster - not sure. It could be the a preparatory or post-burn program was run by K3b prior to/after invoking cdrecord and that did succeed.

NickElliott wrote:I tried to burn a CD and got the "cdrecord has no permission to open the device" message, this was after I recently upgraded to 12.10.

So I ran K3bSetup to re-establish permissions for the 'burning' group and after that was able to burn a CD, though the disk I first tried to burn is now unusable.

My questions are these:

- why do the permissions get reset after updating to 12.10?

- when I first tried to burn a CD, with incorrect permissions, why was K3b able to render the CD unusable even though it (cdrecord) had "no permission to open the device"?

It would be helpful if K3b reported "sorry I don't have permissions to do this" BEFORE it destroys a disk!

I'm having a similar problem, but no happy ending so far.

On my wife's notebook, running up-to-date Ubuntu 12.04, a data DVD+r burn fails a long way into the process.

The failure is reported as "cdrecord has no permission to open the device". I don't think that cdrecord is actually in use; I think wodim is used instead. But the "setup system permissions" knows that. /usr/bin/wodim has 0755 permissions, owned by root.root. Setup System Permissions wants to make it setuid root -- scary.

I don't think that this should be necessary since I have another notebook with up-to-date Ubuntu 12.04 and it has no trouble burning the very same project. The first notebook also has a problem with burning even when I try to use a different (external) DVD drive.

So there is something mysteriously different about the two machines. The permissions listed by Setup System Permissions are identical.

Looking at the debugging log is quite confusing. When shell commands are listed, command arguments are not quoted so you cannot tell an argument with spaces from multiple arguments.

I don't think all stderr logging from a subcommand makes it to the debugging log.

So I tried using strace to figure out what the failure is. wodim did successfully open /dev/sr0. The strace output is voluminous and therefor hard to figure out completely. But this looks to be relevant (strace truncates strings):

4885 ioctl(3, SG_IO, {'S', SG_DXFER_TO_DEV, cmd[10]=[2a, 00, 00, 1d, 93, a1, 00, 00, 1f, 00], mx_sb_len=16, iovec_count
=0, dxfer_len=63488, timeout=200000, flags=0x1, data[63488]=["\325\342\267\267\320\6\347\2010\t^\204\365\253zV\226\272.\
232\22\353*\370\334A>\265\231\6\270\217"...] <unfinished ...>
...
4885 <... ioctl resumed> , status=02, masked_status=01, sb[16]=[71, 00, 03, 00, 00, 00, 00, 0a, 00, 00, 00, 00, 0c, 00, 00, 00], host_status=0, driver_status=0x8, resid=0, duration=10956, info=0x1}) = 0
...
4885 write(2, "Errno: 5 (Input/output error), w"..., 366) = 366
4885 write(2, "/usr/bin/wodim: ", 16) = 16
4885 write(2, "A write error occured.\n", 23) = 23
4885 write(2, "/usr/bin/wodim: ", 16) = 16
4885 write(2, "Please properly read the error m"..., 46) = 46
...
4885 write(1, "\nwrite track data: error after 3"..., 73) = 73

None of this showed up in the "debugging output" that k3b showed me.

Summary: this looks like an I/O error. It is reported as a permission error. The Debugging Output doesn't have important information

Is any useful output given in dmesg? It could be a failure of the hardware to respond to wodim properly, or something similar.

bcooksley wrote:Is any useful output given in dmesg? It could be a failure of the hardware to respond to wodim properly, or something similar.

I looked at dmesg and saw nothing (so I didn't capture it).

I agree that it looks to be a hardware problem given the (truncated) message that I saw in the strace output.

It is interesting that the observed behaviour was the same with two different drives (internal DVD and external usb DVD) on the one machine.

I've burnt perhaps 5 coasters, so this doesn't seem to be a sporadic medium error.

Just out of interest - have you tried disconnecting other hardware unnecessary for burning a disc, and closing all programs to ensure they are not interfering in the burning process?

It might also be a bug in some part of the software stack - in which case trying the external burner on the system which is known to work properly might be a good idea.

Hugh wrote:I don't think all stderr logging from a subcommand makes it to the debugging log.

This turns out not to be the case.

I've put a copy of the debugging log on http://pastebin.ca/2418313. Since it's too long for pastebin, I've deleted large chunks of the boring parts.

In the middle of the 460k log, the error report is clearly laid out. I missed it because I expect errors to show up near the start or the end.

To my inexperienced eye, the message seems to indicate that the end of the disk was reached before the end of the data ("end-of-partition/medium detected"). Yet the log indicates that it wasn't close to the end ("3745 of 4351 MB written"). So this seems unlikely to me.

Can someone else interpret these messages for me? What's going wrong?

Here's the most interesting part (from line 632 of the pastebin file):

Track 01: 3745 of 4351 MB written (fifo 100%) [buf 99%] 6.3x.
Errno: 5 (Input/output error), write_g1 scsi sendcmd: no error
CDB: 2A 00 00 1D 42 DC 00 00 1F 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 72 0B 00 00 00 00 00 0E 09 0C 00 00 00 02 00 00
Sense Key: 0x0 No Additional Sense, Segment 11
Sense Code: 0x00 Qual 0x02 (end-of-partition/medium detected) Fru 0x0
Sense flags: Blk 0 (not valid)
cmd finished after 229.558s timeout 200s
/usr/bin/wodim: A write error occured.
/usr/bin/wodim: Please properly read the error message above.
Errno: 5 (Input/output error), test unit ready scsi sendcmd: no error
CDB: 00 00 00 00 00 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 71 00 03 00 00 00 00 0A 00 00 00 00 0C 00 00 00
Sense Key: 0x3 Medium Error, deferred error, Segment 0
Sense Code: 0x0C Qual 0x00 (write error) Fru 0x0
Sense flags: Blk 0 (not valid)
cmd finished after 0.001s timeout 200s
write track data: error after 3927367680 bytes
Writing time: 934.099s
Average write speed 3.6x.
Min drive buffer fill was 31%
Fixating...
Errno: 5 (Input/output error), close track/session scsi sendcmd: no error
CDB: 5B 00 02 00 00 00 00 00 00 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 72 04 00 00
Sense Key: 0x5 Illegal Request, Segment 0
Sense Code: 0x72 Qual 0x04 (empty or partially written reserved track) Fru 0x0
Sense flags: Blk 0 (not valid)
cmd finished after 0.004s timeout 1000s
Fixating time: 0.007s
/usr/bin/wodim: fifo had 62051 puts and 61861 gets.
/usr/bin/wodim: fifo was 0 times empty and 25505 times full, min fill was 92%.

Hugh wrote:To my inexperienced eye, the message seems to indicate that the end of the disk was reached before the end of the data ("end-of-partition/medium detected"). Yet the log indicates that it wasn't close to the end ("3745 of 4351 MB written"). So this seems unlikely to me.

I forgot to mention: this error looks nothing like what the GUI reported in the "Writing Data Project" window:
cdrecord has no permission to open the device.
You may use K3bsetup to solve this problem.

Are you using Ubuntu (or one of it's derivates) by any chance?
If so, you might want to take a look at https://bugs.launchpad.net/ubuntu/+sour ... bug/149076

bcooksley wrote:Are you using Ubuntu (or one of it's derivates) by any chance?
If so, you might want to take a look at https://bugs.launchpad.net/ubuntu/+sour ... bug/149076

I'm aware of the war between Joerg Schilling and various Linux folks. At least it started out as a licensing conflict (more or less).

One consequence is that most Linux distros (including Ubuntu and Fedora) use wodim, a GPLed fork of cdrecord. As I pointed out in my earlier messages, wodim works find on one machine and not on another, both under Ubuntu 12.04-with-updates. On the machine that worked, k3b under Fedora worked too. All these use wodim 1.1.11.

Having said that, the bug you pointed to does list the symptom I'm experiencing (Error 5).

Hugh wrote:Having said that, the bug you pointed to does list the symptom I'm experiencing (Error 5).

Another datapoint: I turned down the burning speed, based on the various reports there. All the way down to 2.5. The burn worked.

I wonder if the data-source (a USB hard drive using NTFS) was too slow to feed the burn at top speed. Sure would be nice if the tool (wodim) diagnosed that. Underrun could be a common failure mode for burns. "Overburn" was supposed to fix that up, mostly. I wonder if wodim does that right.

I will investigate a bit more.

I do recall seeing in the one of the output logs you posted that the lowest level for the buffer was 31% - which although a touch on the low side, should still be more than high enough to ensure the continuity of the burn.

I've freed up enough disk space to allow building a .iso image on the internal hard drive.

Burning succeeds at full speed when I have k3b build a .iso image before burning (just one tick box).

So: it looks as if USB I/O, NTFS filesystem handling, and on-the-fly composing of the image cannot reliably keep up with full-speed burning on this system.

It sure would be nice if K3B reported the error correctly (this was not a permission error!) and accurately (i.e. that a buffer underrun occurred [I think], beyond the capability of the drive's "burnfree" capability).

It looks to me as if it would be pretty hard to tell that the problem was underrun just from the wodim log. So maybe wodim needs to change.

Yes - This is a bug in K3b and Wodim, as Wodim is giving an incorrect response to K3b, which K3b is also misinterpreting to be permissions related.
Good to see you found a solution however. I would suggest updating any bug(s) you filed against K3b at bugs.kde.org, so the developers can rectify the behaviour of K3b in this regard.

bcooksley wrote:Yes - This is a bug in K3b and Wodim, as Wodim is giving an incorrect response to K3b, which K3b is also misinterpreting to be permissions related.
Good to see you found a solution however. I would suggest updating any bug(s) you filed against K3b at bugs.kde.org, so the developers can rectify the behaviour of K3b in this regard.

Thanks for your help. I've filed https://bugs.kde.org/show_bug.cgi?id=322096

I think cdrkit needs work but it appears to be an inactive project.