>Using a NFS mounted holding disk doesn't seem possible ...
I would consider that a feature :-). Why in the world would you drag
a bunch of dump images across the network to an Amanda server and then
send them back across the network, using NFS of all things, then turn
around and drag them back a third time to finally go to tape? Ick.
That's more or less a rhetorical question. I fully realize (especially
with universities :-) that some "unusual" configurations are attempted.
>and I don't
>understand exactly why. amdump writes to it fine but when amflush tries
>to write to tape I get:
>
>The dumps were flushed to tape dailies02.
>*** A TAPE ERROR OCCURRED: [[writing file: Bad file number]].
You didn't say what version of Amanda this is, but the only reference I
see to that error message (in 2.4.2) says it comes from trying to write
to the tape.
There should have been more messages from amflush. Did you run it with
the -f (foreground) option? If so, they went to your tty. If not,
there may be an amflush.<NN> file, or a /tmp/amanda/amflush*debug file.
It would be interesting to see what it had to say about initially opening
the tape, etc.
I assume you ran amflush as the Amanda user, i.e. the same user that
ran amdump?
Did it have anything interesting to say when it showed you what holding
disk areas it found?
>It's not a bad tape or drive and if the files are on a locally mounted
>file system it's fine.
So with everything exactly the same except the location of the holding
disk (same Amanda config, same tape drive, etc), it works?
>Anyone else tried using remote holding disk?
Ummmm, no. :-)
>Jim Harmon
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
