K3b can’t burn ISO image


This topic is a copy from the old manjaro form.
The issue is still pending and has not been finally resolved. A corresponding workaround is described here.

Description of the original topic:
I’m able to create and burn a new data DVD with k3b. But when I try to burn a ISO image with k3b I get the error message below.
If I interpret the error output correctly it is due to the permission.
Has anything changed here in the last time?
As root I can burn the image with the command cdrecord speed=2 Windows.iso

Error output of k3b:

HL-DT-ST BD-RE  BH10LS30 1.00 (/dev/sr0, CD-R, CD-RW, CD-ROM, DVD-ROM, DVD-R, DVD-RW, DVD-R doppelschichtig, BD-CD-ROM, BD-CD-R, BD-CD-R, DVD+R, DVD+RW, DVD+R doppelschichtig) [DVD-ROM, DVD-R sequenziell, Zweischichtige DVD-R sequenziell, Zweischicht-DVD-R-Sprung, DVD-RAM, DVD-RW Eingeschränktes Überschreiben, DVD-RW sequenziell, DVD+RW, DVD+R, Zweischichtige DVD+R, CD-ROM, CD-R, CD-RW, BD-CD-ROM, BD-R sequenziell (SRM), BD-R Zufällig (RRM), BD-CD-R] [SAO, TAO, RAW, SAO/R96P, SAO/R96R, RAW/R16, RAW/R96P, RAW/R96R, Eingeschränktes Überschreiben, Sprung zwischen DVD-Schichten, Zufällige Aufnahme, Sequenzielle Aufnahme, Sequenzielle Aufnahme + POW] [%7]

K3b Version: 20.4.3
KDE Version: 5.71.0
Qt Version:  5.15.0
Kernel:      5.4.52-1-MANJARO

Used versions
cdrecord: 3.2a09

cdrecord: Die Operation ist nicht erlaubt. Warning: Cannot raise RLIMIT_MEMLOCK limits.
cdrecord: Nicht genügend Hauptspeicher verfügbar. WARNING: Cannot do mlockall(2).
cdrecord: WARNING: This causes a high risk for buffer underruns.
cdrecord: Die Operation ist nicht erlaubt. WARNING: Cannot set RR-scheduler.
cdrecord: Keine Berechtigung. WARNING: Cannot set priority using setpriority().
cdrecord: WARNING: This causes a high risk for buffer underruns.
cdrecord: Insufficient 'file read' privileges. You will not be able to open all needed devices.
cdrecord: Insufficient 'file write' privileges. You will not be able to open all needed devices.
cdrecord: Insufficient 'device' privileges. You may not be able to send all needed SCSI commands, this my cause various unexplainable problems.
cdrecord: Insufficient 'memlock' privileges. You may get buffer underruns.
cdrecord: Insufficient 'priocntl' privileges. You may get buffer underruns.
cdrecord: Insufficient 'network' privileges. You will not be able to do remote SCSI.
scsidev: '/dev/sr0'
devname: '/dev/sr0'
scsibus: -2 target: -2 lun: -2
Warning: Open by 'devname' is unintentional and not supported.
Linux sg driver version: 3.5.27
SCSI buffer size: 64512
Cdrecord-ProDVD-ProBD-Clone 3.02a09 (x86_64-unknown-linux-gnu) Copyright (C) 1995-2016 Joerg Schilling
TOC Type: 1 = CD-ROM
Using libscg version 'schily-0.9'.
Driveropts: 'burnfree'
atapi: 1
Device type    : Removable CD-ROM
Version        : 5
Response Format: 2
Capabilities   : 
Vendor_info    : 'HL-DT-ST'
Identifikation : 'BD-RE  BH10LS30 '
Revision       : '1.00'
Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM.
Current: DVD+R
Profile: BD-ROM 
Profile: BD-R sequential recording 
Profile: BD-R random recording 
Profile: BD-RE 
Profile: DVD-RAM 
Profile: DVD-R sequential recording 
Profile: DVD-R/DL sequential recording 
Profile: DVD-R/DL layer jump recording 
Profile: DVD-RW sequential recording 
Profile: DVD-RW restricted overwrite 
Profile: DVD+RW 
Profile: DVD+R (current)
Profile: DVD+R/DL 
Profile: DVD-ROM 
Profile: CD-R 
Profile: CD-RW 
Profile: CD-ROM 
Profile: Removable Disk 
Using generic SCSI-3/mmc-3 DVD+R driver (mmc_dvdplusr).
Supported modes: PACKET SAO LAYER_JUMP
Drive buf size : 2555904 = 2496 KB
Drive pbuf size: 3850240 = 3760 KB
Drive DMA Speed: 16626 kB/s 94x CD 12x DVD 3x BD
FIFO size      : 4194304 = 4096 KB
cdrecord: Die Operation ist nicht erlaubt. rezero unit: scsi sendcmd: fatal error
CDB:  01 00 00 00 00 00
cdrecord: Die Operation ist nicht erlaubt. Cannot send SCSI cmd via ioctl.
cdrecord: Die Operation ist nicht erlaubt. Cannot open or use SCSI driver.
cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you are root.
cdrecord: For possible transport specifiers try 'cdrecord dev=help'.
Track 01: data  3993 MB        
Total size:     3993 MB = 2044640 sectors

