> Sounds like you have a permission problem. So tell us what the ownership > & permissions are on the device and mount point.
No, this is not really relevant on SuSE. Sorry I haven't followed this thread closely, but there's some silly problem in there. From your kernel version I deduce you're on SuSE 9.1. Permission on the device are automatically configured for every graphical login: perm 600, ownership the logged in user. The second person who logs in graphically gets no access - there isn't really a better way of doing it. By default, users logged in via consoles or ssh get no access either. There is no way to tell in advance how you'd want it, if you want to change it, change the resmgr configuration. If you manually change permissions on the mount point, it'll last until next login/logout. Permissions on the mount point are likewise irrelevant, as by default subfs (an automounter) is already mounted on the mount point. When you insert a disk, the automounter will examine it, and then on the fly mount it when you access it (eg ls), and immediately unmount it when ls is finished. I'm saying this because it can cause some unexpected behaviour with find, du, and df if you're unaware of it. By default, subfs checks for the filesystems udf and iso9660. If you need others, change the line in /ets/fstab (after reading up on subfs). Btw, on SuSE you access cdrecord devices with /dev/devicename, at least since 9.2, though it's possible there's a problem with that on 9.1 still. It's not possible that k3b has the problem you describe, people would have stampeded SuSE headquarters before now. Also, forget about updating the kernel to a vanilla one on any SuSE system unless you a) know how to compile and install kernels, b) are able to deal with the general system breakage which this will cause afterwards. My suggestions would be: * DO make sure you have installed the latest fixes with YOU. * Check there's a symlink /dev/cdrecorder (or something like it) pointing to the actual device (hdd or whatever). You should be able to recreate this in yast under optical drive config. * Check subfs is running on the mount point. Should read something like /dev/hdb on /media/dvd type subfs (ro,nosuid,nodev,fs=iso9660:udf:ext2) * I assume you have already checked somehow that the drive itself is in working condition. If so, swapping in another drive won't solve anything. * Did you fiddle with the system? What did you do? Does this give a hint on why you might have broken cd burning? * If you want to test whether your box reads anything from the media, use dd. I've said this so often now, it's becoming boring. If you want to eliminate permission problems, run dd as root. HTH, Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
