Last week my wife’s four-year old iMac died. When the new one arrived, I set it via migration in the form of a USB-connected drive containing a mirror of her old system.
After booting up the migrated machine, I ran into an issue in which the CrashPlan app wouldn’t start, and the menubar app reported “Can’t connect to backup destination”. I tried running the CrashPlan uninstaller, and then doing a fresh install, but unfortunately it didn’t help.
Checking the console, I found messages reporting that the file “.ui_info” couldn’t be found in the directory
/Library/Application Support/CrashPlan. Which was strange, since I could clearly see that file existed in a Terminal directory listing.
What I also noticed was that the CrashPlan directory was owned by the “wheel” group, while most of the other directories in Application Support were owned by the group “admin”.
I then tried manually deleting the CrashPlan directory in the Terminal, and running the CrashPlan installer again. This time, the CrashPlan directory was owned by the “admin” group—and, consequently, the CrashPlan app successfully started up.
This experienced prompted a couple of observations:
- Even when authenticated by an admin user, the CrashPlan uninstaller was unable to remove its CrashPlan directory in Application Support.
- A fresh install of CrashPlan didn’t set the correct group ownership of the CrashPlan folder in Application Support, which led to the app being unable to start.
- I have the impression that the “wheel” group may have been deprecated at some point in the OS X evolution, but still getting passed on from machine to machine in migration upgrades. I wonder whether it would be a good idea, or even safe, to do a global change of anything on the computer owned by “wheel”, changing it to “group”?
If you know the answer to the third, please let me know in the comments. Thanks!