First of all - I’m starting with Linux, I’ve had it for like a week at this point. I am also still learning the troubleshooting and etc. so don’t expect me to know everything. I might ask stupid questions as I am still a big big learner
I am on Fedora Kinoite KDE plasma and i downloaded k3b through terminal, installed libburn and cdrskin. In the settings of k3b I had an error saying (i dont remember correctly) that to access the optical drive I must be part of the nobody group? So I tried to add myself to the said group and to the cdrom group - but despite this even after restart I couldnt see the mentioned groups when i typed “groups” in terminal. Though surprisingly, the error about the nobody group disappeared at this point?
So I tried to burn the CD again - oh wow, it was done, but not really. The cd ended up being “recorded succesfully” but empty.
So I tried again, the same thing. And again - then I got an error “a different application was using this cd - kioworker” alongside this:
/usr/bin/wodim: Operation not permitted. Warning: Cannot raise RLIMIT_MEMLOCK limits.scsidev: ‘/dev/sr0’devname: ‘/dev/sr0’scsibus: -2 target: -2 lun: -2/usr/bin/wodim: Cannot allocate memory.Cannot open SCSI driver!For possible targets try ‘wodim --devices’ or ‘wodim -scanbus’.For possible transport specifiers try ‘wodim dev=help’.For IDE/ATAPI devices configuration, see the file README.ATAPI.setup fromthe wodim documentation.Text len: 1134TOC Type: 0 = CD-DAcdrecord command:
The cdrom is actually shown in /dev as /dev/sr0 and is owned by root:cdrom
$ ls -l /dev/cdrom
lrwxrwxrwx. 1 root root 3 Aug 27 10:41 /dev/cdrom -> sr0
$ ls -l /dev/sr0
brw-rw----+ 1 root cdrom 11, 0 Aug 27 10:41 /dev/sr0
Thus to be able to use it the user must be part of the cdrom group.
To make yourself part of that group the command sudo usermod -aG cdrom $USER should add you to that group. Then the user must log out and back in before the group membership can take effect.
The command groups will usually show the groups your user belongs to.
However, it seems you are running kinoite so I am not certain how a users groups are managed there. The file of concern is /etc/group and you might try grep $USER /etc/group to see which groups you are actually included in.
$ groups
USER wheel cdrom dialout video render boinc libvirt
$ grep $USER /etc/group
wheel:x:10:USER
cdrom:x:11:USER
dialout:x:18:USER
video:x:39:USER,boinc,plex
render:x:105:USER,boinc
libvirt:x:983:USER
USER:x:1000:
boinc:x:972:USER
Hmm It actually just shows me my user name and wheel group, despite tryint o add myself to the cdrom multiple times. Is it possible that I cannot add myself to the cdrom group cuz I am on kinoite?
In kinoite you have two group files: /etc/group and /usr/lib/group. The full set of group names is located in the read-only file /usr/lib/group, and therefore you can only add yourself the few groups found in /etc/group.
What you need to do is
exctact the line containing “cdrom” from /usr/lib/group
And before you execute the command, make sure you have typed >> (append), not just a single > (overwrite). Otherwise you will probably have a pretty bad time.
k3b expects to be able to modify the permissions on the wodim and cdrdao binaries, but since kinoite has a read-only root filesystem, it’s unable to do so.
I’ve had luck in the past running k3b in a toolbox container, and although it’s far from ideal, the easiest set-up I’ve had was running it through toolbox as root.
then go to: settings → configure k3b → programs (left hand side) → permissions tab
make a note of the permissions there, k3b seems unable to fix them itself due to some dbus error.
exit k3b, and update the binary permissions that it wants. for me it was: (this only works inside the toolbox container)
you’ll need to add yourself to the cdrom group inside the container as well.
⬢ [ash@toolbx bin]$ sudo usermod -aG cdrom ash
re-start your toolbox shell by exiting it, then re-enter with toolbox enter k3b
launching k3b no longer complains, but unfortunately I’ve run out of burnable CDs to test this with, so it may not actually work, but I remember doing something along these lines in the past to get it working.
I guess at the core here though, those binaries should probably have the cdrom group ownership at install time, and I might suggest filing a bug for the package?
I downloaded it trough toolbox, like You did.
I tried to run k3b as root as You said, but then it says it fails to load my optical drive:/
I also tried to update the binary permissions in terminal, and it actually did the work for the growisofs ones, but for some reason it doesn’t do it for wodim and cdrdao. When i click on the change permissions it pops up the error saying:
"Action could not be performed
DBus engine error: failed to start service org.kde.k3b: The name is not activatable”
Does running k3b as root from the rpm-ostree installed version work for now?
outside of this my only other thought would be to use virt-manager to create a VM and passthrough your CD writer so you didn’t have to deal with how clunky k3b seems to be on kinoite.
I gave a try what You said (installing through rpm-ostree and then running with sudo) and for some reason it doesnt detect that I have growisofs already installed (with rpm-ostree).
Though when I open k3b outside from toolbox (with and without sudo), I don’t have the error "Action could not be performed
DBus engine error: failed to start service org.kde.k3b: The name is not activatable” when changing the permissions… And instead I get the error that “the following programs could not be updated [list of the programs from the permissions list]”
I guess my only choice could be using a vm as You said or using a different device that doesnt have kinoite
showing that the current logged-in user also gets read-write access. It should therefore not be necessary to make the user a member of the cdrom group or setting the setuserid bit on any program.
What the exact problem is, is hard to determine due to badly formatted message quoted in the first message.
