Recently, the iTunes app on our family server got out of whack and cast me into an infinite loop, requesting endless authentication before my iDevices could sync. It was turned out to be an interesting problem that not even Apple tech support could solve.
__________________
A few weeks ago, I wrote about how my boot drive had become so badly corrupted that it was not repairable. Apple’s disk utility suggested that I back up my files and repartition the drive. I wrote about that saga here: “Restore a Corrupted Boot Drive with Time Machine.”
One of the fallouts from that adventure was an immediate and brutal error message as soon as one our family’s iDevices tried to sync back to iTunes.
You are so screwed.
Then, in a vain attempt to re-certify the authorization, I went ahead and entered my credentials.
Let's try it.
Of course, that did me no good, and I got this message.
Oops!
What was frustrating was that, in time, the same error message would come up when the next sync to my iPad was scheduled. I could either get sucked into that endless loop or cancel out and wait for the message to pop up again later. I was feeling so, so annoyed.
A Casual Guess
I asked around with TMO team casually, and no one had seen this type of error before. One suggestion was to use my once per year option to deauthorize all my Macs and then reauthorize one by one. That made sense because I only had three Macs in play; somewhere along the way, I’d forgotten to deauthorize twos Mac before they were sold. Reauthorizing seemed like a good plan.
That did not work.
Support Forums
An inspection of some of the support forums turned up a similar case, and the best suggestion seemed to be to deauthorize the Mac, uninstall iTunes, reinstall iTunes, then reauthorize the Mac. That seemed like overkill, so I put that idea on hold.
Calling Apple
Under my AppleCare umbrella, I called Apple tech support. The first level of support was not helpful with this kind of nasty looking error, so I was passed on to an iTunes expert. She, however, was still reading from support scripts, and got bogged down in the process of deauthorizing and reauthorizing my Mac. We got nowhere.
Finally, she passed me on to an iPad expert. He was mystified also, and put me on hold for a few minutes to consult. While I was on hold, I decided to try something. Recall, that in the process of changing my boot drive, my Computer name (System Preferences -> Sharing) became different than the name of the boot drive. That’s okay. One should always be able to do that.
For fun, I changed the Computer Name to be the same as the boot drive, then in iTunes, I forced a resync to the iPad 3. (iTunes -> Device name -> Right Click -> Sync…) Voila. For the first time in days, 54 app updates and new purchases were seamlessly and quickly transfered back to iTunes. Joy! My Apple support specialist, happy to hear that my problem was apparently solved when he came back from the hold, closed the books on this incident.
NOT the End of the Story
But that wasn’t the end of the story. I was troubled by the idea that changing the Computer Name was the definitive answer to the problem, and I didn’t want to write a how-to article until I spoke with someone who’d been down this road before. I asked TMO’s Jim Tanous, a former Apple Genius about it.
After I explained what happened, his opinion was that the iTunes Preference file has become corrupted. This file has a list of authorized devices that are allowed to sync back to your master iTunes app — where your iDevices are backed up and synced. If that file becomes corrupted, he suggested, then you get the kind of error I first encountered above. This may not be definitive, but it’s out best working theory.
The thinking was that in the process of changing the Computer Name, I forced an update to the iTunes Preference file located at ~/Library/Preferences/com.apple.iTunes.plist. As a result, the list of authorized devices was rebuilt. This explains why reinstalling iTunes would solve the problem, but that’s vast overkill. Deleting the preference file and letting it rebuild is a better approach.
Lessons Learned
Sometimes we run across errors that look more insidious than they are. Error messages intended to reflect one kind of dysfunction are pressed into service for a similar error, but the distinction between the two cases isn’t surfaced to the user. As a result, the user can draw wrong conclusions about the true nature of the error. In this case, the state of my iTunes authorization.
Even more interesting is that one action, like changing the Computer Name, can have ripple effects and appear to be the problem when, in fact, all it does is trigger a series of OS events that drive deeper into the root cause. That’s why users develop and publish anecdotal techniques in the forums for solving problems that may not work for others. Indeed, might dig them into an even deeper hole.
Finally, I was thinking to myself that OS X, 11 years old, still isn’t clever enough to detect that the user is caught in an infinite UI loop. It would be nice if the OS had some kind of supervisor, a daemon that watches for endless UI loops and tries to intercede, delve into causes, make a recommendation or at least bring up Apple’s support phone number on the screen.
It’s been a long time since I had to delete a preference file, and if I hadn’t been distracted by the ominous and misdirected nature of the error, I might have tried that. Back in the earliest days of OS X, the corruption of plist preference files was a rampant problem. It’s so rare now that one can forget that it’s a practical trouble shooting technique for any app.
The journey (and lessons) with OS X continue.