I'm running a fully updated F28/KDE system and I also get failures trying to blank a CD-RW disc.

[egreshko@meimei ~]$ /usr/bin/wodim -v gracetime=2 dev=/dev/sr0 speed=4 -tao driveropts=burnfree blank=fast
TOC Type: 1 = CD-ROM
/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 from
the wodim documentation.

The command also fails with the user in the cdrom group.  It also fails if selinux is set to permissive.

However, it does work as "root".

[root@meimei ~]# /usr/bin/wodim -v gracetime=2 dev=/dev/sr0 speed=4 -tao driveropts=burnfree blank=fast
TOC Type: 1 = CD-ROM
scsidev: '/dev/sr0'
devname: '/dev/sr0'
scsibus: -2 target: -2 lun: -2
Linux sg driver version: 3.5.27
Wodim version: 1.1.11
Driveropts: 'burnfree'
SCSI buffer size: 64512
Device type    : Removable CD-ROM
Version        : 5
Response Format: 2
Capabilities   : 
Vendor_info    : 'ASUS    '
Identification : 'DRW-24D5MT      '
Revision       : '1.00'
Device seems to be: Generic mmc2 DVD-R/DVD-RW.
Current: 0x000A (CD-RW)
Profile: 0x0015 (DVD-R/DL sequential recording) 
Profile: 0x0016 (DVD-R/DL layer jump recording) 
Profile: 0x002B (DVD+R/DL) 
Profile: 0x001B (DVD+R) 
Profile: 0x001A (DVD+RW) 
Profile: 0x0014 (DVD-RW sequential recording) 
Profile: 0x0013 (DVD-RW restricted overwrite) 
Profile: 0x0012 (DVD-RAM) 
Profile: 0x0011 (DVD-R sequential recording) 
Profile: 0x0010 (DVD-ROM) 
Profile: 0x000A (CD-RW) (current)
Profile: 0x0009 (CD-R) 
Profile: 0x0008 (CD-ROM) 
Profile: 0x0002 (Removable disk) 
Using generic SCSI-3/mmc   CD-R/CD-RW driver (mmc_cdr).
Driver flags   : MMC-3 SWABAUDIO BURNFREE 
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
Drive buf size : 362208 = 353 KB
Beginning DMA speed test. Set CDR_NODMATEST environment variable if device
communication breaks or freezes immediately after that.
Current Secsize: 2048
ATIP info from disk:
  Indicated writing power: 5
  Reference speed: 2
  Is not unrestricted
  Is erasable
  ATIP start of lead in:  -11940 (97:22/60)
  ATIP start of lead out: 335975 (74:41/50)
  1T speed low:  0 (reserved val  0) 1T speed high:  4
  2T speed low:  0 (reserved val  5) 2T speed high:  0 (reserved val 10)
  power mult factor: 3 5
  recommended erase/write power: 2
  A1 values: 02 3A A0
  A2 values: 5A A6 14
Disk type:    Phase change
Manuf. index: 43
Manufacturer: Acer Media Technology, Inc.
Speed set to 706 KB/s
Starting to write CD/DVD at speed   4.0 in real BLANK mode for single session.
Last chance to quit, starting real write in    0 seconds. Operation starts.
Performing OPC...
Blanking PMA, TOC, pregap
Blanking time:    0.171s

FWIW, you can workaround the problem by doing

sudo chmod +s /usr/bin/wodim

I checked an F27 system, it doesn't have a DVD, and suid isn't set.  But, as I said, I had no problems with k3b in F27.  I used it minimally.

Triaging to cdrkit (owner of wodim)

*** Bug 1591968 has been marked as a duplicate of this bug. ***

