10.5: Repair a user/group Finder crashing issue

Dec 12, '07 07:30:00AM

Contributed by: thinkyhead

If you've tried to edit the ownership of your files in Leopard's Finder, you may have seen in the Get Info window that many of your files and folders belong to a group called "unknown," and that when you try to fix them, the Finder crashes. This is because in older versions of Mac OS X, users belonged to their own private groups with the same ID number as the user (e.g., 501/501). But in Leopard, users now have a primary group membership of staff (20). Unfortunately, if you updated your system to Leopard using the Archive/Install or Upgrade method, your existing users were left with their old membership values, and Leopard doesn't quite love them.

Fixing the problem requires several steps, including editing your user accounts' hidden options, fixing group ownership of your home folder, and sending some obscure commands to directory services in Terminal via the dscl command. Whew! To make things simpler, I've written a simple bash script that makes all the necessary changes. And here it is:

#!/bin/bash
#
# Leopard User Fix by Thinkyhead
#
# Fixes the broken group membership in Leopard after an upgrade
#

if [ `whoami` == "root" ]; then
 echo "[ERROR] `basename $0` must be executed as an admin user (no sudo)."
 exit 1
fi

GID_IS_UID=`sudo dscl . read /Users/$USER | grep PrimaryGroupID | grep "$UID"`
GID_IS_STAFF=`sudo dscl . read /Users/$USER | grep PrimaryGroupID | grep 20`

if [ -z $GID_IS_UID ]; then
 echo "[ERROR] It looks like your account is already fixed!"
  if [ -z "$GID_IS_STAFF" ]; then
   echo "[ERROR] However, you are not a member of group 'staff' which is bad!"
  fi

 echo -n "Would you like to proceed anyway? (y/N):"; read PROCEED
 if [ -z $REPAIR ] || [ "$PROCEED" = "n" ] || [ "$PROCEED" = "N" ]; then
  exit 0
 fi
fi

#
# 1. Change User's primary group to "staff" (20):
#
	sudo dscl . changei /Users/$USER PrimaryGroupID 1 20

#
# 2. Make sure the user is in the "staff" group in Directory Services:
#

USER_IS_IN_STAFF=`sudo dscl . read /Groups/staff | grep GroupMembership | grep "$USER"`

if [ -z $USER_IS_IN_STAFF ]; then
	sudo dscl . append /Groups/staff GroupMembership $USER
fi

#
# 3. Fix group permissions on all items in the user's home folder:
#
	sudo chgrp -R staff $HOME

#
# ...or more slowly, but more accurately:
#
#	sudo chgrp staff $HOME
#	sudo find $HOME -group $UID -exec chgrp staff "{}" ;
#

#
# 4. Delete the group that's no longer in use:
#
	sudo dscl . delete /Groups/$USER >/dev/null 2>&1

#
# 5. Repair Permissions
#

echo -n "Would you like to repair permissions? (Y/n):"; read REPAIR
if [ -z $REPAIR ] || [ "$REPAIR" = "y" ] || [ "$REPAIR" = "Y" ]; then
  sudo diskutil repairPermissions /
fi

#
# 6. Reboot for safety.
#

echo -n "Logging out is recommended, but reboot is more thorough.nWould you like to reboot? (Y/n):"; read REBOOT
if [ -z $REBOOT ] || [ "$REBOOT" = "y" ] || [ "$REBOOT" = "Y" ]; then
  reboot
fi

exit 0
Save the script somewhere, and make it executable (chmod a+x scriptname), then run it to fix the problem.

[robg adds: As a reader on the queue review site noted, Apple has a different solution: create a group with the same group ID as your user ID, and make that new group your primary group. I'm not sure that this problem affects all Upgrade users, either -- my MacBook Pro was upgraded from 10.4 to 10.5, but it doesn't have this Finder crash on Get Info edit problem.]

Comments (12)


Mac OS X Hints
http://hints.macworld.com/article.php?story=200711291134001