cdrecord command:
/usr/bin/cdrecord -v gracetime=2 dev=/dev/sr0 speed=8 -sao driveropts=burnfree -data -tsize=2044640s -

What is the output of the command…



Workaround to solve the problem:

The required standard authorizations can be viewed in k3b under Settings --> programs --> permissions (see picture below)

The required rights and group membership can be set with the following commands.
sudo chmod 4710 /usr/bin/cdrdao
sudo chmod 4710 /usr/bin/cdrecord
sudo chmod 0750 /usr/bin/growisofs

sudo chmod 4710 /usr/sbin/cdrdao
sudo chmod 4710 /usr/sbin/cdrecord
sudo chmod 0750 /usr/sbin/growisofs

sudo chmod 4710 /sbin/cdrdao
sudo chmod 4710 /sbin/cdrecord
sudo chmod 750 /sbin/growisofs

sudo chown root:optical /usr/bin/cdrecord
sudo chown root:optical /usr/bin/cdrdao
sudo chown root:optical /usr/bin/growisofs

Finaly I add my user to GROUP optical:
sudo usermod -g optical <MyUserName>


What’s strange is that you have wodim installed. wodim is part of the cdrkit package, which is a fork of Jörg Schilling’s original cdrtools.

Manjaro and Arch both use the original cdrtools package by default, and the cdrkit package is neither in the Manjaro repository nor in the AUR. It is most likely conflicting with cdrtools, and so I’m curious as to how cdrkit ended up on your system.

I do know that several distributions use cdrkit instead of cdrtools, as a result of a licensing conflict between Jörg Schilling and Debian. In fact, I think cdrkit was developed by Debian, and from there it has made its way into all of the *buntus, as well as into Mageia, OpenMandriva and other non-Debian-derived distributions.

cdrkit does indeed require one to be a member of the cdrom group, which is called optical in Arch and Manjaro. cdrtools does not require this.

Thank you very much for the hint!
It has been a few days since I have tried the suggested solutions from the old forum. One of them was with wodim and this one has now accidentally taken over. Sorry for that.
To keep the clarity in this thread, it would be nice if you would delete your comments.

PS: I updated to post above

I think the clarity of the information in this thread would come to suffer if I were to do that. Clearly the issue was caused by installing cdrkit ─ wherever you installed it from, because this is neither a Manjaro package nor an AUR package ─ and thus my comments are pertinent. :wink:

I’m Sorry!
I do not have installed cdrkit, I have installed cdrtools.

My Manjaro installation is about three years old and I use Manjaro out of the box with some AUR packages.

Hmm… I’ve just looked on my system, and wodim does appear in the filesystem ─ which is strange ─ but here it appears to be a symbolic link to the actual cdrecord.

[12:23:03][aragorn] >  locate wodim