Hi, i analyzed the issue and found, that wodim (run as user, like k3b does it) issues a prlimit64(0, RLIMIT_MEMLOCK, {rlim_cur=RLIM64_INFINITY, rlim_max=RLIM64_INFINITY}), what fails, because the user is not root. However, the failure is ignored by the program and it continues, so the related message is confusing and misleading.
Later, wodim issues mlockall(MCL_CURRENT|MCL_FUTURE), what returns 0 (!?!).
Shortly later, it tries mmap(NULL, 1748992, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 EAGAIN (Resource temporarily unavailable) and terminates as consequence of this.
The error status EAGAIN means, that already memory according to the limit "max locked memory" is locked in memory, what is strange. wodim neither calls mlock nor mmap with MAP_LOCKED. The only thing i see is the above mentioned mlockall.
This mlockall should fail, because the program does not run with sufficient privileges.
So how comes the locked memory ?
My suspicion is, that the kernel is in the mlockall call so kind to lock as many memory as the currently effective limit (typically 16 MB, run ulimit -a to see) allows. That means, that the next mmap will fail, because the allowed locked memory is used up, what is in turn not so nice.

What i did to make k3b / wodim work is to write a shared object, that interposes mlockall and just returns 0 without doing anything. This suppresses the system call and thus the locking of memory and the following mmap's succeed and i can burn CDs/DVDs normally.

I would like to have clarified if the (assumed) behaviour of the mlockall system call is really desired, as it imo makes not much sense to lock 16 MB, what is only a tiny fraction of the memory today's program monsters (especially e.g. java programs) are consuming, so locking this little piece does not help much, especially as (i guess) it is not clear and more or less random, what part of the address space is locked then.

This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Bug is still present in F29, how to change Version here?

rebasing to f29

*** Bug 1580021 has been marked as a duplicate of this bug. ***

What I did as a workaround is that I opened a Konsole and ran:
su
ulimit -l unlimited
su [my user name]
k3b
and wodim works in that K3b instance without SUID.

In Fedora 30, CD burning is working 'out of the box" via k3b.

No workarounds needed.

I think assertions that this works in Fedora 30 are premature, as it
depends on exactly what your ulimits are.

The limit on locked memory pages (which can be seen with "ulimit -l")
determines how much memory an unprivileged process is allowed to lock.
So, in response to comment #5, mlockall() succeeds if the current size
of the process is less than the limit, but because this is called with
the MCL_FUTURE flag set, any future mmap will fail if the mmap would 
increase the size of the process to more than that limit.

Now wodim works fine if your ulimit is so small that the initial 
mlockall call fails; it just doesn't bother to lock the pages.
It will also work if the limit is large enough to cover all the
memory requirements of the process.  It fails if the limit is between
those values.

I have access to a number of Fedora 28 systems where the default
limit is 16384k, and wodim does not work on these systems.  I also
have access to a Fedora 30 system on which the default limit is 64k,
and wodim does work on this system.  (I don't understand why the limits
are different, since the settings for this in both systemd and pam are
blank on all systems, but that's a digression.)  Now it so happens
that on the Fedora 30 system, wodim successfully allocates memory if
I set the limit to 16384k.  But it fails if I set it to 8192k.  So
the underlying bug is still present on Fedora 30, although in practice
it happens to work by coincidence.

There are two possible fixes for this bug:

 (a) wodim should not call mlockall if it does not have the capability
     to do so.  Figuring this out is tricky: it can do so if the
     prlimit call succeeded, or the ulimit is high enough already,
     or it is running as root, or the process has CAP_IPC_LOCK.
or:
 (b) install the wodim binary with CAP_IPC_LOCK capability.

For anyone suffering this bug, item (b) can be applied as a workaround,
like this:
     sudo setcap cap_ipc_lock+pe /usr/bin/wodim

But this change will revert any time the wodim package gets upgraded
or reinstalled.

> In Fedora 30, CD burning is working 'out of the box" via k3b.

In the "out of the box" Fedora 30 installation I observe:
> cdrecord has no permission to open the device

Even, having my user in the cdrom group.

Created attachment 1609109 [details]
k3b error on cdrw writting in out-of-box Fedora 30

OK, rebasing to f30.

Can any cdrkit maintainer please at least comment?

*** Bug 1737178 has been marked as a duplicate of this bug. ***

This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '30'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 30 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

In Fedora 32 (wodim-1.1.11-44.fc32.x86_64), my conclusions at comment 12 still apply.  That is, wodim currently works because the default limit for locked memory is 64, but you can trigger the bug by raising that limit to, e.g., 8192.

I have a fresh install of Fedora 32 and I did not encounter any write problems.

Per Ian Collier's comment 18:

$ ulimit -l
16384

So I am not seeing his problem.

I would considered this fixed for Fedora 32.

My ulimit -l gives 64 on Fedora 32. What is the difference? Are you setting ulimit in some script?

(In reply to Robert Moskowitz from comment #19)

I did say you can trigger the bug by setting it to 8192, and earlier, 
that 16384 did not trigger the bug on Fedora 30.  So you did not 
disprove my point.

The fact is that this usually works now, but the underlying bug which
caused it not to work on some Fedora 28 systems is still present.  It's
up to the maintainers to decide whether this is "worth" fixing.

(In reply to Sammy from comment #20)
> My ulimit -l gives 64 on Fedora 32. What is the difference? Are you setting
> ulimit in some script?

I have no idea.  I am running F32 Xfce Workstation.   Plus whatever packages I added.

I have never, knowingly, done anything with ulimit.  I don't know what controls it or what it is for!

This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Cannot even erase a CD-RW

Devices
-----------------------
PIONEER BD-ROM  BDC-207D 1.00 (/dev/sr0, CD-R, CD-RW, CD-ROM, DVD-ROM, DVD-R, DVD-RW, DVD-R DL, BD-ROM, DVD+R, DVD+RW, DVD+R DL) [DVD-ROM, DVD-R sequenziale, DVD-R sequenziale a doppio strato, DVD-R jump a doppio strato, DVD-RW a riscrittura limitata, DVD-RW sequenziale, DVD+RW, DVD+R, DVD+R a doppio strato, CD-ROM, CD-R, CD-RW, BD-ROM] [SAO, TAO, RAW, SAO/R96P, SAO/R96R, RAW/R16, RAW/R96P, RAW/R96R, Riscrittura limitata, Salto di livello] [%7]

System
-----------------------
K3b Version: 22.8.1
KDE Version: 5.98.0
Qt Version:  5.15.6
Kernel:      5.19.15-201.fc36.x86_64

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

cdrecord
-----------------------
/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 from
the wodim documentation.
TOC Type: 1 = CD-ROM

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

On this system (still) running Fedora 35:

[kevin@desktop64 ~]$ ulimit -l
8192

There is nothing setting this in /etc/security/limits.conf or /etc/security/limits.d/.

This message is a reminder that Fedora Linux 36 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '36'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 36 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

problem still persists with F38 KDE using k3b to copy a CD; applying 

sudo chmod u+s /usr/bin/wodim

made it work.

(In reply to Joachim Schröder from comment #28)
> sudo chmod u+s /usr/bin/wodim
> 
> made it work.

Don't do that.  Do this (comment 12):
     sudo setcap cap_ipc_lock+pe /usr/bin/wodim

This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle.
Changing version to 39.

Still encontered this bug in Fedora 38 as well as Rawhide.
Also referring to: https://bugzilla.redhat.com/show_bug.cgi?id=2229520

Still in 40.

The bug is still present in F41
Thank you

(In reply to cornosier from comment #33)
> The bug is still present in F41
> Thank you

Can confirm with Fedora 41 and k3b-24.12.0

Bug still present in k3b-24.12.3-1.fc41.

Why isn't this fixed since seven years? It was first reported against Fedora 28.

Because most developers have long stopped using optical drives, so there is nobody still interested in fixing any issues with them.

This message is a reminder that Fedora Linux 40 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 40 on 2025-05-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '40'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 40 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

(In reply to Aoife Moloney from comment #37)
> Thank you for reporting this issue and we are sorry that we were not 
> able to fix it before Fedora Linux 40 is end of life. If you would still
> like 
> to see this bug fixed and are able to reproduce it against a later version 
> of Fedora Linux, you are encouraged to change the 'version' to a later
> version
> prior to this bug being closed.

Unable to change version field. Bug is still relevant