-
All replies
-
Helpful answers
-
Mar 10, 2013 9:29 AM in response to Easybourneby rogerchristian,I found this free app this morning and it solved my problem VERY easily, drag and drop to repair.
Called Permissions Reset
-
Mar 10, 2013 10:24 AM in response to rogerchristianby rogerchristian,The Ohanaware site is OK, but here is a direct link to the permissions repair download from Macupdate:
-
May 17, 2013 9:03 PM in response to rogerchristianby Ignolopi,Wow. That worked for me. Hours of time spent on my ridiculous mysterious permissions issue, 5 minutes with the Permissions Reset app and it's fixed. Kill me now.
Thanks!
-
Sep 1, 2013 5:35 PM in response to Easybourneby jfaughnan,This is an old thread, but I'll add a new fix inspired in part by an old post by jsd2.
In my case the GID inherited from Tiger (and earlier) was 502 -- that's every user was assigned to a group where the GID was equal to the UID. I found that by using ls -l.
Then I downloaded Workgroup Manager for Mountain Lion (10.8) and created a new Group with a specified GID of 502.
Like magic, OS X can now resolve the GID and it's all happy.
Lots of details here:
http://tech.kateva.org/2013/09/permissions-bug-in-os-x-fetching-forever.html
-
Sep 2, 2013 7:23 AM in response to jfaughnanby Tony T1,I remember this bug, back in 2008, when Leopard was released.
https://discussions.apple.com/message/7012995#7012995
Apple had a Support Document on this (no longer available), anyway, that fix probably wouldn't work on ML
I fixed it back in 2008 by Installing a fresh OS X, and then a manual installation of my programs and a manual copying of my home directory files. A pita back then, but glad I did it.
-
Dec 10, 2013 9:10 PM in response to Easybourneby kenspocket1,Heh, Same issue in Mavericks.
Here boy fetch!!
-
Jun 10, 2014 3:16 PM in response to kenspocket1by David Hill9,Like others here, I have been migrating one user account forward since the dawn of OS X, so I had lots of "Fetching" in Mavericks. I don't know how I didn't notice it earlier.
It turns out this is easy to fix, assuming that you know how to use ls, chown, and chgrp and have a little time to burn.
I've seen a lot of commentary about using utilities (Apple's and otherwise) to fix this and about making sure that your user account belongs to the correct group (staff). I'll attempt to boil this down to what little has to occur to make this work, without regard to exact steps.
1. Be sure your user account is a member of group "staff."
2. Set your home directory and all of its contents to group "staff" by using: chgrp -R staff /Users/Username
3. Using chmod, set your Home folder 755. Then using -R option, set all its subfolders to 700, with exception of the Public folder and (if you have retained one) the Sites folder... Public folder is 755, and the Drop Box in it is 733.
Comments on those points, by number:
1. I found this to be a distraction and waste of time, because the migration assistant had already done a good job of assigning my account to staff, so there was nothing to fix here. I'm guessing that step 1 has been a potentially confusing distraction for many here, because it's already done and does nothing to fix the actual problem, which is the fact that on older accounts all the home contents will have the GID set to match the UID. As in my case, ls -n showed that group for all my stuff was still set to 501.
2. Where this might seem counterintuitive is if you are looking at permissions in the Finder's Info window. Forget using the Info window, other than to verify that "Fetching" is gone once you're done. It omits so much as to be confusing... By default, as far as I can tell (using ls -l and ls -n on a freshly created Admin account for reference) every single thing in the home directory has staff as a group, even if staff does not appear in the Finder's Info window. The reason being that the Finder Info window will only display the group name if the file has a permission that allows the group to actually use it. Example: If your Music folder has a permission of 700 (rwx------) and a group of staff, Finder Info will omit staff simply because staff does not have enough permission to do anything with it. To test this, you can take any folder that is currently a 700 permission with group of staff, and open the Info window on it to verify that staff is missing; then with the Info window still open change the permission to 750, and you will see staff pop up in the Info window almost instantly.
-
Jun 10, 2014 4:44 PM in response to David Hill9by kenspocket1,Hi I tried the steps ,
I think maybe fetching has stopped.
Im left with _spotlight Read Only . on many usr lib files folders etc.
What is _spotlight user ?
TY.
-
Jul 6, 2014 8:55 AM in response to Andrew Dumkeby John Benninghoff,@Andrew: thanks, your post fixed my issue!
-
Mar 20, 2015 12:17 PM in response to Easybourneby Gib Henry,I solved this.
The reason it has caused so much confusion since 2007 is that we have all been describing it as a permission problem. Well, it isn’t a permission problem at all; describing it as such limits our thinking to permissions, and nothing you do with permissions will solve it—because the permissions are already correct! See for yourself: look in the Get Info or Inspector window, and you’ll see that the permissions are set to Read/Write, even though you can’t do either one. You didn't see that before because you were focussed on permission errors instead of ownership!
It is in fact an owner problem! You can't read or write because the file system doesn't know who the owner is. In the Get Info or Inspector window, add a new user (you) by clicking the + at the bottom of the Sharing and Permission section, and grant yourself Read/Write permission (isn’t that just what you wanted?!). That is sufficient for you to read and write, but to really clean up properly, click on the offending “fetching” user, and click the minus sign to delete it. Voilà! Problem solved!
I believe the problem comes about in migrating to a new machine when there’s some confusion about owner name vs. owner ID (e.g. 501, 502, etc.); e.g., your user ID was 502 on the previous machine, it's 501 on the new one, and the file in question isn't in your user hierarchy (e.g., it isn't in ~/). Cheers,
--
Gib Henry
