Last week, Apple pushed two surprise updates, to XProtect and fix a bug in Big Sur version 11.6.7. Unusually, this didn’t go as smoothly as it should have with some users, including me, complaining of repeated failures to install downloaded updates. This appears to have been the result of damaged or corrupt downloads. While persistence brought success for some, there are still Macs which are struggling to update successfully. This article explains what you can do when your Mac can find an update but doesn’t install it successfully.

How can you tell when an update fails to install?

This is easiest when you use either of my free utilities SilentKnight or LockRattler. They’ll both report the update is available, then when you click to Install all updates, you’ll see an error message in the scrolling text window reporting that installation of the update failed, and the component being updated won’t change to the new version number.

If the Software Update pane shows an error, that should provide similar information. Otherwise, to download and install waiting updates you can type
softwareupdate -ia --include-config-data (or in El Capitan sudo softwareupdate -ia)
in Terminal, to see the same messages shown by SilentKnight, as that’s the tool it uses to obtain waiting updates too.

If you know your way around the Unified Log, you should discover parallel entries there.

What next?

By far the most common cause for failure to install updates like this is that something has gone wrong with softwareupdate or its service softwareupdated. That’s most easily corrected by restarting your Mac, then trying to download and install the update again.

If it still doesn’t work, start up in Safe mode and try to install the update there. One of the primary purposes of Safe mode is to resolve problems with updates and updating, whether they’re full macOS updates or small security data updates like XProtect.

If you’re not running a local Content Caching server and still can’t get the update to install, all you can do is wait an hour or two and try again.

Local Content Caching server

If you’re running a local Content Caching server, then the problem could now rest with the copy of the update stored in its cache. That’s what probably happened to so many of us last week: when the local server downloaded the update from Apple’s software update servers, the copy obtained was damaged. Once that damaged copy has been put into your local server’s cache, that’s the update that it will serve to all your local Macs when they connect to it to obtain the update.

What can make this worse is that, even if you do manage to get the Mac running the Content Caching server to update successfully, that doesn’t mean that it will replace the damaged copy in its cache, which may continue to deliver that same damaged version to all the Macs which try connecting to it.

To confirm this, you can inspect the log, as I’ve described here.

The most immediate solution, which should allow all your local systems to update correctly, is to shut down the Content Caching server, turn the service off in the Sharing pane, or isolate the server from the rest of the network. Then update all your other systems, which should download fresh copies of the update directly from Apple’s servers. Once that’s done, you can bring the server back up in Safe mode and try updating it there.

Should you flush the cache?

In this case, because others were affected, including those not running a Content Caching server, it’s almost certain the damaged update came like that from Apple’s servers, as does happen occasionally. In that circumstance, once all your other Macs have updated directly, you don’t need to do anything to remove the duff copy in your server’s cache.

It’s important to establish that this hasn’t occurred because of a local factor. Using Disk Utility, run First Aid on the volume containing the cache to ensure that its file system is healthy.

I don’t know any way of removing individual updates from the Content Caching server. Apple’s command tool for its maintenance, AssetCacheManagerUtil, only knows how to flush whole caches, using
sudo AssetCacheManagerUtil [flushCache|flushPersonalCache|flushSharedCache]
where the commands set the cache to be flushed:

• flushCache flushes the entire content cache.
• flushPersonalCache flushes all personal (iCloud) content.
• flushSharedCache flushes all shared (non-iCloud) content.

Flushing a large cache, such as mine which is currently over 100 GB, may not be what you want to do. So long as there’s no storage problem and the update affected was most probably supplied broken, there shouldn’t be any harm in leaving it where it is.

Further reading

Repeated installations of the same updates
How security data updates should work