Mac OS X — admin vs wheel group (and how that affected CrashPlan)

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!

Comments

Somehow my install of CrashPlan suffered from the same issue: the group on the ‘/Library/Application Support/CrashPlan’ dir and its files was set to ‘wheel’. A simple sudo chgrp -R admin /Library/Application Support/CrashPlan allowed both the CrashPlan desktop and menubar apps to launch successfully. Frustratingly, the desktop app does not provide very good (read: any) debugging info — it just stop bouncing after 10 or 15 seconds without showing any UI. It was the menu bar app that helpfully logged its attempts to find the .ui_info file at each of the locations (user and global), which lead me to realize that it couldn’t read the .ui_info file because my user couldn’t read it either. :-/ sigh