>... Is there any chance my thrashing about has screwed up some vital >file there that could trigger this error? ...
Possibly, but it doesn't really look like it. >... I did learn that amindexd is writing debug logs: > >amindexd: debug 1 pid 2586 ruid 11 euid 11 start time Tue Jan 15 13:44:32 2002 >amindexd: version 2.4.1p1 >< 220 [server] AMANDA index server (2.4.1p1) ready. >> ���� >< 500 Access not allowed Is there really a line of non-printing characters between the 220 and the 500 line? If not, that's really odd. You should see an initial sequence something like this: amindexd: debug 1 pid 15118 ruid 2875 euid 2875 start time Thu Jan 17 15:39:26 2002 amindexd: version 2.4.2p2 < 220 clerk AMANDA index server (2.4.2p2) ready. > SECURITY USER root bsd security: remote host fortress.cc.purdue.edu user root local user backup amandahosts security check passed < 200 Access OK > DATE 2002-01-17 < 200 Working date set to 2002-01-17. Note the "SECURITY USER root" line. That's the first think amrecover should send to amindexd. >Not very helpful to me. Is there any way to ratchet up the debug level? Not the debug level, but you can run amindexd in a test mode that might help. First, run it by hand, as your backup user, on the server. Note the "-t" option: $ .../amindexd -t 220 clerk AMANDA index server (2.4.2p2) ready. SECURITY USER root 200 Access OK DATE 2002-01-17 200 Working date set to 2002-01-17. QUIT 200 Good bye. The lines that do *not* start with a number (e.g. "SECURITY USER root") are what I typed. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
