com.apple.AddressBook.InternetAccountsBridge[2010]: dnssd_clientstub ConnectToServer: connect() failed path:/var/run/mDNSResponder Socket:4 Err:-1 Errno:1 Operation not permitted

Same problem for me since upgrade to 10.11.2. I need to do more test but i think my iOS devices in version 9.2 have problem to.

i have upgrade server and client. Don't if problem come from server or clients

This is due to OS X's Internet accounts system, which manages accounts for things like calendars, contacts, reminders and notes.

It includes the processes accountsd (part of Accounts.framework), com.apple.AddressBook.InternetAccountsBridge and com.apple.AddressBook.ContactsAccountsService (part of AddressBook.framework) and others.

It's failing to talk to the mDNSResponder process, which handles Bonjour and dynamic DNS lookup. I don't know precisely why it would try to use mDNSResponder, but it's clear that someone at Apple screwed up when they configured the sandbox permissions.

In my case, the problem went away after I disabled and then re-enabled my Fruux account, under System Preferences -> Internet Accounts. I use Fruux (a third-party CardDAV provider) for contacts and reminders.

Flipping this bit seems to have cleared up whatever was stuck in the accounts system.

Disable all accounts. (This includes checkboxes next to things like "Calendar" and "Reminders" within the account settings.) Wait a few seconds. You should see the "connect() failed" messages no longer appearing in the log after this. Then re-enable.

I have the same problem on my retina MBP mid-2012. Connecting to mac mini address book server. Fails precisely with the same problem and log entry. The com.apple.AddressBook.InternetAccountsBridge does not seem to be able to connect to mDNSresponder when trying to resolve the server hostname which I entered into the InternetAccountSettings PrefPane. I spent the whole day debugging the stupid problem, giving up now.

Last thing I did was attaching lldb to com.apple.AddressBook.InternetAccountsBridge process and setting some breakpoints in _connect_nocancel, doing stack backtraces and function parameter dumps to verify what running truss on the process suggested before:

proc_info(0x8, 0x2FC, 0x2) = 0 0

socket(0x1, 0x1, 0x0) = 4 0

setsockopt(0x4, 0xFFFF, 0x1022) = 0 0

setsockopt(0x4, 0xFFFF, 0x1100) = 0 0

connect_nocancel(0x4, 0x7000001166F0, 0x6A) = -1 Err#1

__semwait_signal_nocancel(0xF07, 0x0, 0x1) = -1 Err#60

connect_nocancel(0x4, 0x7000001166F0, 0x6A) = -1 Err#1

__semwait_signal_nocancel(0xF07, 0x0, 0x1) = -1 Err#60

connect_nocancel(0x4, 0x7000001166F0, 0x6A) = -1 Err#1

__semwait_signal_nocancel(0xF07, 0x0, 0x1) = -1 Err#60

connect_nocancel(0x4, 0x7000001166F0, 0x6A) = -1 Err#1

close_nocancel(0x4) = 0 0

<<<< repeating a couple of times during spinning beachball session >>>>

So everything appears as if the com.apple.AddressBook.InternetAccountBridge process spawned from the AddressBook.framework via launchd lacks the necessary sandbox privileges to talk to mDNSresponder. Unfortunately I cannot seem to find the correct sandbox configuration .sb file that applies here. Maybe someone else can. Anybody here running a WD MyBook external HDD by the way? Probably not related, but the system complained some time before that the drive manager software was not supported on El Capitan and I have the vague feeling that things started to go south from there.

Apple, bugs like this one are acceptable in beta software and developer prerelease, not in .2 service releases. When I take a look at the system log it is full of error messages like the ones from this problem. Who knows what else is broken and which ones can safely be ignored. A snow-leopard-like cleanup exercise would be highly needed for OS X right now. I don't need new UI skins, GUI elements or Facebook integration, what I need is a reliable operating system I can work with.

Frustrated,

--j

I only had this issue after I did a completely clean install of 10.11.2 last night. (I had to do a clean install for some other reason)

I was very frustrated too and finally I restored these 2 folders from my old backup:

~/Library/Accounts

