K3B only recognises burner as ROOT

brundles · 06-07-2005, 04:24 AM

I'm hoping someone here can help as it's driving me round the bend!

Basically I've had problems getting K3B to recognise the burner in my PC (as an fyi, the burner is not the one that was there when SuSE was installed - not sure if that makes any difference). At a friends suggestion I tried firing K3B up as root as he thought it would make it do a rescan of the IDE bus. The root user recognised it straight away and configured it properly. Unfortunately logging out of root and back in as me and it's just the same as before

.

I'm pretty new to arguing with CD drives on Linux so if there is any info that would be useful, let me know.

fstab looks like this:

Code:

dev/hda6            /                    reiserfs   defaults              1 1
/dev/hda1            /windows/C           vfat     users,gid=users,umask=0002,iocharset=iso8859-1,codepage=437 0 0
/dev/hda2            /windows/D           ntfs       ro,users,gid=users,umask=0002,nls=iso8859-1 0 0
/dev/hda5            swap                 swap       pri=42                0 0
devpts               /dev/pts             devpts     mode=0620,gid=5       0 0
proc                 /proc                proc       defaults              0 0
usbdevfs             /proc/bus/usb        usbdevfs   noauto                0 0
/dev/cdrecorder      /media/cdrecorder    subfs      fs=cdfss,ro,procuid,nosuid,nodev,exec 0 0
/dev/cdrom           /media/cdrom         subfs      fs=cdfss,ro,procuid,nosuid,nodev,exec 0 0
/dev/dvd             /media/dvd           subfs      fs=cdfss,ro,procuid,nosuid,nodev,exec 0 0
/dev/dvdrecorder     /media/dvdrecorder   subfs      fs=cdfss,ro,procuid,nosuid,nodev,exec 0 0
/dev/fd0             /media/floppy        subfs      fs=floppyfss,procuid,nodev,nosuid,sync 0 0
usbfs                /proc/bus/usb        usbfs      noauto                0 0
/dev/hdb5            /shared120           vfat       users,owner,umask=000    0 0
/dev/hdb6            /data                vfat       users,owner,umask=000    0 0

mount returns this:

Code:

/dev/hda6 on / type reiserfs (rw)
proc on /proc type proc (rw)
tmpfs on /dev/shm type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/hda1 on /windows/C type vfat (rw,noexec,nosuid,nodev,gid=100,umask=0002,ioc
harset=iso8859-1,codepage=437)
/dev/hda2 on /windows/D type ntfs (ro,noexec,nosuid,nodev,gid=100,umask=0002,nls
=iso8859-1)
/dev/cdrecorder on /media/cdrecorder type subfs (ro,nosuid,nodev,fs=cdfss,procui
d)
/dev/hdc on /media/cdrom type subfs (ro,nosuid,nodev,fs=cdfss,procuid)
/dev/hdc on /media/dvd type subfs (ro,nosuid,nodev,fs=cdfss,procuid)
/dev/hdd on /media/dvdrecorder type subfs (ro,nosuid,nodev,fs=cdfss,procuid)
/dev/fd0 on /media/floppy type subfs (rw,nosuid,nodev,sync,fs=floppyfss,procuid)
/dev/hdb5 on /shared120 type vfat (rw,noexec,nosuid,nodev,umask=000)
/dev/hdb6 on /data type vfat (rw,noexec,nosuid,nodev,umask=000)

Thanks in advance,
Keith

oneandoneis2 · 06-07-2005, 04:53 AM

What are the access permissions on the actual device node? (The /dev entry)

brundles · 06-07-2005, 05:31 AM

Quote:

Originally posted by oneandoneis2
What are the access permissions on the actual device node? (The /dev entry)

A grep on the ls -l of /dev gives (among other things) this:

Code:

lrwxrwxrwx   1 root  root           3 2005-06-07 10:07 dvdrecorder -> hdd
brw-rw----   1 root  disk     22,  64 2004-10-02 09:38 hdd

The date stamp of today was when I tried using YAST to remove and re-add the driver entry from it's list of CD drives

Not sure if it helps, but I forgot this one earlier:

Code:

keith@brundles:~> cat /proc/sys/dev/cdrom/info
CD-ROM information, Id: cdrom.c 3.20 2003/12/17

drive name:             hdd     hdc
drive speed:            48      48
drive # of slots:       1       1
Can close tray:         1       1
Can open tray:          1       1
Can lock tray:          1       1
Can change speed:       1       1
Can select disk:        0       0
Can read multisession:  1       1
Can read MCN:           1       1
Reports media changed:  1       1
Can play audio:         1       1
Can write CD-R:         1       0
Can write CD-RW:        1       0
Can read DVD:           1       1
Can write DVD-R:        1       0
Can write DVD-RAM:      0       0
Can read MRW:           1       1
Can write MRW:          1       1
Can write RAM:          1       1

oneandoneis2 · 06-07-2005, 06:03 AM

Okay, is your user a member of the "disk" group?

adriaanbw · 06-07-2005, 06:03 AM

I had a problem with K3b the first time I used it where it was unable to write to the temporary directory.

Try creating a folder /tmp/kde-<yourusername> and ensure you have read/write permissions. This is something I had to do before I was able to use the program.

brundles · 06-07-2005, 06:41 AM

Quote:

Try creating a folder /tmp/kde-<yourusername> and ensure you have read/write permissions.

The folder already exists with a whole bunch of files in there - my user is the owner with full read/write permissions.

Quote:

Okay, is your user a member of the "disk" group?

Checked this and the answer is no. Adding me in via Yast doesn't seem to have made a difference - although I haven't logged out and back in again.

However...

I checked the permissions on the other drive (hdc) and it turns out that for whatever bizarre reason, my user is the owner (and only person with access to) that drive (this may also explain why I can't access files on that drive via SMB even though it shares the drive OK!).

As a quick and dirty test, a chown of hdd to my user gets things working properly.

Now onto the 'correct solution'. From a Linux/admin perspective, am I better changing access to these drives via user and group allocations (seems a bit long winded to me as every disk device is part of the disk group and you might not want everyone to have access to every disk) or via fstab and mount points? I'm thinking via fstab - in which case I should go properly learn about it!

oneandoneis2 · 06-07-2005, 08:13 AM

Both the fstab entries AND the user & group permissions have to be set properly for access to work.