The last time that my local Content Caching server had been able to deliver updates to XProtect and related security data was almost three months ago, in May. After reporting this to Apple via Feedback, and supplying sysdiagnoses to help its engineers get to the bottom of the problem, I was finally told that the problem had been fixed a week or so ago. On Thursday 4 August it had the first chance to try out the latest security update, and I’m delighted to report that everything worked as it should: all four of my Macs downloaded and installed that update successfully.
I’m well aware that some of you still appear to be having problems installing these important security updates. If, as I suspect, Apple has fixed the problem that was stopping mine from working, it doesn’t necessarily mean that it will work for you. This article explains what you can do.
To start with, try updating normally, as you did before this problem began in early June. If Software Update tells you that an update is ready, try installing it as normal. If the new XProtect Remediator hasn’t been updated to version 68, and Software Update informs you that your Mac is fully up to date, try running SilentKnight, to see if that can discover the update, and download and install it for you.
If that works correctly, then rejoice and thank Apple’s engineers.
If it doesn’t, look carefully to see what SilentKnight reports. This bug typically enabled the update to be downloaded, but it then failed to install correctly, leaving your Mac stuck with an older version of XProtect Remediator.
The next question is whether that Mac is using a local Content Caching server for its updates, or obtaining them direct from Apple’s servers.
If you’re running a Content Caching server, restart the Mac hosting that, leave it a couple of minutes, then restart all other Macs that connect to it for their updates. If you’re not running that service, simply restart the Mac that can’t update. Try again, with Software Update or SilentKnight.
If you’re in a rush, and still need to install the update, you can disable the Content Caching service in the Sharing pane on the Mac that’s hosting it, then try to download and install the update again using SilentKnight. Once you’ve updated all your Macs, you can enable the service again.
If you have time, leave the server running, and start up your client Mac(s) in Safe mode, holding the Shift key on an Intel Mac, or going via Recovery mode for Apple silicon models. Then try downloading and installing the update again.
If you still have no joy in updating successfully, and can spare the time, please send Apple Feedback so that it can look further at this problem. To do that is fiddly, but the information you can provide is crucial if Apple’s engineers are going to arrive at a diagnosis. There’s another step you can try with a Content Caching server, that of emptying its cache. Try that in the Options… for Content Caching in the Sharing pane, or in the command line.
Reporting to Apple
My original Feedback report is now closed, as the bug is well and truly fixed here. If you’re still suffering problems, the only way to help the engineers discover what is still wrong is by sending your own Feedback report, something I can’t do for you. To do that, you’ll need to provide the engineers with at least one sysdiagnose, which provides log and other information they can use for diagnosis. There are two easy ways to perform that: I just type
sudo sysdiagnose -f ~/Documents
in Terminal and the compressed archive will be compiled and saved to my Documents folder. Or you can press Control-Option-Command-Shift-Period instead. You can cheat and use the fingers of both hands to do that! If your Mac is trying to get this update from your Content Caching server, then Apple will do best with two sysdiagnoses; if this is just a standalone Mac accessing Apple’s servers, then one is all that’s needed.
The next task is reproduce the problem: open SilentKnight, when it reports that an update is available, click on the button to install it. Once that fails again, wait a few seconds and obtain the sysdiagnoses, one from the Mac that has just failed to install the update, and the other from your Caching Server, if you have one. Those provide Apple with log records of what went wrong during the failed install on the client Mac, and what the server was doing at the time.
If you have a developer account or are in an Apple beta program, you should already have Feedback Assistant ready to open a new issue, describe the problem, and enclose the sysdiagnoses. If you don’t have Feedback Assistant, then please report it through this form.
Normally, I’m ambivalent about sending Feedback reports unless I’m invited to, as so many fail to generate any response and appear to be ignored. However, in the case of these updates they’re vital: Apple has no other way of knowing the problems you’re experiencing, so can’t fix them unless you provide information. Instead of just complaining at how poor Software Update has become, we need to help Apple make it work properly for all Mac users. Thank you for doing your part for us all.