tar: /dev/rmt/0m: Permission denied
Damadomu
I have a problem running "tar" to make a backup on a dat.
The OS is Solaris 8 installed on a SunFire 280R.
I have used this DAT every night (via cron) without any problem, but
the past Friday I needed to reconfigure the /dev and /devices
directories (with a "reboot -- -r") because I lost them (why ? I still
don't know)
Since then my tape stoped to work.
The command used is :
root : tar cvf /dev/rmt/0 dir1 dir2 dir3
tar: /dev/rmt/0: Permission denied
The "mt" response is :
root : mt -f /dev/rmt/0 status
HP DDS-4 DAT (Sun) tape drive:
sense key(0x7)= Write Protected residual= 0 retries= 0
file no= 0 block no= 0
but this is NOT true because the tape is not write protected.
The permissions are :
root : ls -las /dev/rmt/0
2 lrwxrwxrwx 1 root other 43 Sep 17 16:49 /dev/rmt/0
-> ../../devices/pci@8,700000/scsi@6,1/st@4,0:
root : ls -ld /devices \
/devices/pci@8,700000 \
/devices/pci@8,700000/scsi@6,1 \
/devices/pci@8,700000/scsi@6,1/st@4,0:
drwxr-xr-x 5 root sys 512 Sep 17 11:04 /devices
drwxr-xr-x 5 root sys 512 Sep 20 16:08
/devices/pci@8,700000
drwxr-xr-x 2 root sys 1024 Sep 17 17:31
/devices/pci@8,700000/scsi@6,1
cr-------- 1 root sys 33,267 Sep 17 17:31
/devices/pci@8,700000/scsi@6,1/st@4,0:
I tryed to "chmod 666" and "chmod 777" the device (.../st@4,0:) but
nothing happened. The same is when I tryed to "chmod 777" the
direcories...
I also tryed to "release" the device with "mt -f /dev/rmt/0 release"
and after this the status was :
HP DDS-4 DAT (Sun) tape drive:
sense key(0x0)= No Additional Sense residual= 0 retries= 0
file no= 0 block no= 0
but the tar's response was the same.
Any idea ?
I hope someone could help me.
Thank you in advance.
Ciao, Damadomu.
David Moscipan
> Hi all,
> I have a problem running "tar" to make a backup on a dat.
>
> The OS is Solaris 8 installed on a SunFire 280R.
> I have used this DAT every night (via cron) without any problem, but
> the past Friday I needed to reconfigure the /dev and /devices
> directories (with a "reboot -- -r") because I lost them (why ? I still
> don't know)
> Since then my tape stoped to work.
>
> The command used is :
>
> root : tar cvf /dev/rmt/0 dir1 dir2 dir3
> tar: /dev/rmt/0: Permission denied
>
>
> The "mt" response is :
>
> root : mt -f /dev/rmt/0 status
> HP DDS-4 DAT (Sun) tape drive:
> sense key(0x7)= Write Protected residual= 0 retries= 0
Damadomu,
Have you checked the tape's lock ? Is it write protected ?
Darren Dunham
> root : mt -f /dev/rmt/0 status
> HP DDS-4 DAT (Sun) tape drive:
> sense key(0x7)= Write Protected residual= 0 retries= 0
> file no= 0 block no= 0
> but this is NOT true because the tape is not write protected.
But that's what the drive is telling solaris. If there were a problem
with Solaris or the drivers, I would expect no communication at all, not
a specific problem like this.
Instead my guesses would be one of the following.
* the drive sensor for the write-protect switch has failed
* there's a dip switch set to make the drive read-only
* the volume has a problem that affects the write protect switch
* Improper type of tape in drive, making drive read-only
> I also tryed to "release" the device with "mt -f /dev/rmt/0 release"
Hmm. the drive wasn't reserved, so that shouldn't have done anything.
> and after this the status was :
> HP DDS-4 DAT (Sun) tape drive:
> sense key(0x0)= No Additional Sense residual= 0 retries= 0
> file no= 0 block no= 0
> but the tar's response was the same.
Really? If you ran a status immediately after, did it show
write-protected again?
--
Darren Dunham ddu...@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
Damadomu
> Have you checked the tape's lock ? Is it write protected ?
It is ABSOLUTELY NOT write protected :-(
Damadomu
Darren Dunham <ddu...@redwood.taos.com> wrote in message news:<QpD3d.21669$Gu2....@newssvr27.news.prodigy.com>...
> * the drive sensor for the write-protect switch has failed
I think not because I tryed to connect this drive to another SunFire
280R, created the tape devices and tryed to use it with the same tape
inside : it works (I need to make backups :-)
> * there's a dip switch set to make the drive read-only
Where ? In the computer ? This is an external drive connected to a
scsi port and the first thing I thought was that something went wrong
touching it (who ? not me !)... but this is not the case :-(
I disconnected it, cleaned the scsi plug, reconnected, cleaned the
tape head with a cleaning tape, but nothing happened.
> * the volume has a problem that affects the write protect switch
I used the same volume (not a similar, the same) with another computer
and it works.
> * Improper type of tape in drive, making drive read-only
The tape is of the same type I use every night (TDK-4mm-Data
Cartridge-DDS/90m) and I tryed more than one tape before asking help
:-(
> > HP DDS-4 DAT (Sun) tape drive:
> > sense key(0x0)= No Additional Sense residual= 0 retries= 0
> > file no= 0 block no= 0
>
> > but the tar's response was the same.
>
> Really? If you ran a status immediately after, did it show
> write-protected again?
"No Additional Sense" again.
And now the news :
As I already told you, I tryed to connect this external drive to
another computer and it works fine as I expected.
I also tryed to remove everything in /dev/rmt and every "st*"
occurrence in /etc/path_to_inst, executed "devfsadm -v" so now I have
some new links in /dev/rmt ... and this DAT is already write
protected.
I tryed ALL the /dev/rmt/* and the response is always the same.
Any other idea ?
Beardy
>
> And now the news :
> As I already told you, I tryed to connect this external drive to
> another computer and it works fine as I expected.
> I also tryed to remove everything in /dev/rmt and every "st*"
> occurrence in /etc/path_to_inst, executed "devfsadm -v" so now I have
> some new links in /dev/rmt ... and this DAT is already write
> protected.
> I tryed ALL the /dev/rmt/* and the response is always the same.
>
> Any other idea ?
No, but what happens if you just try "date > /dev/rmt/0"?
Could you also try "truss -af dd if=/etc/hosts of=/dev/rmt/0" and post
the results please?
Do you have another SCSI port on the system (or another SCSI card you
can install) which would give you an alternative SCSI path to the tape
drive?
Beardy.
Damadomu
> No, but what happens if you just try "date > /dev/rmt/0"?
root : date > /dev/rmt/0
ksh: /dev/rmt/0: cannot create
> Could you also try "truss -af dd if=/etc/hosts of=/dev/rmt/0" and post
> the results please?
---------------------------------------
28433: execve("/usr/bin/dd", 0xFFBEFC5C, 0xFFBEFC6C) argc = 3
28433: argv: dd if=/etc/hosts of=/dev/rmt/0
28433: mmap(0x00000000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_A
NON, -1, 0) = 0xFF3A0000
28433: resolvepath("/usr/lib/ld.so.1", "/usr/lib/ld.so.1", 1023) = 16
28433: open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
28433: stat("/usr/lib/libc.so.1", 0xFFBEF384) = 0
28433: open("/usr/lib/libc.so.1", O_RDONLY) = 3
28433: fstat(3, 0xFFBEF384) = 0
28433: mmap(0x00000000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xFF390
000
28433: mmap(0x00000000, 802816, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xFF2
80000
28433: mmap(0xFF33C000, 24748, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_
FIXED, 3, 704512) = 0xFF33C000
28433: munmap(0xFF32C000, 65536) = 0
28433: memcntl(0xFF280000, 113448, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
28433: close(3) = 0
28433: stat("/usr/lib/libdl.so.1", 0xFFBEF384) = 0
28433: open("/usr/lib/libdl.so.1", O_RDONLY) = 3
28433: fstat(3, 0xFFBEF384) = 0
28433: mmap(0xFF390000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0)
= 0xFF390000
28433: close(3) = 0
28433: stat("/usr/platform/SUNW,Sun-Fire-280R/lib/libc_psr.so.1", 0xFFBEF214) =
0
28433: open("/usr/platform/SUNW,Sun-Fire-280R/lib/libc_psr.so.1", O_RDONLY) = 3
28433: fstat(3, 0xFFBEF214) = 0
28433: mmap(0x00000000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xFF380
000
28433: close(3) = 0
28433: brk(0x00023F68) = 0
28433: brk(0x00025F68) = 0
28433: stat("/usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2", 0xFFBEEBDC)
= 0
28433: open("/usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2", O_RDONLY) =
3
28433: fstat(3, 0xFFBEEBDC) = 0
28433: mmap(0x00000000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xFF370
000
28433: mmap(0x00000000, 90112, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xFF35
0000
28433: mmap(0xFF362000, 10278, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_
FIXED, 3, 8192) = 0xFF362000
28433: munmap(0xFF354000, 57344) = 0
28433: memcntl(0xFF350000, 8412, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
28433: close(3) = 0
28433: munmap(0xFF370000, 8192) = 0
28433: open64("/etc/hosts", O_RDONLY) = 3
28433: creat64("/dev/rmt/0", 0666) Err#13 EACCES
dd: 28433: write(2, " d d : ", 4) = 4
/dev/rmt/028433: write(2, " / d e v / r m t / 0", 10) = 10
: 28433: write(2, " : ", 2) = 2
open28433: write(2, " o p e n", 4) = 4
: 28433: write(2, " : ", 2) = 2
Permission denied28433: write(2, " P e r m i s s i o n d".., 17) = 17
28433: write(2, "\n", 1) = 1
28433: llseek(0, 0, SEEK_CUR) = 6810
28433: _exit(2)
---------------------------------------
> Do you have another SCSI port on the system (or another SCSI card you
> can install) which would give you an alternative SCSI path to the tape
> drive?
Unfortunately not.
The SunFire 280R has only one external SCSi port.
> Beardy.
Thank you for your help.
I apreciate it a lot.
Ciao, Damadomu.
Laurenz Albe
>> Could you also try "truss -af dd if=/etc/hosts of=/dev/rmt/0" and post
>> the results please?
>
*grin* What do you get if you 'ls -l /dev/rmt/0' ?
Laurenz Albe
Beardy
Laurenz, please let us know the reason for the grin... What do you
expect to see?
Beardy
Damadomu, could you please try to boot the system into single-user mode
"boot -s" and try the same truss and/or tar again please? I suspect that
it may work...
Beardy.
Laurenz Albe
> Laurenz Albe wrote:
>> *grin* What do you get if you 'ls -l /dev/rmt/0' ?
>
> expect to see?
Sorry, that was bull. It's not a file permission problem.
Laurenz Albe
Beardy
No worries. We all trip periodically ;-)
Damadomu
> 28433: creat64("/dev/rmt/0", 0666) Err#13 EACCES
>
> *grin* What do you get if you 'ls -l /dev/rmt/0' ?
lrwxrwxrwx 1 root other 43 Sep 20 17:38 /dev/rmt/0 ->
../../devices/pci@8,700000/scsi@6,1/st@4,0:
root : ls -l /dev/rmt/0
lrwxrwxrwx 1 root other 43 Sep 20 17:38 /dev/rmt/0 ->
../../devices/pci@8,700000/scsi@6,1/st@4,0:
root : ls -l /devices/pci@8,700000/scsi@6,1/st@4,0:
cr-------- 1 root sys 33,267 Sep 17 17:31
/devices/pci@8,700000/scsi@6,1/st@4,0:
Sorry, this is THE SAME result I can get on the other Solaris and
there this drive with the same tape inside, works :-)
> Laurenz Albe
Ciao, Damadomu.
Bruce Esquibel
: root : ls -l /devices/pci@8,700000/scsi@6,1/st@4,0:
: cr-------- 1 root sys 33,267 Sep 17 17:31
: /devices/pci@8,700000/scsi@6,1/st@4,0:
: Sorry, this is THE SAME result I can get on the other Solaris and
: there this drive with the same tape inside, works :-)
Rather odd, just checked my machines with tape drives and everything for it
shows up as...
crw-rw-rw- 1 root sys 33,129 Sep 3 10:27 st@5,0:
including the options (c, cn). Why yours is set to read-only-root is beyond
me but still seems to be the problem.
-bruce
b...@ripco.com
Damadomu
> Damadomu, could you please try to boot the system into single-user mode
> "boot -s" and try the same truss and/or tar again please? I suspect that
> it may work...
In single-user mode both don't work. Same result : permission denied.
Something has changed : now, re-booted in multi-user mode, if I use
tar in a shell-script via "crontab" (my backup script), it WORKS and
if I try to use a tar via prompt it does not work :-(
The file and link permissions are not changed.
This is the first time I have this kind of problem !!!
> Beardy.
Ciao, Damadomu.
Beardy
This is madness. Could you please post the output of the env command,
and then the env command from within an atjob, with:
# at now + 1
env
<CONTROL-D>
This will mail you the output, so pick it up with mailx, and post it
here as well please.
Thanks.
Damadomu
> This is madness. Could you please post the output of the env command,
> and then the env command from within an atjob, with:
root : env
EDITOR=/usr/bin/vi
HOME=/
HZ=100
LOGNAME=root
MAIL=/var/mail/root
PATH=/usr/sbin:/usr/bin:/usr/ccs/bin:/usr/xpg4/bin:/opt/Acrobat4/bin:/usr/local/bin
PS1=root :
SHELL=/sbin/sh
TERM=vt100
TMOUT=750
TZ=MET
> # at now + 1
> env
> <CONTROL-D>
_=/usr/bin/env
MANPATH=/usr/openwin/share/man:/usr/share/man:/usr/dt/share/man:/usr/demo/SOUND/man:/usr/demo/link_audit/man:/usr/java1.2/man:/usr/perl5/man:/usr/apache/man:/usr/j2se/man:/opt/SUNWconn/ge/man:/opt/SUNWconn/man:/opt/SUNWrtvc/man
HZ=100
LC_MONETARY=en_US.ISO8859-1
LC_TIME=en_US.ISO8859-1
PATH=/usr/sbin:/usr/bin:/usr/ccs/bin:/usr/xpg4/bin:/opt/Acrobat4/bin:/usr/local/bin
EDITOR=/usr/bin/vi
LOGNAME=root
MAIL=/var/mail/root
PS1=root :
LC_MESSAGES=C
LC_CTYPE=en_US.ISO8859-1
SHELL=/usr/bin/ksh
TMOUT=750
HOME=/
LC_COLLATE=en_US.ISO8859-1
LC_NUMERIC=en_US.ISO8859-1
TERM=vt100
PWD=/tmp
TZ=MET
A__z="*TMOUT
My environment has been the same since a long long time (months).
I did not change my crontab since months.
I use tar via prompt every day.
I use tar via crontab every night.
I'm the only one who can log in as root user.
I don't think the problem could be in the shell used (sh instead of
ksh)
Thank you for your help !!!
Ciao, Damadomu.
Beardy
Damadomu, if your evening backups via cron are working fine reliably
(and you have done a successful restore of the very last file on an
archive (make it just a test file, but make sure its at the end of the
archive), could you please try a simple tar to a tape within an atjob,
and see if it works (try a few times) without error. If it does work,
and your command-line tar still fails (could you also please check
/var/adm/messages for any SCSI errors?), then you may just have to do
all your ad hoc archives in atjobs :-( I am completely befuddled.
Apols.
Beardy.
all mail refused
> archives in atjobs :-( I am completely befuddled.
You didn't make anything of the different SHELL variable ?
No chance at all there's a silly alias (or function) somewhere ?
Does the tar have the correct md5 ?
--
Elvis Notargiacomo master AT barefaced DOT cheek
http://www.notatla.org.uk/goen/
My energy-saving light bulb caught fire. Now I know
the NSA are beaming microwaves at my flat.
Beardy
> In article <41547469$0$69726$ed26...@ptn-nntp-reader01.plus.net>, Beardy wrote:
>
>
>>archives in atjobs :-( I am completely befuddled.
>
>
> You didn't make anything of the different SHELL variable ?
> No chance at all there's a silly alias (or function) somewhere ?
>
> Does the tar have the correct md5 ?
>
Given the fact that the earlier truss output shows EACCES on a creat64()
call, I suspect that the shell is irrelevant, and the fact that now tar
works from within a cronjob, but not from the command line, and that dd
also fails, and that he alone has root access, nothing really fits to
the cause of the error :-(
Damadomu
> Damadomu, if your evening backups via cron are working fine reliably
> (and you have done a successful restore of the very last file on an
> archive (make it just a test file, but make sure its at the end of the
> archive), could you please try a simple tar to a tape within an atjob,
> and see if it works (try a few times) without error. If it does work,
> and your command-line tar still fails (could you also please check
> /var/adm/messages for any SCSI errors?), then you may just have to do
> all your ad hoc archives in atjobs :-( I am completely befuddled.
:-(
Via cron it works, via atjob it works and yes, I did recover more than
one time more than one file.
In /var/adm/messages there are not SCSI errors !!!
So... thank you all for the help... this problem will be written in
the book "Strange things of Solaris" :-(
I think I have to make my (centralised) backups on another computer
:-(
This is not the best for me but it is a solution.
Ciao, Damadomu.
Beardy
> Beardy <bea...@beardy.net> wrote in message news:<41547469$0$69726$ed26...@ptn-nntp-reader01.plus.net>...
>
>>Damadomu, if your evening backups via cron are working fine reliably
>>(and you have done a successful restore of the very last file on an
>>archive (make it just a test file, but make sure its at the end of the
>>archive), could you please try a simple tar to a tape within an atjob,
>>and see if it works (try a few times) without error. If it does work,
>>and your command-line tar still fails (could you also please check
>>/var/adm/messages for any SCSI errors?), then you may just have to do
>>all your ad hoc archives in atjobs :-( I am completely befuddled.
>
>
> :-(
> Via cron it works, via atjob it works and yes, I did recover more than
> one time more than one file.
That's reassuring at least.
> In /var/adm/messages there are not SCSI errors !!!
That's reassuring at least ;-)
> So... thank you all for the help... this problem will be written in
> the book "Strange things of Solaris" :-(
Apols for not solving the problem.
> I think I have to make my (centralised) backups on another computer
> :-(
Many companies have centralised backup strategies on a backup server via
TSM, ufsdump and the like.
> This is not the best for me but it is a solution.
>
> Ciao, Damadomu.
Remember to update your disaster-recovery docs accordingly ;-)
Beardy.
