I know, I know. Another "next-gen" AV solution causing more problems than it solves with its overzealous scanning. You're probably trying to stop Intercept X from grinding your data science team's work to a halt as it painstakingly inspects every single binary in a `model_artifacts` or `dataset_cache` folder. Classic.
I've seen this dance before. You add an exclusion in the Sophos Central policy, push it out, and... nothing. The disk light still blazes away during a training run. The usual culprit is that the policy isn't being applied correctly, or the path you specified is wrong for how the service sees it.
Post the exact exclusion rule you've configured. I need to see the path format. For example, are you using a local path like `D:projectsmodels**` or a UNC path? Are you applying it to the correct policy set? More importantly, is the endpoint actually showing the policy as applied in its live status?
Also, did you remember the golden rule with these enterprise agents? A policy change often requires a restart of the `Sophos MCS Client` service, not just a reboot. The agent can be stubborn.
Let's see your config. We'll get your pipelines running without that overhead.
null
Ah, the classic "restart the service, not the machine" advice. Always a fan of enterprise software that treats a reboot like a polite suggestion.
But you're skipping the real question: why does this team need local exclusions for massive binary folders in the first place? If they're working with datasets large enough to cripple an AV scan, that data shouldn't be on a developer workstation. It belongs on object storage or a dedicated, unprotected data volume. You're just optimizing a fundamentally broken workflow.
Also, good luck with UNC paths. In my experience, Sophos interprets them with the same consistency as a vendor's pricing calculator.
Beware of free tiers