wodim no longer works from non-root accounts

[John Zaitseff]

With the upgrade from Artful to Bionic (18.04 LTS), wodim no longer works for non-root users. Given that the cdrkit package itself has not changed (version 9:1.1.11-3ubuntu2), the most likely culprit is in the Linux kernel (Bionic, currently linux-image-4.15.0-20-generic 4.15.0-20.21).

In particular, running "wodim -v -dao -audio -copy *.wav" as a non-root user under Bionic now generates the following; this previously worked correctly in Artful and prior releases of Ubuntu:

TOC Type: 0 = CD-DA
wodim: Operation not permitted. Warning: Cannot raise RLIMIT_MEMLOCK limits.
wodim: Resource temporarily unavailable. Cannot get mmap for 12587008 Bytes on /dev/zero.

The exit code is 11.

Note that the user in question is a member of the cdrom group, and running "ls -la /dev/sr0" gives:

brw-rw----+ 1 root cdrom 11, 0 May 8 18:39 /dev/sr0

Attached is an strace of running the above command line. I could not find any workaround by a reasonably quick search of the Internet.

[John Zaitseff (zaitseff)]

The number of bytes being mmap()ed (12587008 bytes) may well be set in /etc/wodim.conf, where the following line appears by default:

CDR_FIFOSIZE=12m

Commenting out this line seems to solve the immediate problem, as only 8192 bytes are now mmap()ed--but I have not tested it with a read CD-R disc, as it seems to me that an 8kB FIFO buffer is a bit small!

After some testing (without any blank CD-Rs), it seems that CDR_FIFOSIZE=7788k works, but 7789k does not. I don't have anything that looks relevant in /etc/sysctl.conf or /etc/sysctl.d/*.

[John Zaitseff (zaitseff)]

Further to my last comment, I'm wondering whether the actual number of bytes that can be successfully mmap()ed is determined by how many other pages are already mmap()ed. Therefore I've set CDR_FIFOSIZE=6m in my /etc/wodim.conf. Hopefully that will work--I'll test it next time I have a CD-R to burn!

[John Zaitseff (zaitseff)]

Another comment: opening a shell and typing "ulimit -l" (max locked memory) gives 16384 (ie, 16MB).

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Tommy Stanton (tommystanton)]

I was running into this same issue while trying to copy a CD in K3B (in Pop!_OS 18.04 LTS).

Thank you for the tip about commenting out CDR_FIFOSIZE, @zaitseff; I'm now unblocked. 😹👍

[Zaphod BIII (maheinmuc)]

K3b also does not work for none-root user any longer.
K3b (Format/Erase rewriteable disk..)-> wodim: Operation not permitted

System
-----------------------
K3b Version: 17.12.3
KDE Version: 5.44.0
Qt Version: 5.9.5
Kernel: 4.15.0-38-generic

Used versions
-----------------------
cdrecord: 1.1.11

cdrecord
-----------------------
/usr/bin/wodim: Operation not permitted. Warning: Cannot raise RLIMIT_MEMLOCK limits.
/usr/bin/wodim: Resource temporarily unavailable. Cannot get mmap for 12587008 Bytes on /dev/zero.
TOC Type: 1 = CD-ROM

cdrecord command:
-----------------------
/usr/bin/wodim -v gracetime=2 dev=/dev/sr0 speed=10 -tao driveropts=burnfree blank=fast

LSB Version: core-9.20170808ubuntu1-noarch:printing-9.20170808ubuntu1-noarch:security-9.20170808ubuntu1-noarch
Distributor ID: Ubuntu
Description: Ubuntu 18.04.1 LTS
Release: 18.04
Codename: bionic
marcus@saturn:~$

Linux saturn 4.15.0-38-generic #41-Ubuntu SMP Wed Oct 10 10:59:38 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

[Martin Heckenbach (heckie75)]

I also see this problem in Ubuntu 18.10 cosmic:

$ wodim -prcap
wodim: Operation not permitted. Warning: Cannot raise RLIMIT_MEMLOCK limits.
wodim: Resource temporarily unavailable. Cannot get mmap for 12587008 Bytes on /dev/zero.

Kernel is:
Linux 4.18.0-12-generic #13-Ubuntu SMP Wed Nov 14 15:17:05 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

[Martin Heckenbach (heckie75)]

I found this solution, see https://bugzilla.redhat.com/show_bug.cgi?id=1580021

sudo chmod u+s /usr/bin/wodim

[A.RICHARD (6-contactmonsieur-u1)]

Thanks Martin. #8 fixed it for me.

[Niklas Sombert (ytvwld)]

Comment #3 suggested to set CDR_FIFOSIZE=6m in /etc/wodim.conf. This did work for me.

[Juliano Fischer Naves (julianofischer)]

Comment #3 did not work for me.
Comment #8 worked.
Thank you everybody, especially Martin!