Latest pre-release of 10.11.4 breaks Sophos AV Home Edition

I am also having the exact same problem. After updating from OS X 10.11.4 Beta 3 to beta 4 on-access protection is off and can not be enabled.

Note that if you turn System Integrity Protection off, you can enable On-Access Protection and it should stay enabled, at least until the next Beta is released.

VincentCina said:

SIP is not new in OS X 10.11.4 Beta 4, it has been there, and enabled, since OS X 10.11 (El Capitan) came out and Sophos on-access protection has been working fine with SIP enabled...

I'm aware of that and was using that trick to keep Sophos running back when El Capitan was first introduced until Sophos was made compatible. As Bob Cook pointed out, Apple has done something different in the most recent beta so turning off SIP is once again a temporary fix if the user needs to be running the latest El Cap version but also needs the protection Sophos provides.

bocaboy said:

...How did you figure out that it was SIP that was causing the problem? It's a little puzzling that it's the problem since, as noted by VincentCina, SIP has been running in El Capitan since it was released.

When El Cap was first introduced, SIP was the new security feature and it got enough coverage that some discussions included the Terminal commands to control it. After my original upgrade to El Cap, Sophos stopped working so turning off SIP seemed worth a try and it worked. As Sophos improved, I'd turn SIP on again as a test and left it on when the problem was solved. But when the problem recurred, turning SIP off was worth a try again, especially since it's simple enough to do. But since SIP is a good idea for security, the csrutil fix should be temporary at best if the betas are on a production machine. 

Thanks for the explanation. I had the same problem as I described here when I installed SAV under Yosemite on my iMac. (Inexplicably, my MacBook Pro was fine under the same OS. Go figure) Anyway, the problem with SAV resolved itself when 9.4.1 was released. It's also been working fine all the way to this beta of 10.11.4. In other words, SIP was never an issue prior to this beta.

Anyway, I did disable SIP, and that solved the problem of the dimmed icon. I have no idea if the problem is with Apple or Sophos, but I've reported it as a bug on the Developer forum at Apple as well as via Feedback Assistant. We'll see if that changes anything.

For the record, I'm surprised that Sophos QA doesn't uncover these problems. They have access to the same builds we do, and based on how many people experience issues, how is it that they're not uncovered prior to release? I'll give them a buy on 10.11.4 as it was just released last week, but this problem has existed on previous builds as well. Anyway, not trying to be difficult, just questioning the QA process at Sophos and that maybe it should be re-examined.

Rather than disable SIP I decided to install 10.11.3 last night. Sophos AV Home, and on-access scanning is working once again. I have lost the use of Photos until it is updated, but I can live with that as I have another production machine. I can live without this beta, as there are not any earth shattering feature enhancements.

That's a good solution in that you have both security systems working as well as whatever improvements 10.11.3 offers, especially when it's applied to a production machine.

Should work is not it does work. It does not work. On access scanning still does not work with SIP disabled.

GaryAlevy said:

Should work is not it does work. It does not work. On access scanning still does not work with SIP disabled.

In Terminal "csrutil status" returns "disabled?" After a reboot, if On Access scanning is off, trying to turn it on fails? And you're using OS X 10.11.4?

I am using the OS X 10.11.4 beta. I found the following: SIP can be completely or partially disabled. When SIP is completely disabled - On-Access scanning does work. When SIP is partially disabled - On-Access scanning does not work. Note that csrutil reports the status of six different configuration variables. In my case I had OS X system configured using csrutil disable --without debug. When configured this way On-Access scanning did not work but another pre-SIP program that relies on code injection, Total Finder, does work while On-Access scanning will not.
SIP configuration components are:
Apple Internal, Kext Signing, Filesystem Protection, Debugging Restrictions, DTrace Restrictions, NVRAM Protections.

GaryAlevy said:

I am using the OS X 10.11.4 beta. I found the following: SIP can be completely or partially disabled. When SIP is completely disabled - On-Access scanning does work. When SIP is partially disabled - On-Access scanning does not work...

So the instructions I offered for disabling SIP do work to enable On-Access scanning but the method to disable SIP just enough to allow TotalFinder to work isn't also enough for On-Access scanning to work. As I understand it, "csrutil status" will only report the six different configuration variables when a custom configuration has been set (e.g., "--without debug") though there was a bug at one point which produced that list even when SIP was completely disabled.

Fortunately, the issue should be resolved with the release of 9.4.2 [:)] It doesn't look like TotalFInder's author will pursue a solution though.

Thanks you were correct.

Thanks you were correct.