11 Replies Latest reply: Jul 9, 2013 11:02 AM by Ravindra Holalkere
Ravindra Holalkere Level 1 Level 1 (105 points)

I use an MBP with ML 10.8.4. When I run DU either from start up or the recovery disk and click repair permissions, at the end there is a message that 'permissions repair complete'.  In that is indeed so, then when I run permissions repair immediately afterwards, why do the same error messages show again. I guess what I mean is that the second time there should be No messages about incorrect permissions, and at the end it should just say repair complete or better yet, no repairs were needed!

 

Am I understanding it wrong or is my DU not working correctly?


MacBook Pro, OS X Mountain Lion, 2.2 GHz Intel Core i7, 8 GB RAM
  • léonie Level 9 Level 9 (72,175 points)

    See this support article:

     

    http://support.apple.com/kb/HT1452

     

    and

    Troubleshooting permissions issues in Mac OS X

     

    Some permission error messages are harmless and will not be changed by running "repair permissions".

  • Barney-15E Level 8 Level 8 (41,410 points)

    It is working correctly, but why are you running Repair Permissions?

     

    There is no reason to just do that. If you have unusual file access problems in areas not in your home folder, or programs report not being able to access their data, then you might have a permission problem that can be fixed by repairing permissions.

     

    If it is problems inside your home folder, Repair Permissions in DU will not help.

  • nbar Level 5 Level 5 (6,980 points)

    If you have the same error message coming up for a specific folder, it is because the sharing and permissions on the folder has conflicting access information. IE: for a folder like "/var/root" the permissions list should be:

    System RW

    Everyone No Access

     

    If you manually change the permissions of this folder to see the contents, even after you change them back, the access changes to:

     

    System RW

    Wheel R

    Everyone No Access

     

    A folder with the permission structure such as ^this^ will show the same ACL error again and again (since wheel group includes root). In order to fix this, you need to delete "wheel" from the sharing & permissions column under the given folder information. I know it is weird, I reproduced the problem many times though...skeptics try if you doubt...

     

    Here is a very helpful tutoriol written by experienced community member on completely repairing permissions if they have become corrupted: https://discussions.apple.com/docs/DOC-2240

    and see this thread:

    https://discussions.apple.com/thread/4073179

  • Barney-15E Level 8 Level 8 (41,410 points)

    There is no reason to remove wheel. The wheel group was originally designed for the special group of users who could su to root. You should not remove it and the permission "errors" that come up are not errors.

     

    That first link is not for "corrupted" preferences. That is for when someone who doesn't know any better decides they should set everyone to "No Access" on their hard drive.

    The second is similar situation, but worse in that they "applied to enclosed."

  • nbar Level 5 Level 5 (6,980 points)

    If you modify the access on a locked file (var/root was my example) so as to allow 'admin' read access, the ACL warning will come up when repairing permissions even if you remove this access subsequently.

     

    "The wheel group was originally designed for the special group of users who could su to root. "

     

    With the following configuration:

     

    System RW

    Wheel R

    Everyone No Access

     

     

    You are both simultaneously granting permission and revoking permission, thus the cyclical ACL warning. Though you have removed admin access, the act of granting this permission to begin with is the 'su to root' part, which is why the system reverts to the ^above^ ACLs for the given folder.  It can be ignored safely, yes....the original question however included "why am i receiving the same errors" after repairing permissions. This is often the answer. Removing wheel sets access back to system defaults and the error no longer occurs.

  • greg sahli Level 7 Level 7 (24,680 points)

    Pretty sure this is what leonieDF was refering to:

    http://support.apple.com/kb/ts1448

  • léonie Level 9 Level 9 (72,175 points)

    Pretty sure this is what leonieDF was refering to:

    http://support.apple.com/kb/ts1448

    exactly - I could not find the link again - thanks

  • Barney-15E Level 8 Level 8 (41,410 points)

    With the following configuration:

     

    System RW

    Wheel R

    Everyone No Access

     

     

    You are both simultaneously granting permission and revoking permission,

    Not really. POSIX permissions can only be granted, not denied. None of those are Acess Control Entries (ACE), which would be part of an Access Control List (ACL). ACEs can both grant and deny access, but are in addition to POSIX permissions, which is what you are describing.

     

    Given that the example you used was a directory (root's home), it would have the following permissions:

    rwxr-x---

    Nothing is denied there. root, the owner (user), is granted read, write, and execute permissions; members of the group, "wheel" are granted read permissions, and all others are not granted any permissions. I suppose you could consider that as being denied, but that is the unix default: deny all, grant to the minimum necessary.

     

    Each three letter group above is the permissions for the Owner, Group, and Other (Everyone), respectively.

     

    System, which is root, is the owner (refered to as user in chmod) and has rwx permissions.

    Wheel is the group and has r-x permissions.

    Everyone, which is other in unix, is not granted any access.

    The owner, root, has read, write, and execute (read the directory contents).

    Members of wheel, which includes root, can only read and execute.

    All others can neither read nor write nor execute.

     

    If you were to share that directory using the File Sharing sys pref, you might attach an ACL to that folder, which would trigger the, "ACL found but not expected" note in Repair Permissions.

  • nbar Level 5 Level 5 (6,980 points)

    If you were to share that directory using the File Sharing sys pref, you might attach an ACL to that folder, which would trigger the, "ACL found but not expected" note in Repair Permissions.

    The only thing I was getting at was the last paragraph of your response. If you modify the Sharing and Permissions of /private/var/root, then set them back to the system default, and repaired the permissions, you would receive that note. If you removed wheel access to that particular folder subsequently, the note would no longer appear. This can be reproduced...just try it. That is all I was saying.

  • Barney-15E Level 8 Level 8 (41,410 points)

    Your example had no ACLs. It was all about changing POSIX permissions.

    It doesn't make any sense to report an ACL error when it has no ACls. But, then that is what happens when you Repair Disk Permissions and look at the output.

     

    And, why do you think /var/root should be rwx------?

  • Ravindra Holalkere Level 1 Level 1 (105 points)

    Thanks everyone for your replies. The reason I was trying DU was because in a fit of lunacy I went and changed the permissions level of Macintosh HD from 'everyone-read only' (or whatever the default was/is) to 'everyone-no access' and... got a scare since OS X stopped booting. Had already seen most of those links mentioned in the various posts during trouble-shooting, esp. the one from Neil was a life-saver, since DU repair permissions did not rectify the permission on HD back to its default nor show any messages about it.

     

    Thanks all for your time.