I never quite understood this, but I need read/write permissions to /dev/sg0 (which refers to my hard disc) as user, to burn CDs with cdrecord/k3b. dmesg: ----- sd 0:0:0:0: Attached scsi disk sda sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray sr 1:0:0:0: Attached scsi CD-ROM sr0 sd 0:0:0:0: Attached scsi generic sg0 type 0 sr 1:0:0:0: Attached scsi generic sg1 type 5 /dev looks like: ---------------- # ls -al /dev/sg* crw-rw---- 1 root root 21, 0 Dec 19 2005 /dev/sg0 crw-rw---- 1 root cdrom 21, 1 Dec 19 2005 /dev/sg1 # ls -al /dev/sr* brw-rw---- 1 root cdrom 11, 0 Dec 19 2005 /dev/sr0 cdrecord error log: ------------------ scsidev: '1,0,0' scsibus: 1 target: 0 lun: 0 /usr/bin/cdrecord: Permission denied. Cannot open '/dev/sg0'. Cannot open SCSI driver. When I change the group of /dev/sg0 to e.g. cdrom (in which my user is included) everything works as expected. So please change the permissions to /dev/sg0 to something resonable with udev. Thanks in advance!
(In reply to comment #0) > When I change the group of /dev/sg0 to e.g. cdrom (in which my user is > included) everything works as expected. So please change the permissions to > /dev/sg0 to something resonable with udev. Thanks in advance! What do you mean reasonable? root:root is perfectly fine for hard drives. Either incorrect k3b setup or k3b bug, there's nothing wrong with permissions set by udev.
(In reply to comment #1) > What do you mean reasonable? root:root is perfectly fine for hard drives. > Either incorrect k3b setup or k3b bug, there's nothing wrong with permissions > set by udev. For hard drives yes, but for the generetic device that belongs to the hard drive, too? The "reasonable" wasn't meent to be offensive but I wanted to point out, that my approach (the cdrom group) is not a clean solution of cause and I want to leave the decision how to fix this to people how know more about the topic. It's not a KDE problem I would say, cause it's cdrecord that complains. And yes, cdrecord often caused problems cause the kernel devels and the cdrecord devel don't like to work together I think. But how else but in changing the device permissions should we solve this problem? Remember that cdrecord doesn't work anymore with suid. If you are on an IDE system and you are able to burn as user, you might give me some infos about your system setup. Maybe it's SATA related? OK, I hope we can find a solution that lets non-root users burn CDs without opening huge securety issues.
(In reply to comment #2) > For hard drives yes, but for the generetic device that belongs to the hard > drive, too? > > The "reasonable" wasn't meent to be offensive but I wanted to point out, that > my approach (the cdrom group) is not a clean solution of cause and I want to > leave the decision how to fix this to people how know more about the topic. I really don't see how is this an udev issue: crw-rw---- 1 root root 21, 0 Dec 19 2005 /dev/sg0 ^^^ is a hard drive, permissions correct; crw-rw---- 1 root cdrom 21, 1 Dec 19 2005 /dev/sg1 # ls -al /dev/sr* brw-rw---- 1 root cdrom 11, 0 Dec 19 2005 /dev/sr0 are cdrom/cd writer devices, again permissions are correct. Sorry, but cdrecord/k3b/whatever being stupid and wanting to burn to hard drive instead of CD burner is anything but udev bug.
OK, then it is not an udev issue - but it is still an issue :-( Can we leave this bug open and assign it to cdrecord or how can we deal with the problem? I had a little discussion with another Dell Inspiron 6000 owner in the forum: http://forums.gentoo.org/viewtopic-t-397496-highlight-.html ###### Here is a short summary of our observations: CinzC wrote: Something I've wondered for long: when I try to burn a CD under Gnome with Nautilus I always had to allow write access on /dev/sg0 although the CD writer is attached to /dev/sr0. What is really wierd is that the (SATA) hard disk is attached to /dev/sg0 and the CD writer is attached to /dev/sg1. Me wrote: What about the following test configuration: deleting /dev/sg0 and creating a symlink to /dev/sg1 instead. When burning still works then cdrecord is realy confused with the scsi busses and doesn't need access to the hard disk scsi bus. If not then this access is truely needed and permissions should be handled "correctly" by udev. VinzC wrote: I don't believe this will work in fact - though I'm curious giving it a try. I suspect cdrecord looks for a SCSI device capable of burning. And remember we checked SCSI CDROM support in the kernel although the CDROM device is actually IDE, connected to a SATA controller. Hence cdrecord uses sg0 instead of sg1. This is my feeling rather than an actual observation. Things might be more complicated than expected in fact. Or I haven't understood anything, which is also quite possible :-). Me wrote: It appears that you are right. Indead there is no access to the scsi bus for the hd needed - the linking stuff described above works perfectly well. Even stranger it works entirely without /dev/sg0 (delete it) ... So it looks like it is a cdrecord problem but I do not realy understand why it insists on using sg0 and sg1 ... What's the next step? Changing my bug report to be against cdrecord (which is a dead project)? Hopefully the Gentoo devs can fix this! ######## End of forum discussion summary OK, my conclusion is that cdrecord needs rw permissions for the sgX device that belongs to the cdrecorder and that this sgX is created with the proper permissions by udev. But cdrecord is to silly to distinguish between the sgX from the cdrecorder and the sgX from my harddisk. The sgX from harddisk cames first in the naming sceme (sg0) and has permissions that are typical for HDs but not suffisant for cdburning. Now cdrecord takes this first sgX as the one it needs for burning and complains about wrong permissions. Question here: is the sgX for harddisks neeeded at all in the system or is it a fault that it is created? When I delete sg0 (sgX for the hd) then cdrecord works as expected - I guess it then finds sg1 finally which is sgX for the cdrecorder. Hope that helps somehow.
Obviously not a KDE issue.
Can you give an example how you call cdrecord?
Hi, I'm also affected by this problem on a machine with real SCSI-devices. Here's what I found out: Using cdrecord the way its author prefers it doesn't work as user: > cdrecord -atip -dev=0,4,0 Cdrecord-Clone 2.01.01a01 (i686-pc-linux-gnu) Copyright (C) 1995-2004 J
Hi, I'm also affected by this problem on a machine with real SCSI-devices. Here's what I found out: Using cdrecord the way its author prefers it doesn't work as user: > cdrecord -atip -dev=0,4,0 Cdrecord-Clone 2.01.01a01 (i686-pc-linux-gnu) Copyright (C) 1995-2004 Jörg Schilling cdrecord: Warning: Running on Linux-2.6.13.5-mh2 cdrecord: There are unsettled issues with Linux-2.5 and newer. cdrecord: If you have unexpected problems, please try Linux-2.4 or Solaris. TOC Type: 1 = CD-ROM scsidev: '0,4,0' scsibus: 0 target: 4 lun: 0 cdrecord: Permission denied. Cannot open '/dev/sg0'. Cannot open SCSI driver. cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you are root. cdrecord: For possible transport specifiers try 'cdrecord dev=help'. But using -dev=/dev/sg3 instead of -dev=0,4,0 works as user: > cdrecord -atip -dev=/dev/sg3 Cdrecord-Clone 2.01.01a01 (i686-pc-linux-gnu) Copyright (C) 1995-2004 Jörg Schilling cdrecord: Warning: Running on Linux-2.6.13.5-mh2 cdrecord: There are unsettled issues with Linux-2.5 and newer. cdrecord: If you have unexpected problems, please try Linux-2.4 or Solaris. TOC Type: 1 = CD-ROM scsidev: '/dev/cdrecorder' devname: '/dev/cdrecorder' scsibus: -2 target: -2 lun: -2 Warning: Open by 'devname' is unintentional and not supported. Linux sg driver version: 3.5.33 Using libscg version 'schily-0.8'. SCSI buffer size: 64512 atapi: 0 Device type : Removable CD-ROM Version : 2 Response Format: 2 Capabilities : SYNC LINKED Vendor_info : 'PLEXTOR ' Identifikation : 'CD-R PX-W124TS' Revision : '1.07' Device seems to be: Generic mmc CD-RW. Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags : MMC SWABAUDIO Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R Drive buf size : 2373168 = 2317 KB Drive DMA Speed: 16209 kB/s 92x CD 11x DVD Current Secsize: 2048 ATIP info from disk: Indicated writing power: 4 Is not unrestricted Is not erasable Disk sub type: Medium Type A, high Beta category (A+) (3) ATIP start of lead in: -11077 (97:34/23) ATIP start of lead out: 359848 (79:59/73) Disk type: Long strategy type (Cyanine, AZO or similar) Manuf. index: 11 Manufacturer: Mitsubishi Chemical Corporation Now what does k3b? I think it's using the -dev=x,y,z method to specify the device as the errormessage given by cdrecord thru k3b is the same as using cdrecord -dev=0,4,0 on the commandline... Cheers Poly
Additional information: the /dev/cdrecorder comes from a custom udev-rule I've written: BUS=="scsi", KERNEL=="sg[0-9]*", SYSFS{model}=="CD-R PX-W124TS", GROUP:="cdrw", SYMLINK="scd%n cdrecorder" Poly
still have the same problem with alpha 07 ?
Yes, the error is still present in alpha07.
I'm also getting an issue where K3b complains of cdrecord not running as root. I tried dropping back to cdrecord itself, but it's throwing up an error about permissions when I try to "cdrecord -scanbus": Cdrecord-Clone 2.01.01a06 (i686-pc-linux-gnu) Copyright (C) 1995-2006 J
I'm also getting an issue where K3b complains of cdrecord not running as root. I tried dropping back to cdrecord itself, but it's throwing up an error about permissions when I try to "cdrecord -scanbus": Cdrecord-Clone 2.01.01a06 (i686-pc-linux-gnu) Copyright (C) 1995-2006 Jörg Schilling cdrecord: Permission denied. Cannot open '/dev/sg0'. Cannot open SCSI driver. cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you are root. cdrecord: For possible transport specifiers try 'cdrecord dev=help'. (My writer is a Plextor PX-716A, on Secondary IDE/Slave. I don't have any SCSI devices or controllers attached to my computer.)
(In reply to comment #11) > permissions when I try to "cdrecord -scanbus": You have to name the bus it should scan. Try cdrecord dev=ATA -scanbus
(In reply to comment #12) > (In reply to comment #11) > > permissions when I try to "cdrecord -scanbus": > > You have to name the bus it should scan. Try cdrecord dev=ATA -scanbus > Thanks, that scanned my writer correctly. Also gave me a comedy warning: "Using badly designed ATAPI via /ev/hd* interface."
app-cdr/cdrkit suffers from the same problem. As it seems to be more likely that rather the cdrkit-devs would fix this instead of J
app-cdr/cdrkit suffers from the same problem. As it seems to be more likely that rather the cdrkit-devs would fix this instead of Jörg "I-am-the-ultimate-unfailable-god-of-cdburning-apps-and-you-have-no-clue-about-anything-in-life" Schilling, maybe we should report this bug to the cdrkit-devs? Cheers Poly-C
I have a similar problem, if not the same. This works for me: http://qa.mandriva.com/twiki/bin/view/Main/MandrivaLinux2006ReleaseNotes#Plextor_burner Maybe not the best solution.
(In reply to comment #15) > I have a similar problem, if not the same. This works for me: > http://qa.mandriva.com/twiki/bin/view/Main/MandrivaLinux2006ReleaseNotes#Plextor_burner > > Maybe not the best solution. Well. I don't want to install cdrtools with suid-root by default. But I think about adding an einfo-note to the ebuild.
I think this bug has been resolved in the latest cdrkit-version. Can you test please?
Dear Lars, I apprechiate to work that is done both in cdrkit upstream and in your efforts to get in into portage. I'll try to get a cdrkit setting up and running here in the next ~ 2 weeks but to be honest I am a little concerned whether it is ready for prime time yet. I usualy prefer the stable portage tree ;) (I read your post on the planet one minute ago) My question is what do you mean by latest cdrkit? Is 1.0 enough or do we need 1.1?
Hello Lars, I'll give cdrkit-1.0 a try as soon as I'm at my SCSI machine again. Cheers Poly-C
I can confirm that using cdrkit instead of cdrtools fixes this for me. Thanks.
(In reply to comment #18) > My question is what do you mean by latest cdrkit? Is 1.0 enough or do we need 1.1? Please test cdrkit-1.0 first, as this one will be stabilised soon (this month). If it works, report back. Otherwise test cdrkit-1.1.0 and report the status.
(In reply to comment #20) > I can confirm that using cdrkit instead of cdrtools fixes this for me. Thanks. Which version of cdrkit?
>Which version of cdrkit? cdrkit-1.0 at first. cdrkit-1.1.0 now. Both seem to be working fine with regard to the permissions problem.
HI, the same here. Both, version 1.0 and version 1.1.0 are working perfectly with regard to the permission problem. I did several testburns on my Plextor PX-W124TS with both versions and all succeeded. Thanks for your work on this Lars... Cheers Poly-C
app-cdr/cdrkit doesn't have this problem as some of us here already told. How about closing this bug with recommendation to use cdrkit instead of cdrtools?
cdrkit-1.1.2 is stable now, use it.
*** Bug 187056 has been marked as a duplicate of this bug. ***
The problem with cdrecord is now resolved with the upgrade to wodim. But there is still the same problem with cdrdao...
*** Bug 195546 has been marked as a duplicate of this bug. ***
*** Bug 198371 has been marked as a duplicate of this bug. ***
*** Bug 204982 has been marked as a duplicate of this bug. ***
Reopening this bug, given that cdrkit is apparently in low maintenance mode, according to upstream activity and also using cdrkit doesn't fix cdrtools issues.
(In reply to comment #35) > Reopening this bug, given that cdrkit is apparently in low maintenance mode, > according to upstream activity and also using cdrkit doesn't fix cdrtools > issues. I really don't see what you are expecting here?! Jörg Schilling refuses to fix his stuff, blames kernel developers, his "fix" being "install cdrecord suid-root" (which is completely unneeded as cdrkit proves) - and instead of fixing a blatant bug in the product he's bashing distros that fix his buggy code with friendly notes about "bastardized and defective variants". http://cdrecord.berlios.de/private/cdrecord.html
Jörg Schilling is indeed a problematic guy, but that doesn't fix that people use cdrtools, Jakub. And at the pace cdrkit is moving, don't expect that to change.