Skip to main content

Our environment hasn't really had any need for a caching server, but I figured I'd test it out anyway. I took a server we had previously set up as a file server/time machine server as the guinea pig. Since this is a test only, it's OK if it will only work on its subnet. The problem is it doesn't work at all even with machines confirmed to be on the same subnet.




  • Hardware: Mac Mini (mid 2011)

  • macOS: 10.12.6

  • Server Version: 5.3.1

  • ip address: static


  • client OSs: Range from 10.10-10.12.6


  • Permissions: All Networks + matching this server's network


  • Peering: All Networks


  • StartupStatus = "OK"


  • RegistrationStatus = 1

  • CacheStatus = "OK"

  • state = RUNNING


  • AllowPersonalCaching = yes (temp just to confirm caching works)


  • LogClientIdentity = yes

  • AllowSharedCaching = yes

  • ListenRangesOnly = no

  • LocalSubnetsOnly = no



As far as I can tell from Apple's documentation, this should be fine for something that runs solely on one subnet. It has always successfully registered with Apple as a viable cache server. These things can take some time to filter in, so I let it run for about a week. No devices ever connected to it. It has cached nothing. It is discoverable, and I can reach it from any given Mac on the subnet. The server was already in use for things on the network, so the DNS settings should be correct.



The subnet itself is solely for wired internet, so I wouldn't expect iOS devices to reach this server. I would, however, expect the devices I plug into the same switch to reach it. When I run /usr/bin/assetcachelocatorutil from client machines, I get a bunch of goose eggs for the found server counts.



Any suggestions on how to get this caching server to actually cache literally anything?

@McAwesome Does your organization have more than one public facing IP address? Did you add an _aaplcache._tcp entry to your DNS for all of the IP addresses your machines would hit Apple's update servers from? If not, you really need to do that and Server.app will generate the line you need to add to your DNS for you (or the command needed if you're using a Windows server for DNS).



And in case you hadn't seen it yet, this is a good resources for Caching Server info: OS X Caching Server - Setup and Troubleshooting

@StoneMagnet I believe we do, but since this is set to just one subnet I don't think that should matter. From what I was able to read at that link and in Apple's documentation, the public facing IP address issue only really matters if you're accessing multiple networks or subnets. Everything should be able to talk to each other on the same subnet, though once we go to other buildings on our network things get much more complicated.



If I can get it working on it's own subnet, I can approach the higher ups to get the bureaucratic process started to get it set up for more than just its subnet. The joys of a big company.

@McAwesome No, it matters if you want things to work reliably. To check for updates, all of your machines reach out to Apple's servers, which will re-direct them to the local Caching Server if it recognizes the IP address they're coming from as having one. The fact that your machines are on the same subnet as the server on your internal network does not necessarily mean they'd appear as being from the same public IP to Apple. My experience with a network that has 15 public facing IPs has been that no _aaplcache._tcp in DNS == flaky Caching Servers (I run multiple), but _aaplcache._tcp in DNS == reliable caching servers.

@StoneMagnet Ah gotcha. I guess that roundabout answers my question. Due to the networking team's rules on things, I can't get it set up even if I wanted to.

@McAwesome I can feel your pain, it took me months to get the group in charge of our district DNS to make that change. For me the trick was getting the right district people in the room with our Apple SE who explained that unless you wanted every Apple device on your network pulling updates individually from Apple's servers you really want a properly configured Caching Server on your internal network.

@StoneMagnet I think it's something we could get going, but not at the level I was toying with it. It wouldn't make sense to go through all the hoops for just one department I handle. If they have to make those changes, they may as well set something up for every department to take advantage of.

@McAwesome You could try pitching it to the group responsible for your org's network that their helping you get your test Caching Server properly configured by making a single line addition to their DNS, even temporarily, should quickly show if it's something they should be providing company wide.

Terms & ConditionsCookie settings