The XFenceDaemon is hogging a lot of resource on my Mac, at times I've seen it consume 20GB of memory and 80% cpu. Is their a way to switch this DeepGaurd feature off on F-Secure Safe or do I have to remove Safe completely?
These following steps suggested by our backend team would help in reducing the Xfencedaemon high CPU usage. You can perform these given steps and let us know the outcome.
1) Open Terminal app
2) Type in the command below to open the file that contains custom rules for XFENCE (it will prompt for the customer’s admin password)
sudo nano "/Users/Shared/F-Secure XFENCE/local.xfence.rc"
3) Add the entire line below to the first line of that file. You can just copy the line below with Command+C key combination and paste it to that file with Command+V key combination.
allow prefix "/Users/" "/usr/local/Cellar/node/12.12.0/bin/node" rwcx "" "95efcb05d535725ea1bf5ee4ee0cc0b80eedb2d3e5b3df83c8be6167b373d55e" "0"
4) Press Control+O key combination and "Enter" key to confirm changes to the file. And then Control+X key combination to exit from the file editing mode
5) Reboot the Mac to apply these changes.
DeepGuard is working in silent mode in the latest release of SAFE on macOS. Unfortunately, there are no user facing controls for it at the moment. But, we can figure out the root cause for DeepGuard to behave like it does on your system and create an override rule that will calm it down.
Could you please share if you've noticed if high CPU consumption by XFenceDaemon is starting to happen when you launch some specific application or you are performing a certain operation on your Mac? Thanks in advance!
Best regards, Arthur
SAFE Mac R&D Team
P.S. @Sethu, just a heads up for future similar reports. Most of such issues are quite individual and thus the solutions that we provide are also quite specific to each user's setup. The previously mentioned solution was shared because the user was experiencing issues with running "node" command line utility (step 3) alongside DeepGuard. It's better to figure out the root cause of such behavior by DeepGuard as such solutions only target specific applications/process paths. As a general rule, we can start by asking for more details about applications which are running at the same time when this behavior is observed and asking for diagnostics (fsdiag) is also a good idea.
Any information on when these controls would be available on macOS? I tried disabling real-time protection, but that doesn't seem to affect xfencedaemon.
Currently it prevents me from opening Unity (by Unity Technologies) projects and adding/removing Unity's packages in the project. A workaround for this is to keep Activity Monitor open while Unity is loading and kill xfencedaemon every time it starts. I'm doing my work on a MacBook Pro (2019) with macOS 11.0.1.
Is there a command to make it ignore "/Applications/Unity*"? There are several apps from Unity: Unity Hub in "/Applications", and different versions of the editor inside "/Applications/Unity".
The current plan is to release SAFE with fully featured DeepGuard by the end of the year. That includes user visible controls. But for now, I'll take a look at Unity app and what it accesses to see if I can come up with a DeepGuard override rule to help you out. I'll get back to you as soon as I can with my findings.
Hi again, @Havokki!
Let's try the steps below to mitigate low performance in Unity due to DeepGuard interference.
Please open Terminal app and enter the commands below to create an ignore rule for DeepGuard which targets Unity applications. There two commands: the first one creates an ignore rule for applications which are signed with Unity team identifier and the second one restarts DeepGuard service (xfencedaemon).
echo 'allow prefix "/Users/" "any" rwcx "t" "BVPN9UFA9B"' | sudo /bin/sh -c "cat >> /Users/Shared/F-Secure\ XFENCE/local.xfence.rc"
sudo killall xfencedaemon
Please let me know if there is any improvement after executing these commands in Terminal. Thanks!
Thanks, @ArthurVal! Xfencedaemon starts and takes quite a lot of CPU but only for a moment and Unity is able to do its stuff again.
Alright. So at least some improvement, I hope.
Let's do it like that. If you are still willing to fix that remaining temporary slowdown during the launch, please file a support request (https://www.f-secure.com/en/home/support/contact) and attach the archive with SAFE diagnostics which you can get by running "Support Tool" app. It is located in the same folder as SAFE. This way, we'll be able to see the exact activity that DeepGuard intercepts and we can target that explicitly to fix it completely.
Alternatively, as it was mentioned previously, we are planning to make a new release of SAFE with user visible controls in the near future (current plan is until the end of the year). So you would also be able to see exactly what activity DeepGuard is intercepting and would be able to create a similar allow rule on your own when DeepGuard shows a prompt.