Video Screencast Help

SEPM\data\inbox\log many ".err" files

Created: 29 Feb 2012 • Updated: 29 Feb 2012 | 12 comments
S_K's picture
This issue has been solved. See solution.


I just noticed that in the SEPM\data\inbox\log subfolders (like Client and System) there are many ".err" files. Does this indicate any problems and how I can verify this?

As far as I know, SEPM\data\inbox\log is where the clients upload data into different subfolders there.

Comments 12 CommentsJump to latest comment


stop the SEPM service, delete them, and then restart the SEPM service and monitor the folder to see if it builds up again.



Please don't forget to mark your thread solved with whatever answer helped you.

P_K_'s picture

If the above steps not get rid of the files them stop the SEPM service, delete the files and than start the SEPM service.

There shouldn't really be any files in here. This is the folder that all the client information gets sent to. It sounds as though there is a problem processing the files. Normally you may see a handful of .DAT files that the SEPM will clean out on its own as it processes them.

MCT MCSE-2012 Symantec Technical Specialist (SCTS)

ABN's picture

TMP files are generated on SEPM servers when it processes the logs received from the client machines and the .err files are generated when the SEPM server has issues in processing or forwarding the logs to the database server.

You can find the “dat.err” files in the following locations,

D:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\data\inbox\agentinfo
D:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\data\inbox\content
D:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\data\inbox\log
D:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\data\inbox\log\behavior
D:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\data\inbox\log\client
D:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\data\inbox\log\packets
D:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\data\inbox\log\security
D:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\data\inbox\log\system
D:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\data\inbox\log\tex\AVMan
D:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\data\inbox\log\traffic

The .ERR file can be delted as such, else you can have a .BAT script and have is shcheduled to do the JOB say once in a month or 2.

S_K's picture

I deleted all ".err" files. Most of them were into the System and Clients subfolders. And actually most of them were very old (few months and even 2-3 years old). For now all looks fine, not new err files generated.

However, there is one more thing, the customer is using one AV software for the servers and SEP for the client machines. So the SEPM is installed on a server with another AV, not SEP. I checked in the scanning exclusions that SEPM installation folder is not excluded from scan. Should I do it or you do not recommend the whole SEPM folder to be excluded? 

P_K_'s picture

If I would have been your place, I would have excluded SEPM folder

MCT MCSE-2012 Symantec Technical Specialist (SCTS)

pete_4u2002's picture

the .err files are the one that are not processed by the SEPM. It could be overload on the SEPM and DB.

NRaj's picture

The err files are created when the SEPM has issues procesing the logs from client to database. These have to be manually deleted. We were running eTrust on the SEPM servers and after installing SEP on SEPMs and upgrading th RU7, the issue was controlled to a great extent.

mssym's picture

The .err files could be located in different subfolder, based on the directory infrastructure, I think some events might store in the .err and never got processed, if we simply deleted those files, we might end up with losing some valuable event information, I am afraid, especially some of the things that the auditors look for,

Why not rename .err back to .dat file to get them re-processed?

NRaj's picture

These are the client information that the server sends to DB. I do not think there is a way to say what exact information we may lose if we delete some files.

But changing the .err file to .dat did actually work. The file was processed and removed automatically.

Cameron_W's picture

If you have not yet done so I would highly recommend changing from PUSH to PULL mode and raise the heartbeat. This will help alleviate a lot of the load that is put upon this server.

If I was able to help resolve your issue please mark my post as solution.