Thanks everyone for all the suggestions. I have eventually realised
that when the drive recently visited the daughter/partner's machine for
it's annual format/install, it had to be jumpered as master (sharing a
cable), but wasn't changed back when going back in this one (alone on
it's cable). And now I understand that this makes a big difference in
linux because hdc and hdd aren't the same thing. Stupid mistake that
hopefully I won't make again.
Cheers, Roger
Volker Kuhlmann wrote:
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
