Before iTunes 12.7, you could use iTunes for iOS syncing and backups, and iTunes could copy over downloaded iOS apps. Apple changed all that a few months ago with the release of iTunes 12.7. I suggested that a newly available feature in macOS 10.13 High Sierra could help cushion the blow of repeated downloads.
If you needed to restore an iOS device, those apps would be copied locally, instead of downloaded from the internet. And with multiple iOS devices in a household all using iTunes, it seemed like iTunes 12.7 could require a lot more app downloading, which can affect people with limited bandwidth or charges for bandwidth overages.
High Sierra added a feature previously found in macOS Server: Content Caching. In the Sharing system preference pane, you can click Content Caching, and enable it, and then macOS will retain all sorts of Apple and iCloud related stuff. Devices on the local network will recognize the cache, and retrieve what they can from the Mac instead of a new Internet download. (You can read Apple’s full list.)
If you have a desktop machine and extra storage, it’s perfect, because you gain an advantage and are just using extra hard disk space.
However, shortly after I wrote the column noted above, content caching stopped working for me. I click the Options button in the Content Caching service, and then clicked Edit and selected a different disk drive than my startup drive. After clicking OK, the service noted that content was being copied—in fact, it wasn’t. There was no content cached, and the copying never ended.
I filed this away, and every once in a while poked at the setting, and it always seemed to be copying, even though there was nothing to copy. Recently, researching a reader question, I decided to solve this, and found a detailed article explaining the command line tool
AssetCacheManagerUtil, which offers more controls than those found in the preference pane.
Poking at the stored settings, I found the problem, because this tool showed me the error experienced by the content-caching server. It couldn’t find an expected folder on the drive I’d selected. When you select a different drive to store the cache, that drive has to have the folder:
If it doesn’t exist? It stalls. This seems like a foolish testing error on Apple’s part: no message explains what’s going on, and there’s no text or other information that tells you a particular folder has to be on the destination volume you’re choosing for caching.
The very simple solution was using a command-line instruction via Terminal to create that folder. (You can also do it in the Finder by nesting folders.) Because this is an external drive, the path I use below has to include
/Volumes/, which is the Unix starting point for everything but your startup volume. Here’s the command:
mkdir -p "/Volumes/Your Volume Name/Library/Application Support/Apple/AssetCache/Data"
Substitute your exact drive name after
/Volumes/ and before
/Library/. It’s critical to put quotation marks around the full path, as without it, the command line treats any portion separated by a space as a separate folder to create—which makes a mess.
I also then used Activity Monitor to temporarily kill the processes being used for content caching.
- Launch Activity Monitor (Applications > Utilities).
- In the search field at upper right, type in AssetCache.
- For the items that appear, select one at a time and click the X (kill) button in the upper left, and confirm that you want to Force Quit.
- Repeat until they’re all temporarily gone. macOS will relaunch them.
In a few moments after they’re relaunched, the Content Caching service will be back to normal, showing a green light and once again able to be configured.
I don’t know how many people have tried to use this feature and move a cache to a volume that lacked the necessary folder, but given how useful this caching can be, I hope more of you try to use it!
Ask Mac 911
We’ve compiled a list of the questions we get asked most frequently along with answers and links to columns: read our super FAQ to see if your question is covered. If not, we’re always looking for new problems to solve! Email yours to email@example.com including screen captures as appropriate, and whether you want your full name used. Every question won’t be answered, we don’t reply to email, and we cannot provide direct troubleshooting advice.