Sunday, September 01, 2013

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:

Screen Shot 2013 09 01 at 5 09 15 PM

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:

Screen Shot 2013 09 01 at 5 11 55 PM

or this ...

 Screen Shot 2013 09 01 at 5 05 44 PM

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:

- 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

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):

Repairpermissions

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.

2 comments:

Unknown said...

So have you been able to resolve the bug? It isn't immediately clear for me. I have been fighting it since I reinstalled Lion which, btw, has been my only and first ever OS X, no Migration or the like, and judging from Google references it dates back to the point on the timeline when the software was rolled out for the first time. My issue emerged once I decided - in the most stupidest move possible - to remove ACLs through an exec I downloaded from GitHub, battling another issue (related to Disk Util's ineptitude to repair some permissions, BTW) thus rendering FaceTime and iCal alerts notifications unusable. To restore functionality of both I was left with no choice but to reinstall OS X, which I accomplished via Internet Recovery, on top of existing files and folders (i.e., without clean reinstall), reseting ACLs for my home folder afterwards in addition. I regained the ability to use these apps but didn't take notice of the permission values since everything appeared working fine in every respect and only did recently. Though I doubted about utility of this whole "resetpassword-ACL reset" mantra from the beginning - as I resorted to it once - I though I'd give it a shot and - nothing. I still get this "Fetching…" group, so annoying! So resetting ACLs is not a solution. Are you saying we need to download "Server admin tools" which this Workgroup manager is bundled with and reset ACLs in the next step?

Unknown said...

Recently had a similar issue. Not sure how it occurred..I was creating a new Admin account and deleted the old one. At some point the "fetching" bug showed up..but only for one folder. All the files in the folder acted as though "write-protected". I wanted to edit a specific file, so I copied it to my Downloads folder. When I did this and did a "Get Info" on it, the permission was corrected..IE NOT "fetching". I copyied the file back to its original location..checked permissions..still OK..tried to edit..no go. So I copied the ENTIRE folder to Downloads..renamed the original "fetching" folder..then copied the folder from Downloads to the original location. Permissions corrected..folder and contents no longer "fetched" up. ;-)