k3b won't write

English Multimedia
#1

This may be an upstream issue, as I’m having this problem on openSUSE LEAP 15.1 (2 systems), Kubuntu 18.04LTS (2 systems), and Solydk 9.

It first appeared on the Kubuntu systems in early to mid September, but It’s now happening on the openSUSE systems.
It won’t write images or data projects to either CD or DVD media.

In openSUSE the error says

cdrecord has no permission to open the device.
modify device settings in k3b to solve this problem

The messages in Kubuntu are slightly different, but to the same effect.
However, I even tried logging in as root and running k3b, I got the same error message.
Both root and cdrom have write permissions on /dev/sr0, and my user is in the cdrom group.
Here are the permissions for cdrecord

ls -l /usr/bin/cdrecord
-rwxr-xr-x 1 root cdrom 442160 Apr 28  2019 /usr/bin/cdrecord

I see that neither UID nor GID is set. Should they be?

Here are the contents of the debug log

Devices
-----------------------
ATAPI DVD A  DH24ABL GX12 (/dev/sr0, CD-R, CD-RW, CD-ROM, DVD-ROM, DVD-R, DVD-RW, DVD-R DL, DVD+R, DVD+RW, DVD+R DL) [DVD-ROM, DVD-R Sequential, DVD-R Dual Layer Sequential, DVD-R Dual Layer Jump, DVD-RAM, DVD-RW Restricted Overwrite, DVD-RW Sequential, DVD+RW, DVD+R, DVD+R Dual Layer, CD-ROM, CD-R, CD-RW] [SAO, TAO, RAW, SAO/R96P, SAO/R96R, RAW/R16, RAW/R96P, RAW/R96R, Restricted Overwrite, Layer Jump] %7]

System
-----------------------
K3b Version: 18.12.3
KDE Version: 5.55.0
Qt Version:  5.9.7
Kernel:      4.12.14-lp151.28.20-default

Used versions
-----------------------
cdrecord: 3.2a09

cdrecord
-----------------------
cdrecord: Operation not permitted. Warning: Cannot raise RLIMIT_MEMLOCK limits.
cdrecord: Cannot allocate memory. WARNING: Cannot do mlockall(2).
cdrecord: WARNING: This causes a high risk for buffer underruns.
cdrecord: Operation not permitted. WARNING: Cannot set RR-scheduler.
cdrecord: Permission denied. 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: Warning: Cannot read drive buffer.
cdrecord: Warning: The DMA speed test has been skipped.
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    : 'ATAPI   '
Identifikation : 'DVD A  DH24ABL  '
Revision       : 'GX12'
Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM.
Current: DVD-RW restricted overwrite
Profile: DVD+R/DL 
Profile: DVD+R 
Profile: DVD+RW 
Profile: DVD-R/DL layer jump recording 
Profile: DVD-R/DL sequential recording 
Profile: DVD-RW sequential recording (current)
Profile: DVD-RW restricted overwrite (current)
Profile: DVD-RAM 
Profile: DVD-R sequential recording 
Profile: DVD-ROM 
Profile: CD-RW 
Profile: CD-R 
Profile: CD-ROM 
Profile: Removable Disk 
Using generic SCSI-3/mmc-2 DVD-R/DVD-RW/DVD-RAM driver (mmc_dvd).
Driver flags   : NO-CD DVD MMC-3 SWABAUDIO BURNFREE FORCESPEED 
Supported modes: PACKET SAO LAYER_JUMP
Drive buf size : 1177600 = 1150 KB
FIFO size      : 4194304 = 4096 KB
cdrecord: Operation not permitted. rezero unit: scsi sendcmd: fatal error
CDB:  01 00 00 00 00 00
cdrecord: Operation not permitted. Cannot send SCSI cmd via ioctl.
cdrecord: Operation not permitted. 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  3637 MB        
Total size:     3637 MB = 1862198 sectors

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

It’s frustrating to have to fire up a Windows machine in order to write to optical media.

What am I missing?

Thanks,
ron

#2

I have no idea why this goes wrong, but I do not understand this detail. Maybe you are confused here and that is to be avoided :wink: (sorry if I completely misunderstand you here).
What you show is that the file /usr/bin/cdrecord can be read and executed by the owner (root), members of the group (cdrom) and all others (in fact thus: all). It can only be written into by root. That is a rather normal permission setting for a to be used by all, system installed program.

What the error says is IMHO about the permissions of the device file, in this case most probably /dev/sr0.
So you probably meant to show

ls -l /dev/sr0
#3

Sorry I wasn’t clear when I said

Both root and cdrom have write permissions on /dev/sr0, and my user is in the cdrom group.

It was intended to show that I had done

ls -l /dev/sr0
brw-rw----+ 1 root cdrom 11, 0 Nov  1 08:03 **/dev/sr0**

