Showing results for 
Search instead for 
Did you mean: 

Varonis DatAdvantage file server scan possibly causing mass recall of archived files

Level 3


Not sure if anyone here can help with this but I'm trying to track down the cause of an issue where one of our file servers has run out of disk space. A large number of files (over 200GB worth) appear to have been recalled from EV between 02:00 and 04:00 this morning which is very unlikely to be a user process as these are graphics files and the users don't work those kind of hours! A similar thing seems to have happened the last two nights on a smaller scale. A major change this week is the installation of the Varonis DatAdvantage software on Monday which is set to do a Filewalk on our file servers every night at 22:00. On the face of it it seems like Varonis is causing the issue but I just wondered if anyone is using this product on file servers which also run EV? I have Varonis support looking at the issue later this morning but any tips from the EV side would be useful.


Mark Whitmarsh.


Partner    VIP    Accredited Certified

Hi Mark,

To avoid the issue from happening again, you can make the configuration documented in the article below to exclude the program from recalling archived files.


Thank you, that looks like a good solution - I will test that tonight.


What Virgil suggested should resolve the issue.  If you need to confirm what process is recalling the files you can Dtrace EvPlaceholderService on the file server and look for lines similar to the following:

(EvPlaceholderService)    <6180>    EV:M    WorkItem::GetExeName: Trying to get the .exe name for pid: 4944
(EvPlaceholderService)    <6180>    EV:M    WorkItem::GetExeNameUsingPHHelper: entry - PID:4944
(EvPlaceholderService)    <6180>    EV:M    WorkItem::GetExeNameUsingPHHelper: exit - PID:4944, exe name:mspaint.exe
(EvPlaceholderService)    <6180>    EV:M    WorkItem::GetExeName: The .exe name for for pid: 4944 is mspaint.exe

This should give you the local process that is recalling the file.  Many should be from pid: 4 and this would be System indicating a remote request to open the file.



After a bit of a delay I've tested the ExcludedExes reg entry fix and that doesn't work. Unfortunately even though there is a Varonis service running on the file server that supposedly does the filewalk through the files when I ran DTrace I could see that EV sees the file recall request as coming from the Varonis server across the network (pid: 4 - no exe name).

So I guess that's that unless there is a way to block the SID of the Varonis service account user from being able to perform file recalls.



You could try to use Method 2 in the following article to put the server in backup mode.

This places the SID's of the users in the group in the driver cache and does not allow recalls from those users.