After doing a clean install of Mountain Lion on my MacBook Pro (13" unibody, MacBookPro5,5) and upgrading to 10.8.3 I'm having trouble with iMessage, Facetime and Back to My Mac. I am running Little Snitch (version 3.0.4) though turning it on or off has no effect on these results. My Apple ID works for other services.

System Preferences > iCloud: Turning on Back to My Mac gives the error "iCloud server not responding." (though it didn't seem to try very hard, looking at the network monitor)

iMessage: Attempting to sign in yields "Could not sign in to iMessage. Could not sign in. Please check your network connection and try again."

FaceTime: Attempting to sign in yields "Could not sign in. Please check your network connection and try again."

I've tried the following:

  1. Checked that my time is set, in the correct time zone, and set to automatically set itself.
  2. I checked Keychain Access > System for any Back to My Mac keys to delete. None present.
  3. I have no entries in /private/etc/hosts for *.apple.com or for *.verisign.com.

Of note: the serial number listed in About this Mac/System Information is incorrect and does not match the SN on the case (off by one letter--I think it was serialized incorrectly once after the logic board was replaced once). Would this affect iMessage/iCloud in Mountain Lion? It worked in Lion despite this. Sadly I am out of AppleCare coverage, but maybe a Genius would see the fault is Apple's and re-serialize the board.

1 Answer 1


The serial number may be an issue. When MacOSX thinks it is running on dodgy (i.e. non-Apple) hardware it usually has far more severe problems. There's no lockdown of an installation of MacOSX to a particular Mac, i.e. no DRM with keys and mandated validation with the vendor as with Windows. Apple cares most about people buying hardware, so the only "piracy" of MacOSX that they interfere with in code is running it on non-Apple hardware. But since my first version of this, I have been pointed at http://www.apple.com/support/icloud/contact/ by someone too polite to call m stupid in public, and that has strong sign of iCloud/SN linkage.

There's nowhere near enough info in the question to provide a sure answer to your problem, but there are clues pointing to possible issues. To figure it out, you should start by shutting off Little Snitch and the built-in firewall. You probably will want them back on eventually, but they should be off while you are trying to get complex services working to assure that they are not able to cause secondary blockage. And because you mentioned it, you get a rant: NEVER add entries to /private/etc/hosts on a modern MacOSX except for the 4 that the system needs for proper loopback initialization at boot time: IPv4 localhost and broadcasthost plus 2 forms of IPv6 localhost. if you have anything else in there, you should remove it. Once you've eliminated the possibility that your system config is explicitly blocking communication, you can look to the outside. All of those services include mechanisms to set up direct connections between 2 machines that may have IP addresses which are temporary and/or may be behind a NAT gateway that translates their traffic between a public and private (unroutable) address. Unfortunately, it is also possible for external network devices like routers and firewalls anywhere between the two ends to thwart those mechanisms. If you are behind a tight firewall, you will have trouble. If you are behind 2 layers of NAT, you will have trouble. Knowing what trouble you have isn't going to be discernible with toys like the Little Snitch network monitor, since the error you're getting probably involves just a handful of packets rather than any ongoing flow. To know what's happening you'd need to use a tool like tcpdump or wireshark and have an understanding of what you're looking at and looking for.

  • 1
    I shut off Little Snitch; the built in firewall is off. The reason I have things in /etc/hosts is twofold: 1) I don't want Adobe apps phoning home, and 2) I am running MAMP, which inserts entries automatically to correspond to local webservices that have been set up. I did try taking those host entries all out though and that did not help. Can you elucidate on why you feel one should not add hosts entries on a modern Mac system?
    – OxC0FFEE
    Commented May 17, 2013 at 19:25
  • Secondly, I have DHCP reservations on my systems on my router. UPNP is off. My IP, while not static, has not changed in the six months since I got this ISP (TWC). I tried tcpdump but didn't really know what processes or traffic to watch out for.
    – OxC0FFEE
    Commented May 17, 2013 at 19:27
  • 1
    The MacOSX resolver won't always use the hosts file and the world does more complex things with DNS than can be expressed in a hosts file. On top of that, Apple uses some surprising systems (e.g. MS machines!) as part of iCloud services, so an uncareful entry could kill them. It's not a certainly harmful thing to do, but has risks and there are cleaner & more robust alternatives.
    – Bill Cole
    Commented May 18, 2013 at 1:32
  • 1
    ALSO: see italicized corrections in 1st paragraph. I was wrong: the bad SN seems a likely cause. When that is resolved, you should re-enable LS. It is a cleaner/safer/more robust alternative to /etc/hosts for blocking phone-homes and does what the opaque (& historically dysfunctional) builtin FW is supposed to do with more clarity.
    – Bill Cole
    Commented May 18, 2013 at 1:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .