Error "none of the files in the file list exist(71)"

When i ran 4.5 i had the exact same thing.

From what i determined it was just netbackup being glitchy. It would pull the drive list from one of the other clients and try and back it up. Thankfully since there was no d,e,f drive, there was no loss.

I had to learn to live with it. Because we upgraded to 5.1 and never saw the problem again.

Do you have more than one client in same policy?

Check the exclude_list on that client.
Also with 4.5 I think people had problems if they had all local drives selected but the machines in question did not all have the same device mapping. ie one box has a d and one does not.

also check that the client is upgraded to the same level as the server. One other thing is if it is complaining about not being able to backup the dirve try excludeing that drive.Message was edited by:
Dennis Strom

I had the same problem at v4.5. I ended up putting in an exclude for that drive. In fact it was reporting two drives that didnt exist.

However, I did believe the server did have some extra drives before it had netbackup installed. And I'm sure that Windows somehow keeps a signature reference of previous attached devices somewhere in the registry, this is the only place I could think of where Netbackup was getting the info.

> This is a strange one....

I'm just grasping for solutions and this may have nothing to do with it, but check the tir_dir directory under $INSTAL_DIR\Veritas\NetBackup\tir_dir for a D drive

Assuming you don't have any include lists, what happens if you change ALL_LOCAL_DRIVES with "System_state" and ":\"?

I had this issue on 4.5FP6. My scenario, I had mutliple servers running win2k. One server sent a status 71. It ended up that it, llike your case, was trying to backup a D: that didn't exist. I noticed putting that client in another policy by itself using the ALL_LOCAL_DRIVES directive worked without producing that error. However, putting the server back in the previous policy brought the issue back. Part of me feels that there could have been an issue with TIR, like Bob suggested; however, we weren't using TIR. So, in my case, I had the same backup definitions in my policy as you do for yours; but I ended up having to create a separate policy, as I didn't see the issue go away by excluding that drive. It was strange.