Repair Disk Permissions: is it a safe operation ?

Question

Level 1

8 points

Repair Disk Permissions: is it a safe operation ?

Hello,

I'm preparing for the 101 course and, reading about the Verify/Repair disk permissions utility, I wanted to test it on my mac.

I launched the verification on it and I see "lot" of unexpected entries (see below):

******************************************************************************** ********************************************************************

Verifying permissions for “Macintosh HD”

Permissions differ on “System/Library/User Template/ar.lproj”; should be drwxr-xr-x ; they are drwx------ .

User differs on “usr/share/collabd/coreclient/public/locales/zh_CN.lproj”; should be 94; user is 0.

Group differs on “usr/share/collabd/coreclient/public/locales/zh_CN.lproj”; should be 94; group is 0.

User differs on “usr/share/collabd/webauthd”; should be 94; user is 221.

Group differs on “usr/share/collabd/webauthd”; should be 94; group is 221.

User differs on “usr/share/collabd/webauthd/locales”; should be 94; user is 221.

Group differs on “usr/share/collabd/webauthd/locales”; should be 94; group is 221.

User differs on “usr/share/collabd/webauthd/locales/zh_CN.lproj”; should be 221; user is 0.

Group differs on “usr/share/collabd/webauthd/locales/zh_CN.lproj”; should be 221; group is 0.

Group differs on “Library/Java”; should be 0; group is 80.

Permissions differ on “Library/Java”; should be drwxr-xr-x ; they are drwxrwxr-x .

Permissions differ on “System/Library/User Template/cs.lproj/Pictures/iChat Icons”; should be lrwxrwxrwx ; they are lrwxr-xr-x .

Permissions differ on “System/Library/User Template/hu.lproj/Pictures/iChat Icons”; should be lrwxrwxrwx ; they are lrwxr-xr-x .

Permissions differ on “System/Library/User Template/tr.lproj/Pictures/iChat Icons”; should be lrwxrwxrwx ; they are lrwxr-xr-x .

User differs on “usr/share/collabd/coreclient/locales/zh_CN.lproj”; should be 94; user is 0.

Group differs on “usr/share/collabd/coreclient/locales/zh_CN.lproj”; should be 94; group is 0.

Permissions differ on “usr/share/devicemgr/frontend/admin/zh_TW.lproj/app/javascript.js”; should be lrwxrwxrwx ; they are lrwxr-xr-x .

Permissions differ on “usr/share/devicemgr/frontend/admin/zh_CN.lproj/app/javascript.js”; should be lrwxrwxrwx ; they are lrwxr-xr-x .

Permissions differ on “usr/share/devicemgr/frontend/admin/ru.lproj/app/javascript.js”; should be lrwxrwxrwx ; they are lrwxr-xr-x .

Permissions differ on “usr/share/devicemgr/frontend/admin/ko.lproj/app/javascript.js”; should be lrwxrwxrwx ; they are lrwxr-xr-x .

Permissions differ on “usr/share/devicemgr/frontend/admin/nl.lproj/app/javascript.js”; should be lrwxrwxrwx ; they are lrwxr-xr-x .

Permissions differ on “usr/share/devicemgr/frontend/admin/it.lproj/app/javascript.js”; should be lrwxrwxrwx ; they are lrwxr-xr-x .

Permissions differ on “usr/share/devicemgr/frontend/admin/es.lproj/app/javascript.js”; should be lrwxrwxrwx ; they are lrwxr-xr-x .

Permissions differ on “usr/share/devicemgr/frontend/admin/fr.lproj/app/javascript.js”; should be lrwxrwxrwx ; they are lrwxr-xr-x .

Permissions differ on “usr/share/devicemgr/frontend/admin/de.lproj/app/javascript.js”; should be lrwxrwxrwx ; they are lrwxr-xr-x .

Permissions differ on “usr/share/devicemgr/frontend/admin/ja.lproj/app/javascript.js”; should be lrwxrwxrwx ; they are lrwxr-xr-x .

Group differs on “Library/Documentation/Applications/iTunes/Acknowledgements.rtf”; should be 0; group is 80.

Permissions differ on “Library/Documentation/Applications/iTunes/Acknowledgements.rtf”; should be -rw-r--r-- ; they are -rw-rw-r-- .

Group differs on “Library/Documentation/iPod/Acknowledgements.rtf”; should be 0; group is 80.

Permissions differ on “Library/Documentation/iPod/Acknowledgements.rtf”; should be -rw-r--r-- ; they are -rw-rw-r-- .

Group differs on “.DS_Store”; should be 80; group is 0.

Permissions differ on “.DS_Store”; should be -rw-rw-r-- ; they are -rw-r--r-- .

User differs on “Applications/.DS_Store”; should be 0; user is 501.

Permissions differ on “Applications/.DS_Store”; should be -rw-rw-r-- ; they are -rw-r--r-- .

Group differs on “Library/Preferences/com.apple.alf.plist”; should be 80; group is 0.

ACL found but not expected on “private/var/root”

ACL found but not expected on “private/var/root/Library”

