Video Screencast Help

EV 8.0 SP2 : FSA event 40980 error 53

Created: 30 May 2011 • Updated: 12 Dec 2012 | 11 comments
This issue has been solved. See solution.

This week-end my FSA task was completed after this error on event log :


Type de l'événement : Erreur
Source de l'événement : Enterprise Vault
Catégorie de l'événement : File System Archiving Task
ID de l'événement : 40980
Date :  29/05/2011
Heure :  16:44:36
Utilisateur : N/A
Ordinateur : 
Description :
The folder attributes for the folder: \\?\UNC\xxxxxxx\O$\donnees\Pole PAPH could not be accessed due to the following error: Error loading file stream: \\?\UNC\xxxxxxx\O$\donnees\Pole PAPH:EVArchivePoint.xml, error code: 53.

 This folder and its subfolders will be excluded from archiving


The Symantec support talks about a network error. Why the task has continued ? This is a network error to access the file server or to read folder attributes ? Why the task is completed when there are access errors ?

Thanks for your help.


Comments 11 CommentsJump to latest comment

JesusWept3's picture

could have been a temporary glitch, if you run now against the fsa target, does it fail on the same error?
If you see the error, the code returned is "53" which is an error returned from windows.

If you run "net helpmsg 53" the error it gives you is "The Network Path Was Not Found"

dept-sma's picture

Thank's. I have not the opportunity to run again the task. This task has been run since 14 december and with this error it has been completed. My file server has a 3,6 To disk.

I have to wait to migrate the server in 9.0.

I looked on the event log's file server and there is no error with network. I don't understand what happened...

JesusWept3's picture

yeah, its a tough one, i mean really you'd have to see if you could reproduce it
If it fails again, you could try seeing if you can view the EVArchivePoint.XML file in the following location

 \\?\UNC\xxxxxxx\O$\donnees\Pole PAPH:EVArchivePoint.xml

You will need to download the following location:

If you download the Streams.exe application, you can point it to the \Pole PAPH\ folder and see if it can access the EVArchivePoint.xml

Rob Brenner's picture

In regards to the error, the most important advice I would give at this stage is that, no matter what tool you decide to use to view or check the content of EVArchivePoint.xml, you should be careful if you decide to delete the ArchivePoint in case there is a corruption.

You should ONLY use FSAUtility to re-create the ArchivePoint. If you use any other methods, like re-creating the AP via the VAC or using ArchivePoints.exe you will end up with a duplicate Archive.

dept-sma's picture

 Yes, I know how to recreate an archivepoint file with FSAUtility and that it's the best method.

Rob Brenner's picture

I'm not sure if I understood correctly. You have configured a file server target volume which contains 3.6 Terabyte of data and the Archiving Task has been running since 14 December finishing on 29th May?

To me it sounds very 'unrealistic' and counter productive to be managing your targets this way.

I don't know the details about your archiving policy rules, but if you are archiving everything, it would also not be a recommended approach.

dept-sma's picture

Yes, unfortunatly, you understood correctly ! I can't change anything on this file server. The tree is very large and deep. Enterprise Vault doesn't permit a FSA task on a folder, only on a volume. So I can run only one archiving task.

And the problem comes from EV v8 (see attached file) which is not able to manage checkpoint file with a large and deep volume's tree. I am waiting to migrate to EV 9.

The problem that I encountered (network loss) has stopped the archiving task in progress altough a great part of tree is not archived. Why this network error is not well managed by EV ?

Case 414-647-744 (Having difficulties in archiving files....).doc 22.5 KB
Rob Brenner's picture

This is why tried to stress that running a single Archiving Task for such vast amounts of data is unrealistic and counter-productive. I would still recommend you to consider re-studying the implementation of the archiving solution in this environment.

The more burden you put into a single Archivint task the more chances you will have of being affected by environmental issues like network disruption.

If you haven't yet archived the entire data set it may be early enough to justify stopping with the current archiving strategy and change the way you deploy the archiving strategy against the data set.

You could create additional shares below the main drive letter for the disk volume and then assign each as an individual Volume target with their respective Archving Task. This would improve the processing time to walk the file system.

Rob Brenner's picture

There are 2 problems:

1- If you are intending on archiving everything, you should use a less agressive rule to archive the data in stages

2- If the file server Volume is so large that it takes so long to complete a single archiving run, it will cause yo a lot of headache when trying to manage, troubleshoot issues and administrer the data.

Here it would be advisable to try and split the load into separate Archiving tasks so you can run them at different schedule intervals.