Permissions bug in OS X: Fetching forever - SOLVED with Workgroup Manager (Bonus: Reset user account permissions with passwordreset.app)

See the update for how I finally solved this bug.

-

This is apparently a longstanding OS X bug that particularly affects veterans. I noticed it while debugging an odd behavior I noticed after a Carbon Coper Cloner operation.

When I look at permissions on some of my Home folder files I see this:

The Fetching is forever -- OS X is trying to resolve a reference that no longer exists. In a new user account permissions look like this:

or this ...

 

One cause of the bug is described by jsd2 in a 2011 Apple Discussion thread on the problem:

Newly created users in Leopard, Snow Leopard, and Lion have "staff" as their primary group, but users left over from Tiger have a primary group that has the same name as the username.  In my system, files and folders created by Tiger-originated accounts show the proper ownerships in Terminal, but if you Get Info from Lion's Finder, the Sharing & Permissions section apparently can't find the proper group name, and continues to display "Fetching…"  If I create a new account, it correctly shows "staff" as the group.

I tried creating a Group that matched my short username (jfaughnan) to see if that would fool Mountain Lion into eliminating the "Fetching" message but it had no effect. So, by now deep into this post, I continued on.

Next I used terminal (ls -l) to inspect permissions on one of those Fetching examples (edited a bit here)

drwxr-xr-x@ jfaughnan  502 

The sequence drwxr-xr-x should be read d rwx r-x r-x and it means this is a directory and it can User can read/write/execute, Group can read/execute and World can read/execute.

502 is my system assign UID (not to be confused with more modern UUID, both can be seen in User and Groups Advanced), but it's showing up here where one would expect to see Group ID (GID). 

Here's the result for a different account, created, I think, in Snow Leopard

drwxrwxrwx  Admin  staff 

In the 2nd case the GID is able to resolve to one of the Mountain Lion group names, which one can display with $ less /etc/group (or skip to the bottom of this post and check out workgroup manager):

nobody:*:-2: nogroup:*:-1: wheel:*:0:root daemon:*:1:root kmem:*:2:root sys:*:3:root owner:*:10: everyone:*:12: staff:*:20:root _appstore:*:33:utmp:*:45: authedusers:*:50:

In the first case the GID can't resolve to the Group Name, because in Tiger there was a GID set equal to my UID, in this case both were 502 - as jsd2 described above.

Now, at this point you might ask a dangerous question. You might point out that ls -l is only showing ONE GID/GroupName, but a file in OS X can belong to multiple Groups (these do). Well, cough, I think OS X permissions are broken. Indeed, while SharePoint 2007 was proof that Microsoft was broken, Mountain Lion permissions are proof Apple is broken.

It gets worse. I used the Finder to remove the 'Fetching' line from "Sharing & Permissions" on some of my old files. Doing this did not, as I expected, remove the '502' reference that shows up with ls -l. It made no difference to the ls -l results at all.

Which suggests to me that the real problem can't be exposed with these Unix permission displays. The real issue may well be buried in ACLs, or wherever OS X now keeps track of File-Group relationships. 

Which is where I end, because for me I think this "Fetching" thing isn't causing any real problems. I'll leave with only two additional notes:

• There's a way to allegedly reset permissions on the Home Directory from the Recovery partition by running 'resetpassword' in Terminal and then NOT resetting password but instead Reset Home Directory Permissions and ACLs. Darwin help you if you try this - it was documented by Apple for 10.5 but NOT Mountain Lion. Have several good backup first.
• If you want to explore further, try Workgroup Manager 10.8 (See OS X Server: Admin tools compatibility information). Fire it up, accept default of local machine, and give it your Admin account un/pw. Lots of interesting information there. When I looked into it I found a NEW Group with GID 503 that had same name as my UID. I wonder where that came from ...

- fn -

[1] I believe since Carbon Copy Cloner cloned my original drive this is the same UID I had then; migration assistant would have changed it. See: OSX Tips: Setting-up a new Mac from an old one, its backups, or a PC Problems after using Migration Assistant.

[2] useful Python command: python -c 'import grp; print grp.getgrnam("staff").gr_gid'

See also

• Gordon's Notes: Is there a club for people who hate OS X permissions? 1/2010

Update 9/1/2013: I've solved the Fetching forever bug. It was easy in the end.

This is what I did:

1. As above, I used ls -l to show me that the unmatched GID associated with the Fetching Forever bug was 502. In my case it was still the same as my UID. (I think ls -l shows one the PRIMARY group associated with a file, whereas Get Info shows all groups.
2. I used Workgroup Manager 10.8 to create a new Group I called Old502. I could have called it anything. The trick is that Workgroup Manager lets us specify the GID. I gave this group the GID of 502.
3. Now, instead of Fetching Forever, OS X Get Info shows Old502. Everything is as it should be, at the cost of an extraneous Group that does no harm.

Update 9/2/2013: In the course of another project (future post) I took a look at Apple's occult user account password reset tool.

I ran it from a booted Mountain Lion Install "disk" (SD card) but it might look the same from a Recovery Partition or Recovery Disk restart.  I started terminal and entered resetpassword, and, after a few minutes, I got this (I entered some values):

It's a weird and awkward UI and the app is obviously mis-titled and completely undocumented, but it appears that after years of confusing users with Disk Utility's near worthless Repair Disk Permissions there is indeed an official way to repair a user's Home Folder Permissions. I have a Disk Migration operation pending, I'm going to give this a try once the data is in place on  fresh Mountain Lion instance.

Update 9/9/2013: After I used migration assistant to move my accounts to a new system I think the permissions were reset back to the standard. The 502 bug persisted though, after I removed the Group I'd created for GID 502 I got 'Fetching' back again.