[SOLVED] Brasero won't write to disc because of permissions

pavlosdec · 2020-11-08 10:09:41

I don't know if this problem is a simple one, but I'm stuck.
I tried to burn an ISO to CD-R with Brasero. Before the writing begins it gives me this message "You do not have the required permissions to use this drive" and it ejects the disc.
I added the user to these groups: storage, disk, optical, but the outcome was the same.
I read the wiki (Optical disc drive page) and I tried to burn the ISO with the cdrecord CLI command as a user and it failed. But with the same command with sudo succeded...
What kind of permission I'm missing here?

Thanks for any help.

Last edited by pavlosdec (2020-11-12 17:44:34)

pavlosdec · 2020-11-08 10:14:52

This is the output of cdrecord used by normal user:

Cdrecord-ProDVD-ProBD-Clone 3.02a09 (x86_64-unknown-linux-gnu) Copyright (C) 1995-2016 Joerg Schilling
TOC Type: 1 = CD-ROM
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
Using libscg version 'schily-0.9'.
SCSI buffer size: 64512
atapi: 1
Device type    : Removable CD-ROM
Version        : 5
Response Format: 2
Capabilities   : 
Vendor_info    : 'HL-DT-ST'
Identifikation : 'DVDRAM GH22NS50 '
Revision       : 'TN02'
Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM.
Current: CD-R
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 
Profile: DVD+R/DL 
Profile: DVD-ROM 
Profile: CD-R (current)
Profile: CD-RW 
Profile: CD-ROM 
Profile: 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 LAYER_JUMP
Drive buf size : 1053696 = 1029 KB
Drive pbuf size: 1966080 = 1920 KB
cdrecord: Warning: DMA resid 0 for 'read buffer', actual data is too short.
cdrecord: Warning: The DMA speed test has been skipped.
FIFO size      : 4194304 = 4096 KB
Track 01: data   562 MB        
Total size:      646 MB (64:00.97) = 288073 sectors
Lout start:      646 MB (64:02/73) = 288073 sectors
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'.

Last edited by pavlosdec (2020-11-08 16:13:17)

mpan · 2020-11-08 11:32:11

Could it be that issue?

pavlosdec · 2020-11-08 11:36:23

I think it clould be tha same. And it is still unsolved...
I will keep an eye on that thread, thank you...

ewaller · 2020-11-08 15:16:44

Can you verify that the group for the drive is 'optical' and that there exist group write permissions? Post the output of ls -l /dev/sr0
After you added your user to the 'optical' group, did you log out and log back in? As a sanity check, what is the output of groups ?

pavlosdec · 2020-11-08 15:50:46

I did all that but the issue is this
The problem is the latest version of cdrtools. When I downgraded to the previous version there was no issue.
So, I think I will be ignoring the package's latest version for now...

P.S. Should I mark this as SOLVED??? (kinda...)

Last edited by pavlosdec (2020-11-08 15:51:40)

mpan · 2020-11-08 15:54:07

ewaller:
Even if one is in optical, it won’t work. cdrecord requires various other privileges — not merely access to the device file.

Just to make it clear:

 $ ls -l /dev/sr0
brw-rw----+ 1 root optical 11, 0 Nov  3 01:44 /dev/sr0

 $ groups
lp http video audio optical storage scanner users wireshark data500 beepers

ewaller · 2020-11-08 16:12:24

Okay, good to know. I always try for the low hanging fruit first

Spinnekop · 2020-11-08 16:39:56

I had this problem a while back and discovered on a working machine that the permission for /usr/bin/cdrecord was

-rws--s--x 1 root root 574448 Jul 7 16:35 cdrecord

once I did a "sudo chmod u+s cdrecord" on the non-working machine it worked. I think I may have done g+s as well but that probably wasn't necessary.

If I was clever I might be able to tell you why it worked...

Last edited by Spinnekop (2020-11-08 16:44:58)

mpan · 2020-11-09 05:23:35

ewaller wrote:

Okay, good to know. I always try for the low hanging fruit first ;)

No need to feel bad about it. I find the “just setuid the binary” solution to be dirty and suggest it only as a temporary way to circumvent the problem until the package is fixed. Ideally, as suggested by the cdrtools page and 3.01 release notes, that should be solved using capabilities.

I would probably ask the same question as you did, if not that this is an n-th person who experiences the same problem (me included).

Spinnekop wrote:

I think I may have done g+s as well but that probably wasn't necessary.

To clarify: indeed it is not necessary. A process running as root is already a root. ;)

Last edited by mpan (2020-11-09 05:25:39)

scdbackup · 2020-11-09 08:16:12

Hi,

congrats to finding the solution.

As programmer of libburn i have to state that the view of cdrecord on
permissions is unfounded and gets deliberately enforced by a piece of
code in cdrecord, not by the Linux kernel.
With mere rw-permission to the device file it is possible to do all SCSI
transactions which are necessary for burning.

Everybody who has a text editor and a C compiler can get rid of the
demand for any superuser powers, be they coarse or finely granulated.

It is about 9 code lines (and 9 comment lines) in cdrecord.c :

        /*
         * Linux-2.6.8.1 did break the SCSI pass through kernel interface.
         * Since then, many SCSI commands are filtered away by the Linux kernel
         * if we do not have root privilleges. Since REZERO UNIT is in the list
         * of filtered SCSI commands, it is a good indicator on whether we run
         * with the needed privileges. Failing here is better than failing later
         * with e.g. vendor unique commands, where cdrecord would miss
         * functionality or fail completely after starting to write.
         */
        seterrno(0);
        scgp->silent++;
        code = rezero_unit(scgp); /* Not supported by some drives */
        scgp->silent--;
        err = geterrno();
        if (code < 0 && (err == EPERM || err == EACCES)) {
                linuxcheck();   /* For version 1.413 of cdrecord.c */
                scg_openerr("");
        }

Throw them out and be free.

Have a nice day

Thomas

pavlosdec · 2020-11-12 17:42:26

Solved by updating cdrtools to 3.02a09-4

mpan · 2020-11-13 04:23:47

scdbackup: don’t forget to remove the whole comment above, explaining why those lines are required for cdrecord to work properly. Though you may report that as a bug: if it is not needed, it may be removed upstream.

Last edited by mpan (2020-11-13 04:25:07)

Arch Linux

#1 2020-11-08 10:09:41

[SOLVED] Brasero won't write to disc because of permissions

#2 2020-11-08 10:14:52

Re: [SOLVED] Brasero won't write to disc because of permissions

#3 2020-11-08 11:32:11

Re: [SOLVED] Brasero won't write to disc because of permissions

#4 2020-11-08 11:36:23

Re: [SOLVED] Brasero won't write to disc because of permissions

#5 2020-11-08 15:16:44

Re: [SOLVED] Brasero won't write to disc because of permissions

#6 2020-11-08 15:50:46

Re: [SOLVED] Brasero won't write to disc because of permissions

#7 2020-11-08 15:54:07

Re: [SOLVED] Brasero won't write to disc because of permissions

#8 2020-11-08 16:12:24

Re: [SOLVED] Brasero won't write to disc because of permissions

#9 2020-11-08 16:39:56

Re: [SOLVED] Brasero won't write to disc because of permissions

#10 2020-11-09 05:23:35

Re: [SOLVED] Brasero won't write to disc because of permissions

#11 2020-11-09 08:16:12

Re: [SOLVED] Brasero won't write to disc because of permissions

#12 2020-11-12 17:42:26

Re: [SOLVED] Brasero won't write to disc because of permissions

#13 2020-11-13 04:23:47

Re: [SOLVED] Brasero won't write to disc because of permissions

Board footer