Can macOS Endpoint Protection Co-Exist with Google Drive File Stream?

[Mox 2]

Hello,

We are evaluating ESET Endpoint Protection 6.5.600.1 on macOS High Sierra. We've discovered that ESET Endpoint Protection brings our Macs almost to a complete halt when Google Drive File Stream (GDFS) is running. GDFS becomes unresponsive, and all system activity becomes so sluggish as to make the system unuseable.

We have tried excluding /Volumes/GoogleDrive/* (using Application Preferences > Protection > General > Exclusions > File System) but this did not seem to help. When users quit GDFS, the system performance returns to normal.

Is there any other setting I can use to exclude GDFS in a way that will allow ESET Endpoint Protection to work with it? 

[Marcos 4,838]

Please try excluding /Users/%user%/Library/Application Support/Google/DriveFS/ .

[Mox 2]

Thanks Marcos. Excluding /Users/%user%/Library/Application Support/Google/DriveFS/* did not help. Even with that exclusion added, ESET still makes a Mac unusable when Google Drive File Stream is running.

[Marcos 4,838]

I was informed that we are in touch with Drive file stream developers since a 100% solution needs to be implemented on both sides if we don't want to sacrifice protection. In the mean time, we're trying to find a workaround via exclusions. We'll keep you posted.

[Peter Randziak 1,010]

Hello @Mox

please make these two exclusions:

"/Volumes/GoogleDrive/*.*" 

"/Users/{username}/Library/Application Support/Google/DriveFS/*.*"    replace the {username} with user under which the Google Drive File Stream runs.

without the quotation marks and with the *.* at the end of the exclusion definition.

Please let us know if it helped you to resolve the issue.

Regards, P.R.

[Mox 2]

Thanks Peter. The *.* wildcard seems to have done the trick.

I added both of the exclusions you suggested, and re-installed GDFS. This configuration works fine.

I then went back and removed the exclusion that specifies my username rather than using a variable. It still worked fine.

For reference, here's the exclusion set that I'm currently using:

/Volumes/GoogleDrive/*
/Volumes/GoogleDrive/*.*
/Users/%user%/Library/Application Support/Google/DriveFS/*
/Users/%user%/Library/Application Support/Google/DriveFS/*.*
/Users/%USER%/Library/Application Support/Google/DriveFS/*
/Users/%USER%/Library/Application Support/Google/DriveFS/*.*

So far, it's working fine with GDFS. I'm sure some of these rules are redundant... with more testing I'll probably be able to remove two or more.

[Mike O. 1]

@Peter Randziak

The challenge with this syntax:

"/Users/{username}/Library/Application Support/Google/DriveFS/*.*"    replace the {username} with user under which the Google Drive File Stream runs.

Is that it's hard to script or generalize to any logged in user, which makes it hard to centrally manage.

Can you confirm the syntax that can be used for Unix-like systems (MacOS and Linux) that is certain to work with ESET? The logical approach would be:

~/Library/Application Support/Google/DriveFS/*.*

But there's no sense of whether that will work or not.

Thank you!

[Peter Randziak 1,010]

Hello @Mike O. 

it seems, that it should be sufficient to exclude the /Volumes/GoogleDrive/*.*    OR the path with username.

So the first one should be your choice in your environment.

Regards, P.R.

[Mike O. 1]

Hi @Peter Randziak,

Thanks for your reply. We're finding just the first exclusion to not be adequate in all cases. 

Can you please share the correct exclusion syntax for the user home directory on Mac? I can't find it documented anywhere. I need to understand how to form my exclusions so the code that parses the exclusion list will understand it correctly. I'm assuming since one can use system variables on Windows, there's comparable functionality for UNIX/Linux-like file systems.

[Nick M 3]

I'm experiencing this same issue in an enterprise deployment. As Mox described, with Endpoint Antivirus and Google Drive File Stream running simultaneously, our Macs become unresponsive to the point that they are unusable.

Just wanted to add my voice as another administrator who's very interested in a fix for this issue.

[Bazze 1]

For us, so far, the example given in this thread has been working great.

/Volumes/GoogleDrive/*.*

However, I'm now moving over to look at this issue for Windows users. How would one solve it there since volumes are only named with a letter? Seems like it's favoring "G:\" but I guess if it would already be occupied, it would choose another letter. So excluding the "G"-drive doesn't do the trick in all cases. Any ideas?

[Mike O. 1]

@Bazze, I read an announcement that admins will are now able to indicate which drive letter DFS should use for their GSuite domain:

https://support.google.com/a/answer/7577057?hl=en

That's what we're looking at to make this predictable/scriptable.

[Bazze 1]

On 3/11/2018 at 7:10 PM, Mike O. said:

@Bazze, I read an announcement that admins will are now able to indicate which drive letter DFS should use for their GSuite domain:

https://support.google.com/a/answer/7577057?hl=en

That's what we're looking at to make this predictable/scriptable.

Perfect! Thanks.