ACL found but not expected on “private/var/root/Library/Preferences”

Permissions verification complete

******************************************************************************** **************************************************************************

It seems to me that these are all related to system files, things that weren't changed by third-party applications or by me.

The question are:

- why an untouched system would have errors in the permissions ?

- is it safe, since I haven't got until now problems with permissions on that os, to repair these errors or it's better to leave everything as it is now ?

:-)

Ciao,

Nicola

MacBook Air, Mac OS X (10.7.2), (11C74)

Posted on Feb 15, 2012 2:19 PM

Reply

Answer 1

Tony T1

Level 6

10,232 points

Feb 15, 2012 2:27 PM in response to Nicola F.

Repair Permissions.

Reply

Answer 2

Feb 15, 2012 2:33 PM in response to Nicola F.

Hello Nicola,

You raise a touchy area for discussion...some users on here are very opposed to repairing permissions, others are strongly in favor of repairing permissions before and after software installation.

The permission statements you see do not generally adversely affect the system but they are not the permissions disk utility has been told to expect. Those may be artifacts from the installation process and why we have been told in the past to always repair permissions after installing/updating the operating system.

Since you ran verification, if you run repair you will end up cleaning up a lot of this "discrepancies" with what disk utility wants to see.

Repair permissions is safe, and I tend to use it every time I upgrade or install software.

Ralph

Reply

Answer 3

Nicola F. Author

Level 1

8 points

Feb 15, 2012 2:47 PM in response to Ralph Landry1

Thanks, I was just worried about "false positive" problems reported, since I was not expecting them...after the repair I still have three entries:

ACL found but not expected on “private/var/root”

ACL found but not expected on “private/var/root/Library”

ACL found but not expected on “private/var/root/Library/Preferences”

but I'm pretty sure that these are related to the fact that I activated root login for testing (now it's deactivated) and at that point the system applied ACL to those folders...

Regards,

Nicola

Reply

Answer 4

Feb 15, 2012 2:54 PM in response to Nicola F.

Entirely possible.

And if you were to run repair again the "errors" may not appear at all.

Disk utility is nothing more than a user-friendly form of the Unix fsck command, if you have delved into the operating system very far. If you are familiar with fsck we are always told to run it, if we get any final statement other than all is good, run it again, until it says all is clean. We don't usually do that with disk utility but if you are serious about learning the operating system and its inner workings, give it a try and see what happens.

Another note: one should always run the version of disk utility on the startup drive for permission repair, it knows more about what it needs to see than the version on an install disk.

Reply

Answer 5

Tony T1

Level 6

10,232 points

Feb 15, 2012 4:21 PM in response to Ralph Landry1

Ralph Landry1 wrote:

You raise a touchy area for discussion...some users on here are very opposed to repairing permissions, others are strongly in favor of repairing permissions before and after software installation.

No one "here" is opposed to repairing permissions.

Reply

Answer 6

Feb 15, 2012 4:24 PM in response to Tony T1

There has been some heavy debate over repairing a few months back...some strong opinions about not doing so.

Of course, the present company seems to be of a like mind 🙂

Reply

Answer 7

Tony T1

Level 6

10,232 points

Feb 15, 2012 4:39 PM in response to Ralph Landry1

Well, there is always debate as as to whether or not repairing permissions will solve a specific issue (seems that it is the #1 suggested solution for every problem 😉), but in this case, the OP only wanted to know if it was "safe" to repair (...and we both agree that it is)

Reply

Answer 8

babowa

Level 9

78,103 points

Feb 15, 2012 4:46 PM in response to Nicola F.

And here is a list of items you can safely ignore if they are still present after the repair:

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

It may not be necessary, but doing it sometimes does help, so make your own decision. I repair after any update or software install (I don't bother with the verify - I just hit repair).

Reply

Answer 9

Nicola F. Author

Level 1

8 points

Feb 16, 2012 2:11 AM in response to babowa

Perfect! 🙂

I could maybe schedule the disk utility (or play with cron and fsck) to do it periodically...?...but I'm the only user on that os and I'm not installing new software frequently, so I think it's easier to run it manually after big installations or updates...

Thank you all !! 😎

Ciao

Nicola

Reply

Answer 10

Barney-15E

Level 10

112,638 points

Feb 16, 2012 4:29 AM in response to Nicola F.

You don't need to do it periodically. You only need to do it if you get file access problems within the System level of your folders. Additionally, there isn't any other "maintenance" you need to do periodically.

Reply

Answer 11

Vernonya

Level 1

14 points

Jan 27, 2015 2:13 PM in response to Nicola F.

Hi I noticed that your Repair Disk permissions and when we come to the . DS-Store it says ' user should be 0, it is 501'. What does this mean ? It has just come up on my own disk repair . Is 501 significant, and why have I, the user, been changed to 501 ?

Reply

Answer 12

Barney-15E

Level 10

112,638 points

Jan 27, 2015 5:32 PM in response to Vernonya

It means the folder is not in your home library so the .DS_Store should be owned by root (0), not you (501).

Reply