One more data point, which I encountered on another machine. I'd see updates, but the App Store would just lock up with the spinning pizza of death.
In the console log, I saw a bunch of messages along the lines of:
Sandbox creation failed: Saving after update for container (~/Library/Containers/com.apple.ShareKitHelper/Data) failed: NSCocoaErrorDomain:513 You don’t have permission to save the file “Container.plist” in the folder “com.apple.ShareKitHelper”.
Doing an ls -le on that file showed that there were complicated ACLs. It was probably the wrong thing from a security standpoint, but I removed them all and the App Store started working again:
chmod -R -N /Users/samuelg/Library/Containers/com.apple.ShareKitHelper
This worked for me. I don't know how I got bad ACLs on the directory or its contents. Disk Utility's "repair permissions" doesn't seem to look into the user's Library directory or fix problems there.
It's conceivable to me that your Library/Cookies directory has bad ACLs on it.
If you try:
ls -lde ~/Library/Cookies
and you see something like:
-rwxrwxrwx@ 1 yourname staff 66801 Sep 12 13:48 /Users/yourname/Library/Cookies
0: group:everyone deny write,append,writeattr,writeextattr,chown
you might try removing the ACLs. I don't really know the overall security implications -- I suspect it's not the safest thing to do -- but it might be at least an indicator of what's wrong. If it works, you can always try restoring ACLs one by one, so it's as locked down as possible but still functional.
I'm shooting in the dark somewhat, so keep that in mind. I know a decent amount about Unix, but I'm still fairly ignorant about the OS X extensions. I don't think this suggestion could cause any serious issues, but I can't guarantee that, so do this at your own risk!
You can remove the cookie directly in your account (`rm Library/Cookies/com.apple.appstore.plist`), when AppStore starts new cookie will be created. I think it's one of many hints in this thread and it does not work for me.
I tried deleting the plist too and it didn't work for me either - while the AppStore created a new com.apple.appstore.plist it was completely empty so it didn't work. Creating the file form another account and copying over worked (as that cookie is not corrupt/empty) - give it a try…
I try mohd hatta's suggestion below and it works for me now.
"navigate to Library/Preferences/SystemConfiguration and then delete NetworkInterfaces.plist
then restart ur mac, setting ur network and sign in app store"
Xie Xie to mohd hatta ~~ (Thanks in Mandarin [Chinese] to mohd hatta) James Liang from Taiwan
Thanks to all for their contributions. Unfortunately even the 'create a dummy account' option isn't working for me!
Pure speculation but I have a suspicion this is indeed tied into the network plist for some kind of newly rolled out copyright protection scheme that relies on the built in en0 MAC Address. I had a similar issue with Silverlight on the Mac I have with this problem, which is somewhat unusual in that the built in en0 is burned out and can't be created. So anything that relies on en0 being there dies a painful death.
Here's what mystifies me, though: If the bug does lie in a system-wide issue like the device's en0 MAC address, then why would App Store sign-in for a given Apple ID fail for one user account on the device, yet work fine for another user account on the same device?
That's my situation, which makes me think that the issue must lie in settings (Preferences, etc.) for the user account that can't sign in. Although my attempts to follow every suggestion and delete all possible offenders from the account's Library (and network.plist, etc.) is having no success.
(To clarify the situation: My main user account on my iMac has no trouble using my Apple ID for iCloud and other purposes, but simply cannot sign in to the App Store with that Apple ID. Meanwhile, another user account on my iMac can use that same Apple ID for App Store login, with no problem.)
Thus, I'm still looking for a user-specific issue causing the problem. No luck so far... : (
Hello: I experienced the same issue, after re-installing ML on a MBA that had previously had Lion and then been upgraded.
No matter what I did (and I followed all the tips in this thread and found on other sites) I still had that annoying error, however I didn't have the error on a differnet user acct on my same Mac.
Here is how I resolved it.
Since I had created the 2nd user, i had done nothing with that user _except_ test the App Store, using my original apple ID. It worked fine.
Then I tarred up the entire Library folder for that user into tmp, something like this:
2nd user$ tar cvf /tmp/2nd-Library.tar Library
Then I switched accts back to my primary user on the mac, the one that would not let me sign in to the App Store.
First, i backed up my existing Library (I used a 2nd drive, you can back it up wherever)
1st user$ rsync -avE Library /Volumes/DRIVE2/Library-Backup
Once that was done, I extracted the good Library tarball OVER my Library, and it would only replace files that existed, and fix whatever broken files were in there.
1st user$ tar xvf /tmp/2nd-Library.tar Library
I immediately changed ownership back to myself, then I replaced some things I know had nothing to do with the App store and I needed:
1st user$ sudo chown -R MYUSERNAME:staff Library/
1st user$ cp -rpf /Volumes/DRIVE2/Library-Backup/Application\ Support/AddressBook/* Library/Application\ Support/AddressBook/
1st user$ cp -rpf /Volumes/DRIVE2/Library-Backup/Keychains/* Library/Keychains/
1st user$ cp -rpf /Volumes/DRIVE2/Library-Backup/* Library/Calendars/
Then I ran App Store, and was able to sign-in, purchase and install apps.
I agree it's strange though I'm thinking we have an uncaught exception that's tossed all the way to the top level which is "unknown error" and that means we could easily have multiple issues covered here
Supporting: The various fixes posted are certainly working for some, while none of them have been effective for myself and others. This suggests it's possibly different core issues that all manifest with "unknown error".