>It's telling me sth about "No index records for disk for specified date" - whi
>ch isn't
>true!
>I got onto the tape-server, got into the infofile-directory ...
I assume you meant the indexdir directory?
>1.13.19 in place. Hm. Unzipped the indexfile and more'd it: for me it seems co
>rrect but who knows!
If the lines start with a big number, it's the 1.13 bug. If they look
like normal paths without a leading big number, it's probably OK.
>Has anybody had sth similar or does anyone know any solution for that behaviou
>r!?
This problem comes up fairly often and usually just requires some
detective work.
First, what date, host and disk did amrecover say it was going to use?
Does that match the path you used in the index directory (except the
disk name has '/' characters converted to '_')? Is there a .gz file
with a datestamp on or before the date amrecover reported?
Does the user you run amindexd as (look at inetd.conf) have access to
the index directory and everything within it?
Take a look at /tmp/amanda/amindexd*debug on the server. It may have
some other clues.
> Ingo Bez
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
