When the keychain locks up your Mac

Mac OS X’s keychain system is a great feature, but there are times when it doesn’t behave quite the way it should. Sometimes your keychain file develops mild corruption, and a quick run of Keychain Acccess’ Keychain First Aid function patches things right up. But other times more involved troubleshooting is called for.

At some point back in April or May, my MacBook Pro developed a nasty keychain-related problem relating to Personal File Sharing. After a batch of security and other updates, whenever I tried to connect to one of the other computers on my home network, I’d get the now-familiar dialog stating—and I’m paraphrasing here—“[XYZ] has been updated; do you want to update the keychain to allow access?”

(Basically, this is OS X’s way of saying, “Hold on, partner; there’s a new version of XYZ on your machine that wants the same access to your passwords that the old version had.” If you’ve indeed updated XYZ recently, you agree and get on with your day. But if you haven’t installed a new version, or installed an OS X update that did so, this is a warning that there might be some sort of malware posing as that application in order to gain access to passwords.)

Since I’d just installed an update that affected file sharing, I clicked the button to approve the update to my keychain, and then waited... and waited... and waited. The dialog remained on the screen and the entire computer became unresponsive. My MacBook Pro was effectively a big, shiny paperweight. Thinking this was a random glitch, I force-restarted, got back up and running, and tried to connect again. And watched the machine freeze up again. And restarted again. Basically, the computer worked flawlessly until I tried to connect to another Mac for which I’d previously saved my file-sharing password to the keychain. Such attempts resulted in Beachball Bonanza.

(I eventually discovered that if I waited 15 to 20 minutes, the dialog went away and I regained control. But who wants to wait that long to connect to another computer when they’re trying to get work done?)

After a few more bang-my-head-against-the-wall attempts, I gave up. I was too busy to spend the time necessary to isolate the cause, so I put the problem on the back burner and just avoided connecting directly to any shares. Thanks to DropCopy, I was able to transfer files to other Macs, but I was still anxious to be able to use standard file sharing again.

Then, last week, I happened to come across an interesting article over at Unsanity.com. Written back in January, it described a similar keychain-authorization problem experienced by an Unsanity staffer. Except, unlike me, the staffer had the time—or at least the unbridled curiosity—to track down the problem.

As it turns out, the cause in that case was a corrupted file deep inside the invisible /var directory; specifically, /var/db/CodeEquivalenceDatabase. Because of this corruption, securityd —a background process that handles keychain access—kept trying and trying to access the file, sucking up RAM in the process and eventually overwhelming even OS X’s impressive memory management system, grinding the system to a halt. Deleting this file fixed the problem.

Figuring I had nothing to lose, I opened the appropriate directory (by using the Finder’s Go To Folder command and typing /var/db ) and moved the file CodeEquivalenceDatabase to the Trash (which required me to provide my administrator name and password). I then restarted. As Steve Jobs would say, “Boom!” The problem was gone. And I noticed no ill effects from deleting the file.

So thanks to Unsanity, I can now access my other Macs from my MacBook Pro. And you, the reader, can visit the original Unsanity article and get a glimpse of the troubleshooting approaches the pros use; specifically, the use of the fs_usage command.

Related:
  
Shop Tech Products at Amazon