Insert a valid tape - you mean the one you're holding?

[rreed]

Afternoon, team. We have some weirdness w/ some of our tape jobs recently not firing right away, or even outright failing, because they think they have no available tapes/tape space to do Files to Tape. For instance a given job should run about 1.2TB and I have about 2.4TB spread across two tapes in a job's pool. The error I initially get is something like, "Insert valid tape, I was last working w/ tape #30." Well, tape #30 is in your assigned pool and has 2.0TB free on it. Feel free to help yourself. But it doesn't, it just sits there asking me to insert it. Fine, I cancel the job, and run an inventory on tape #30 to load it. It goes and picks up the tape, runs a successful inventory, and waits for my next order - while still having tape #30 loaded in the drive. Cool. Re-fire my job, "Insert valid tape, last written tape was #30." The one that's currently in the drive.

Help please?

[rreed]

Interestingly, w/ the job waiting on the tape the drive is holding, it won't let me inventory any other tapes saying all drives are busy (the other drive of the two in this library is legitimately busy running a backup). Fine, I eject tape #30 and it allows me to do so, which appears to free up the drive. Try to run an inventory on another tape, it won't let me saying all drives are busy, even though I just ejected this drive and it's empty, waiting for something to do. Try to inventory the tape in question, it can't because all drives are busy, even though one of them isn't.

[rreed]

So if I cancel this job so the drive is idle, I can then inventory any tape I want. I've cancelled this job and tried another job, same thing. Other jobs are also looking for this same #30 tape that's clearly there.

[nielsengelen]

I would suggest contacting our technical support to have a deeper log investigation why this tape is being locked and not being used correctly.

[rreed]

Hmm, well after the other unrelated job that was running finished, everything appears to be working fine now. I re-fired one of the jobs that was complaining about tape #30 last week and it took off just fine, albiet w/ another tape. I'm not sure why, I wouldn't think the other job running on another tape on another drive would have anything to do w/ this. I don't know. I'll monitor and if when something comes around to trying to write to #30 and has trouble again, I'll open a ticket and report back. Right now, after the other job/tape/drive finished, it seems to no longer be concerned w/ tape #30. Weird.

Many thanks, as always.