~/Library/Application Support/AddressBook

Now the issue is gone. So it looks like it is a bug in one of the latter OS version when saving these settings.

Hi Okrisz,

thank you for your reply. I haven't had time to try to debug this yet. However, I just applied the latest update, now running 10.11.3 and the behavior of the Contacts App improved a lot. I still see the spinning wheel a lot, but not as long and as often as before. The error log messages also disappeared.

Seems Apple fixed the issue. Very nice. Thank you!

--j

This seems to be a sandboxing issue, likely updated rules but the cache of the container not being removed/refreshed properly.

I destroyed my container for com.apple.AddressBook.InternetAccountsBridge and that seems to have resolved this issue.

Note the word DESTROY, there might be random data in there that you like. I did not notice any missing data afterwards, but be warned.

Possibly better to move the dir to a backup location or whatever. YMMV.

Open a Terminal, then go to the container directory:

$ cd ~/Library/Containers

and there remove the container:

$ rm -rf com.apple.AddressBook.InternetAccountsBridge/

Open Activity Monitor (or use kill -9 😉), and kill com.apple.AddressBook.InternetAccountsBridge, close/reopen Calendar.app and it should be soon there again and no more flooding log messages...

We are using Apple Server for contacts, What is see when i add the CardDAV account manually, the given port says 8443, if i check the port on the Contacts server its listens on port 8843. If i change it to 8843 in de Contacts App on the mac client it will not Save ! if i go to tab again the poort 8443 is back.

The strange this is, that the contacts are loaded form the CardDAV server, so there is a connection. But editing and adding Contacts works very slow, (Beach Ball) and some situations (very often actually) the changes are lost.

if i try to add the account with the Advanced option (where you give the server port), i get a authentication error, if i switch back to manual, i get a authentication error (with the same way i added the account before) if i restart the Contacts App i will be able to add it again with the manual option :S.

The contacts client looks very bugged.,,

This worked for me, closed address book, removed the .com folder in finder (not terminal), reopened the addressbook and manually entered the carddav (from OSX server) info. Had to give it some time to show up.

p4th

This seems to be a sandboxing issue, likely updated rules but the cache of the container not being removed/refreshed properly.

I destroyed my container for com.apple.AddressBook.InternetAccountsBridge and that seems to have resolved this issue.

Note the word DESTROY, there might be random data in there that you like. I did not notice any missing data afterwards, but be warned.

Possibly better to move the dir to a backup location or whatever. YMMV.

Open a Terminal, then go to the container directory:

$ cd ~/Library/Containers

and there remove the container:

$ rm -rf com.apple.AddressBook.InternetAccountsBridge/

Open Activity Monitor (or use kill -9 😉), and kill com.apple.AddressBook.InternetAccountsBridge, close/reopen Calendar.app and it should be soon there again and no more flooding log messages...

I've found a solution updating default app sandbox profile. But it require to disable SIP:

In

/System/Library/Sandbox/Profiles/application.sb

(unless (or (entitlement "com.apple.security.network.client") (entitlement "com.apple.security.network.server") (entitlement "com.apple.security.print") (equal? (param "application_bundle_id") "com.apple.AddressBook.InternetAccountsBridge"))
(deny network-outbound (literal "/private/var/run/mDNSResponder")))

Looked very promising at first, but unfortunately it didn't help.

I'm still seeing the errors in the log and the SBODs whenever I try to change anything in the address book. OS version is the latest (10.11.4).

I had the same kind of messages on my console from com.apple.AddressBook.InternetAccountsBridge. Repeated message about denial of /var/run/mDNSResponder appeared many times a minute. I made it stop by changing a setting. in "internet accounts" in system preferences. I had asked for the address book to be synced with two gmail accounts, one through google apps and one not. I turned off the sync for the non-google-apps syncing. Then after a few seconds of messages, the denial messages in my console log went quiet.

Perhaps other users seeing these console messages have the same kind of problem.

Related thread: CardDav sync issue after upgrading to 10.11.2

On other clients there is no VPN Client installed.

It's not just a VPN. There is no Check Point software on the other clients?