[12:23:13][aragorn] >  ll /usr/bin/wodim
lrwxrwxrwx 1 root root 8 Jul  7 17:35 /usr/bin/wodim -> cdrecord

[12:23:33][aragorn] > 


Same on my systen.

[mepi0011@pc ~]$ sudo find / -iname  wodim
[mepi0011@pc ~]$ ls /usr/bin/wodim
[mepi0011@pc ~]$ ls -l /usr/bin/wodim
lrwxrwxrwx 1 root root 8  7. Jul 17:35 /usr/bin/wodim -> cdrecord
1 Like

Finally the link from @pappl where he writes that he reported the problem in the KDE forum.

@Pappl, please share the link to the KDE forum with this forum too?

1 Like


The solution here was not the final one in the old archived forum.
I had to copy k3bhelper to lib64 additionally, then all problems gone!
Here my last entries from terminal history to make it work:
Don’t forget to replace MYUSERNAME with your user:

sudo usermod -a -G optical MYUSERNAME
sudo cp /usr/lib/k3bhelper /usr/lib64/kauth/k3bhelper
sudo chmod 4710 /usr/bin/cdrdao
sudo chmod 4710 /usr/bin/cdrecord
sudo chmod 750 /usr/bin/growisofs

Strange, no access to the old archived manjaro forum.

Edit: Can anybody fix the typo in the title?


1 Like

Normally we should be able to, but at present time this is only possible for moderators. It’s a bug in the way the forum was set up, and I’ve already notified the mods about it. :slight_smile:

1 Like

I’m having the same difficulties, but am using Brasero instead of K3b. (Just haven’t gotten around to installing K3b - it is the best choice for BD-Rs, for sure.)

The problem is definitely with cdrecord. It works fine as root, but throws a bunch of warnings if I run it as an unprivileged user, even though I am in the ‘optical’ group and device /dev/sr0 (which is the correct node) is rw for ‘optical’.

I’ve done the chmod commands above. Unless logout/login is required (can’t see why it would be), it’s not working for me.

Suggestions appreciated. Manjaro n00b, but not new to Linux.

Fixed, and title corrected. :slight_smile:


This is the full solution posted by user Nostromo from the archived forum:

and works for me fixing these problems:

In order to give K3b full access to the writer device the current user needs be added to a group optical.

No change of privileges possible in GUI:

Write process cancelled -> cdrecord has no permissions to open the device.


I suspect if we can get cdrecord working on the command line with normal user privileges (including being in the ‘optical’ group), K3b and Brasero will work, too. The key to the problem seems to be cdrecord.


some technical background:

The complaint about “Die Operation ist nicht erlaubt. rezero unit:” is
probably caused by the legacy SCSI command REZERO UNIT not being in the
list of harmless and halfways harmless SCSI commands of the Linux kernel.
Only the superuser is allowed to perform such commands via ioctl(SG_IO).

In cdrecord.c, function load_media(), one can see a gesture where this
SCSI command is emitted on purpose to find out whether the process of
cdrecord is subject to the normal safety precautions of Linux. If so,
it bails out with “Cannot open or use SCSI driver.”.
(The offending call is rezero_unit(). Comment snippet to search for is
“Linux- did break the SCSI pass through kernel interface.”)

The only obvious solution is to run cdrecord with full superuser power.
The classic and unsafe way to achieve this for normal users is to set
the setuid bit of the root-owned cdrecord binary.

As developer of libburn i officially state that it is not necessary to
impose such demands on the user. rw-permission suffices for all legitimate
CD, DVD, and BD operations.

Have a nice day :slight_smile:



This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.

Since I recently ran across this on two of my systems with Manjaro KDE:

What is the straight-forward way now of doing this? Should I start k3b as root?
Should I rather change permissions on several files as outlined above?

And why is it necessary to do this stuff at all? I mean, burning CDs/DVDs is not exactly something arcane nowadays (well, it probably will be in a couple of years, since they are rapidly going out of fashion) - I would expect that a modern Linux distro is able to handle this a bit more elegantly.