grettir

We've been battling almost identical issues here. First of all, keep in mind that managed Mac clients may be ignoring exclusions right now, and ESET + Time Machine can bring a system to its knees. See: https://forum.eset.com/topic/9793-excluded-directories-still-being-scanned-by-managed-mac-clients/ [Note: I see that you already replied to that thread. Glad to be of help! ] Second, you might want to try disabling Web Access Protection and Email Client Protection, at least as a troubleshooting step. We were experiencing hard locks when connecting to wireless networks, random 1-2 minute system freezes w/beachballing, etc. Early testing with Web Access Protection and Email Client Protection both disabled shows a marked reduction in those symptoms. And previous bugs/fixes involving Web Access Protection sound suspiciously like what we're experiencing: Often esets_daemon freezes OS X completely for about one minute before a number of other issues occur, such as esets_proxy no longer functioning, module errors, and more. …and… Fixed: esets_proxy deadlock causing the HTTP freeze. …and… Fixed: Problems loading websites when Web Access Protection is turned on.

First of all, the sentence "The path to the last 'scanned' file does not mean that the file was scanned…" is pretty hilarious. Although that would go a long way toward explaining why "'excluding' a file does not mean that the file is excluded." Second, if files displayed in the "Scanned objects" stream aren't actually being scanned, then explain the following: 1. When using an unmanaged client, files in excluded directories never appear in the "Scanned objects" stream when they are accessed. 2. When using a managed client, files in excluded directories always appear in the "Scanned objects" stream when they are accessed. Either: a.) Your "Scanned objects" logging/display code is broken since, in your scenario, all accessed files should appear in the "Scanned objects" stream regardless of whether the client is managed or not. …or… b.) When your client says it is "scanning" an object it is actually scanning an object. Third, as I specified in the title of my post, we're talking about the Mac client here, not Windows. And last, but not least, I think I described the results of my Eicar testing in rather good detail. Either you didn't actually read my post before you responded (likely) or my descriptive prose needs some work (also very likely). And I think you may have also skipped over the reply from an ESET Staff member who stated that the behavior that I described has been confirmed by your QA team and is being tracked as a bug. P.S. I apologize for the snark. It's been a rough Monday morning…

Sorry. I obviously need to revisit my Tech Support 101 textbooks: ESET Endpoint Security for macOS 6.3.85.1 ESET Remote Administrator (Server), Version 6.4.304.0 Client testing done on MacOS Sierra 10.12 (16A323).

The short version: 1. It seems that managed Mac clients are only partially honoring exclusions. a. Eicar test files placed in excluded directories are being ignored, as expected. b. Files in excluded directories are still being scanned on access, which is not as expected. 2. Unmanaged Mac clients appear to be honoring exclusions correctly. The long version: My MacBook Pro is affectionately referred to by my colleagues as the "Wind Tunnel" because its fans are constantly going at high speed. And its fans are constantly going at high speed because my managed ESET client is constantly scanning files in directories that have supposedly been explicitly excluded from scanning. A good example is Backblaze's working directory. Since Backblaze is constantly updating its indexes, logs, etc, there's always a lot of churn going on, so I've explicitly excluded Backblaze's working directory… /Library/Backblaze.bzpkg/*.* …via policy (as specified in numerous Knowledgebase articles). And I can tell the exclusion is working (at least in part) because when I place a copy of the Eicar test file in the /Library/Backblaze.bzpkg/ folder (or one of its sub-folders), the ESET client ignores it. But the moment a Backblaze backup kicks off, my managed ESET client starts scanning every file that is accessed in Backblaze's supposedly-excluded working directory, pegging the CPU, and causing the fans on my MacBook Pro to start screaming. Here's a screenshot that shows both the exclusion in the client, as well as the client completely ignoring that exclusion: The same is true of Time Machine backups, as well. Even though I've gone to great lengths to exclude every possible permutation of Time Machine path and volume name, ESET starts churning through every accessed file in those supposedly excluded directories/volumes the moment a Time Machine backup starts. I've only seen this behavior with managed clients. If I install a standalone version of the exact same client with the exact same exclusions, the exclusions work as expected. Even with Backblaze and Time Machine backups happening simultaneously, files in those excluded directories never show up in the scanned objects stream and my fans hum along quietly. But the moment I connect the ESET client to a Remote Administrator server, the scanned objects stream becomes a raging torrent of files in directories that it should be ignoring, and my fans kick into overdrive. I've tried adding/removing policies, creating new policies from scratch, and applying those policies at different levels in the group hierarchy. I've tried uninstalling and reinstalling the client multiple times, as well as going from managed to unmanaged and back again. I've also tried different syntax permutations for the exclusions (including two wildcard symbols (*.*), one wildcard symbol (*), and no wildcard symbol at the end of the path), but the problem remains. Any ideas? I'm out of them…