Operating System - HP-UX
1833757 Members
2347 Online
110063 Solutions
New Discussion

Re: frecover(2114): read error from input device (Permission denied)

 
Ashraf_1
Frequent Advisor

frecover(2114): read error from input device (Permission denied)

Hi Experts,

When I used sam frecover I had some of the files restored and then the backup failed with the following error:

Starting file recovery...
drwxr-xr-x oraydb dba /oracle/YDB/sapdata1/btabd_1
-rw-r----- oraydb dba /oracle/YDB/sapdata1/btabd_1/btabd.data1
drwxr-xr-x oraydb dba /oracle/YDB/sapdata1/btabd_10
frecover(2114): read error from input device (I/O error)
frecover(2114): read error from input device (Permission denied)
frecover(2113): unable to resync backup media

Press to continue sam...

This is happened after a new installation of hp-ux 11i in another server(L2000 with Ultrium 230e). I am sure that this tape was OK and verified as the problem kept on, even when I tried diffrent backup tapes. We used â insf â eâ to recreate device files after getting this error. And still encountering that.

I highly appreciate any valuable assistant.

Regard
ASHRAFM
6 REPLIES 6
john korterman
Honored Contributor

Re: frecover(2114): read error from input device (Permission denied)

Hi,
I found a similar error description for an ancient hpux version. I do not know if it is worth while trying, but the suggested workaround then was to make recover disregard so-called fast search marks: the error would often occur when trying to restore backups spanning more than one tape. The workaround required that frecover be executed from the command line where the device specification should include hostname, e.g.:
instead of e.g.
-f /dev/rmt/0m
in the command sequence, then
:/dev/rmt/0m

Check also the -f option of the man page for frecover. In the samlog you can see which command was actually executed through SAM and modify it to your needs. However, it is just a guess...
The ancient error description can be checked in doc id U0250623 in the tech base.

regards,
John K.
it would be nice if you always got a second chance
Steven E. Protter
Exalted Contributor

Re: frecover(2114): read error from input device (Permission denied)

ioscan -fnC tape
insf -e

may wish to reverse the order.

If you don't see good info on your tape drive, the drive could be bad.

check further with dmesg.

I can not believe that many tapes are bad unless they were made when the drive was failing.

SEP
Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
Sanjiv Sharma_1
Honored Contributor

Re: frecover(2114): read error from input device (Permission denied)

Shaikh Imran
Honored Contributor

Re: frecover(2114): read error from input device (Permission denied)

Hi,
Not the solution to your Problem But a step ahead for you.
Try Taking the backup of any small Filesystem through sam on a different tape and try to restore it.If this succeeds your tape device is configured for the system,O.S,
and obviously the Tape drive is working fine.
The only thing left out for suspect will be 1)The patches as your backup was taken in previous version of HP-Ux and the then patches.
2)(May God help ) The tape.

Regards,

I'll sleep when i am dead.
Steve Post
Trusted Contributor

Re: frecover(2114): read error from input device (Permission denied)

Maybe you wrote up the wrong problem here? Do you have permission to restore file X into directory /Y?

Earlier this week I had a problem with an application. But in the end I discovered the app was working fine. I just could not place a file in a certain directory because I did not have permission to do it.

Another possibility. Perhaps the tape you are reading is larger than the tape drive you are reading from? Is the tape drive for DDS2 and the tape a DDS3?

steve
Ashraf_1
Frequent Advisor

Re: frecover(2114): read error from input device (Permission denied)

Thanks for all responses,

I relied on Steven troubleshooting method. We run ioscan -fnC tape to find out that hardware status was no hardware which means the hardware was there and might be disconnected or switched off. But since it is ON we ensured that there is a loss in the SCSI Cable. So replacing that cable rectified the problem.

Regards,
Ashraf

ASHRAFM