Bug 42881 - scsi tape not detecteda lthough works with tar alone
Summary: scsi tape not detecteda lthough works with tar alone
Status: RESOLVED WORKSFORME
Alias: None
Product: kdat
Classification: Miscellaneous
Component: general (show other bugs)
Version: 2.0.1
Platform: RedHat Enterprise Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Larry Widman
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-05-21 15:03 UTC by laxkde
Modified: 2008-02-15 04:05 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description laxkde 2002-05-21 14:48:13 UTC
(*** This bug was imported into bugs.kde.org ***)

Package:           kdat
Version:           2.0.1 (using KDE 3.0.0 )
Severity:          normal
Installed from:    RedHat RPMs
Compiler:          gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)
OS:                Linux (i686) release 2.4.18-4
OS/Compiler notes: 

My tape device is on /dev/st0 and is properly accessible through tar. KDAT does not seem to detect the tape inside it. Have very few options to debug this any further.

Thanks

(Submitted via bugs.kde.org)
(Called from KBugReport dialog. Fields KDE Version manually changed)
Comment 1 Terry Coles 2002-11-24 19:54:58 UTC
This bug has arisen 5 times before according to the bug list, (Bug numbers 
1167, 1681, 2444, 2678, 24913 as well as this one).  Each time, the 
bug has been reported resolved, but each time it has recurred. 
 
The problem is that when a tape is in the drive, KDAT reports a mount error: 
 
	'There appears to be no tape in the drive /dev/nst0' 
 
There is of course and until now, I hadn't been able to overcome this. 
 
I've been trying to get KDAT to work ever since I first started playing with 
Linux (about 2 years now).  I've tried everything I could think of, including 
running KDAT as root.  I aways got the same result.  When I checked the bug 
lists, I saw that there were previous bugs reporting this problem, so waited 
and 
 
 
hoped for a fix (and went back to mt and tar). 
 
Recently, the subject of KDAT arose again and a couple of us on our local LUG  
mailing list went to town on it.  What I did notice today was that /dev/nst0 
was 
a member of group 'disk': 
 
terry@silver:/dev> ls -la /dev/nst0 
crw-rw----    1 root     disk       9, 128 2002-09-09 21:24 /dev/nst0 
 
User 'terry' wasn't a member of group disk, so I added it to the account. 
KDAT now works perfectly!  Why should that be!  I've always thought that user 
root could do anything, so when KDAT originally refused to work when I logged 
in 
as root, I didn't pursue permissions as a possible cause of the problem. 
 
So, in summary, I can't get it to work when I log in as root, but I can if I 
log  
 
 
in as me, providing that I'm a member of the group that my tape device is (eg 
/dev/nst0).  It will also work, for me, if the permissions on /dev/nst0 are  
opened right up, but it won't work for root whatever I do.  This is a problem,  
because I cannot backup anything owned by root, unless I first create a file 
that can be read by terry.  (I could also create a backup user, but that seems 
to be the wrong thing to do.) 
 
If this is indeed a bug, hopefully this report will help get it sorted.  If in 
fact its just a configuration problem, can I suggest that the Help provides a 
bit of guidance in this area and perhaps another update to the error message 
to 
point the user at the appropriate configuation. 
Comment 2 kdat 2002-11-24 22:36:24 UTC
Subject:  scsi tape not detected although works with tar alone

I am the current maintainer of kdat, having inherited it about the
time that KDE 3.0 came out.  It is very well written: I can't take
credit for that.  It compiles and runs under KDE 3.0: I can take
credit for that.

Many thanks to Terry Coles for a scholarly and careful approach to
the "no tape" problem.  All of the previous cases seem to have
responded simply to naming the tape device correctly.  Most people
use tape drive /dev/st0-/dev/nst0, while the default for kdat was
and is /dev/tape.  The permissions problem appears to be a new one.

I can't explain why there is a problem.  I routinely run kdat as
root specifically to be able to do a complete backup of the selected
files/directories. 

> I've always thought that user root could do anything,

Yup, I always thought so too.  Perhaps someone wiser can explain the
discrepancy.  Until then, Terry's suggestion stands and I will add
it to the Help text (when I get around to revising it) and to the
error message.

Please keep me posted of any other problems with kdat.  I don't have
a lot of time to work at it, but it's good to have a list of things
to work on when time does become available.

Comment 3 laxkde 2002-11-25 04:47:23 UTC
I found a work around this problem. I "manually" mount the tape using 
mt load
before calling kdat with (I disbaled automatic load on start - just to be sure)
kdat &
This seems to allow kdat to work. Unfortunately, it ONLY works for root!

Hope this helps
Comment 4 Terry Coles 2002-11-29 21:40:26 UTC
I tried the mt load workround; unfortunately there seems to be multiple versions of mt around.  I have GNU Version 2.5 (out of the box from SuSE 8.1).  This does not support 'load'.  Presumably other versions do.  I don't suppose KDAT is relying on mt load at any point.... ? 
Comment 5 laxkde 2002-11-29 22:04:07 UTC
I am using mt that came with RedHat (current upgrade 8). It identifies itself 
as "mt-st v. 0.7". Note that I can only use it while log-in as root (su). It 
seems to use the device /dev/tape, but you can override the device with -f.

Hope this helps
Comment 6 Simon Parsons 2002-12-11 18:10:32 UTC
I have the same problem with KDAT 2.0.1 not detecting the tape (the drive is 
/dev/st0 and set as such in options). 
 
Actually, I don't think it's actually TRYING to detect the tape. 
A workaround that works for me is to select "Format" and then bomb out when 
the "All data currently on the tape will be lost. Are you sure you want to 
continue?" prompt comes up. KDAT then recognises the tape. Cool. 
I'm running it as a normal user, so you don't need rootly powers for this one. 
 
Looks like whatever it does before deciding to do some formatting is what it 
should do when it tries to detect a tape. ;-) 
 
Simon 
Comment 7 George Goldberg 2007-12-18 04:58:30 UTC
Is this bug still present in a recent version of KDE, such as 3.5.8 or KDE 4 RC2?
Comment 8 George Goldberg 2008-02-15 04:05:38 UTC
Closing due to no response. Please reopen if this bug can be reproduced with KDE >= 4.0.1