and that /dev/sr0 was, indeed, a block device with major and minor nodes of 11 & 0, respectively (as set up by udev). And that it was readable and writeable by both the owner (root) and group (cdrom).

Showing permissions for /usr/bin/cdrecord explicitly was done to show that the mode was 0755, not 4755 nor 2755 (or even 6755). And I was wondering if the SUID or SGID bits should be set on this program.

It occurs to me that I left out a salient bit of information. I AM able to erase rewriteable media if I set the “force” flag in K3b.

It also occurs to me that I haven’t tried changing the location of the $TMP variable in K3b. It’s set for /tmp, which is a 10GB partition, sized to enable writing DL DVDs. My assumption is that the kernel will simply overwrite files there that don’t have an active handle from current processes. I will try changing the $TMP variable in K3b to a location in a partition with multiple 100GBs of free space. If it then works, it means that the kernel is no longer doing that, hence a kernel issue.

I’ll let you know what I find.

ron

#4

Hm, several things here.

Thanks for the confirmation of /dev/sr0 and why the permissions of /usr/bin/cdrecord are shown.
I do not think it should have SUID/SGID bits set. I have one older openSUSE here and it isn’t there either (well, /usr/bin/cdrecord is a symlink to /usr/bin/woden, but that hasn’t those bits set).

I do not quite understand what you assume of /tmp. But the kernel does not remove/erase/overwrite any files there out of it’s own initiative. To the kernel /tmp has no special meaning. All that we might think to be special about /tmp is what administrators (the installation and later changes) give it as special property (like setting the t-bit for it and cleaning it on boot or regularly with via a crontab run).

But I do not read any pointer to /tmp (or whatever k3b uses as temporary) in the messages. OTOH I do not realy understand what the messages are telling us :frowning:

I guess we still wait for another k3b user (I haven’t used it since I have 15.1 running).

#5

It doesn’t seem to be a problem with k3b itself. I’ve not used k3b for quite some time now but I’ve just successfully written a (test) data CDRW

https://paste.opensuse.org/view/raw/18dfa307 (The average write speed is shown a 0KB/S, I’m sure(?) that was displayed correctly in the past…)
https://paste.opensuse.org/view/raw/fc29e59a

Using k3b 18.12.3 on an up to date leap 15.1 system

#6

There used to be an option in k3b’s settings, where it provided a part where it compared the systems permission settings for various stuff, and made a suggestion for correcting these. One had to enter the root password and it was fixed. But, I don’t have any machines left with optical drives, so I cannot check.

#7

Sorry. My bad.
It’s just that I don’t recall seeing a crontab entry to clean out the /tmp directory in any of the *nix systems I’ve been using since version 7.
Which probably speaks more to A) my powers of observation and/or B) my failing memory than to the presence or absence of any file-based cleanup mechanism.

Moreover, it was a red herring. The /tmp directory has 9.2GB free, according the df -h. I also created a world-writeable directory and pointed k3b to it for use as $TMP. K3b again failed to write in either case.

But another data point-- K3b now works correctly on one of the Kubuntu systems after the updates of the past week. I didn’t try changing anything there, just applied the updates.

I thought I had tried K3b from both openSUSE and Packman repositories, but it seems there is no K3b in Packman for openSUSE 15.1

I clearly have more work to do.

ron

#8

The current version of K3b in openSUSE 15.1 has an announcement, when you get to that tab, that K3b was not built with that option enabled. So no joy there.
It DOES indicate that it wants /us/bin/cdrecord (& 1 other file, I don’t recall the name) to have both user and group to be root, instead of root:cdrom for user and group.
I have manually (and external to K3b) tried changing the group of those files from cdrom to root, but still get the same errors. That’s why I tried logging in as root, to run K3b as root.

ron

#9

That AFAIK would not be persistent, i.e. destroyed on reboot. What you could do, is add your user to the cdrom group. AFAICS from your output that should work and it would be persistent.

#10

As I noted in my opening post, my userID IS a member of the cdrom group (among others).

So, while it may be persistent, it also doesn’t seem to help.

Thanks,
ron

#11

I’m coming in to this thread late but I note that Settings > Configure K3b… > Programs > Permissions tab shows the helper programs and their current/new permissions, and as you’ve already noted /usr/bin/cdrdao an/usr/bin/cdrecord have permissions set as 0755 , and k3b wants 4711…

sudo chmod 4711 /usr/bin/cdrdao

sudo chmod 4711 /usr/bin/cdrecord

FWIW, the same question in this Ubuntu thread…
https://askubuntu.com/questions/1032903/problem-with-k3b-in-18-04-releases-cdrecord-has-no-permission-to-open-the-devi/1034927

#12

That is the SUID bit (as the OP already wondered about above).

That would mean a change of policy for k3b?
I do not realy like this. I typical user program that executes owned by root. >:)

Also, seeing the situation that the OP shows us, the permissions of /dev/sr0 allow members of group cdrom to read and write. And the OP added the user to the cdrom group. Then why is this (dangerous) running as root needed?

#13

It shouldn’t be - that bad ‘workaround’ is presumably attempted as a means to get around the helper program user permissions.

#14

FWIW, I read another similar thread here (one of many it seems)…
https://www.linuxquestions.org/questions/slackware-14/plasma-5-k3b-cdrecord-user-permissions-issue-4175632137/

#15

As I read that, it is a typical case of:

  • I have read something on the Internet;
  • Having a permission problem, I changed permissions, ownership and added groups to users until it “worked”, no matter what the security implications are;
  • Never try to find out the root cause and file a bug with the developers/maintainers.

:disapointed:

#16

LOL …that sums it up Henk!

#17

Yes. K3b does recommend SUID on /usr/bin/cdrecord and /usr/bin/cdrdao.

But, as I noted previously, I have tried to REALLY brute-force the issue by logging in as root (to the desktop, not just a bash shell–and I’m aware of at least some of the dangers) and then launching K3b to do the write. I still got the same error messages.

That’s when I decided that there is more than just a permissions issue. Everything I was doing should have been with root permissions, so SUID/SGID wasn’t going to help.

I’ll go compare the versions of K3b on my openSUSE systems with that on my Kubuntu system that suddenly started working again and report back.

Thanks,
ron

#18

Very strange.

And that recommendation of k3b makes it unfit for use IMHO.

I wonder why. It wasn’t always like that.

#19

Versions:
Kubuntu: from within K3b: 17.12.3
from apt: 17.12.3-0ubuntu3

openSUSE: from within K3b: 18.12.3
from Yast: 18.2.3-lp151.1.2-x86_64

Both Kubuntu machines are 18.04.3LTS. One has HWE (hardware enablement) installed, the other does not (although I’m thinking about it-- it provides the 5.x kernel along with other, lesser upgrades).

I also checked the permissions in Kubuntu:

$ ls -l /usr/bin/cdr* /usr/bin/wodim 
-rwxr-xr-x 1 root root 665832 Jan 14  2018 /usr/bin/cdrdao
lrwxrwxrwx 1 root root      5 Apr 21  2017 /usr/bin/cdrecord -> wodim
-rwxr-xr-x 1 root root 180232 Sep 16  2017 /usr/bin/cdrskin
-rwsr-xr-x 1 root root 454376 Apr 21  2017 /usr/bin/wodim

while the permissions in openSUSE are:

> ls -l /usr/bin/cdr* /usr/bin/wod*
ls: cannot access '/usr/bin/wod*': No such file or directory
-rwxr-xr-x 1 root cdrom 646984 Mar 17  2019 /usr/bin/cdrdao
-rwxr-xr-x 1 root cdrom 442160 Apr 28  2019 /usr/bin/cdrecord
-rwxr-xr-x 1 root root  53720 Dec 17  2018 /usr/bin/cdrwtool

In Kubuntu /usr/bin/cdrecord is a symlink to /usr/bin/wodim, which is SUID root, while in openSUSE nothing is SUID/SGID and /usr/bin/wodim doesn’t exist (not even in the normal repositories–I haven’t checked OBS).

I seem to recall, when K3b wasn’t working in Kubuntu, that the debug output showed that it was trying to use /usr/bin/cdrskin, not cdrecord nor wodim. I didn’t look to see what it’s using now that it’s working again.

Is wodim the missing piece? Any clue why it isn’t in any of the normal openSUSE repositories?

I’m trying (unsuccessfully) to recall exactly when I upgraded these machines from LEAP_15.0 to LEAP15.1. I believe it was fairly recently, and I also believe that this is the first time trying to use K3b since that upgrade.

Does any of this help?

Thanks,
ron

#20

Yes, that has been the case for some time…
https://bugzilla.redhat.com/show_bug.cgi?id=1580021

In particular, the story about wodim and the security issues it presents are nicely summarised here…

wodim only exists because a hostile and uninformed Debian packetizer believed that writing optical media does not need special privilleges while starting personal attacks against me in May 2004.

His claim never has been true for any platform and this never has been true for Linux.

Since the main method used to “make the claim to apparently work” was to remove security checking code, I cannot tell whether wodim is a security risk when installed sid root.

The original software always was and is autited for security in this mode and not a risk.

In addition, cdrecord supports to work with fine grained privielleges on Solaris since January 2006 and after Linux added similar support in 2013, the fine grained privilege support was enhanced to Linux.

I recommend to use recent original software instead of the long dead code that was only seen as a hostile social attack froM Debian.

Check the most recent orignal code as part of the schilytools at:

http://sourceforge.net/projects/schilytools/files/

Is wodim the missing piece? Any clue why it isn’t in any of the normal openSUSE repositories?

No, it shouldn’t be needed at all IMHO.