Disk Utility will not repair permissions

disk-utilitypermission

I have tried to repair permissions multiple times using Disk Utility.app and also using the command-line diskutil. I always get the same output, so apparently it's not fixing the problem. I've also tried running it from the Recovery partition, and get the same result.

$ diskutil repairPermissions /
Started verify/repair permissions on disk0s2 yosemite
Permissions differ on "tmp"; should be drwxrwxrwt ; they are lrwxrwxrwt 
Repaired "tmp"
Permissions differ on "Applications/Safari.app/Contents/Resources/Safari.help/Contents/Resources/index.html"; should be lrwxr-xr-x ; they are -rwxr-xr-x 
Repaired "Applications/Safari.app/Contents/Resources/Safari.help/Contents/Resources/index.html"
Warning: SUID file "System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent" has been modified and will not be repaired
Permissions differ on "Applications/Safari.app/Contents/MacOS/SafariForWebKitDevelopment"; should be -rwxr-xr-x ; they are lrwxr-xr-x 
Repaired "Applications/Safari.app/Contents/MacOS/SafariForWebKitDevelopment"
Finished verify/repair permissions on disk0s2 yosemite

The ARDAgent issue can be ignored, according to Apple.
The other three problems are all related to symlinks, and it seems to me like the current perms are correct. Why does Disk Utility think there is a problem?

I'm on Yosemite 10.10.5.

Best Answer

Using answer space for formatting & 'comment size', I'm not sure this is really a full 'fix', but perhaps a pointer in the right direction. It can be updated/amended to get to the correct answer, if needs be.

Note: Permissions on symbolic links have no effect. You need to check the permissions on the target file/directory - though in fact the perms are 'correct' in this case, it's the links themselves that are not as expected.

Permissions differ on "Applications/Safari.app/Contents/Resources/Safari.help/Contents/Resources/index.html"; should be lrwxr-xr-x ; they are -rwxr-xr-x
means that the Finder thinks that file ought to be a symbolic link, but it isn't - the link has been broken somehow.

On my machine, that link is to /Library/Documentation/Resources/Eagle/index.html

Fix == remake that link
From OSX Daily:How to Create Symbolic Links at Command Line of Mac OS X

How to Make a Symbolic Link
The basic syntax for creating a symbolic link (or soft link) is as follows:

ln -s /path/to/original/ /path/to/link

That will point /path/to/link to the original location, in this case /path/to/original/

Permissions differ on "Applications/Safari.app/Contents/MacOS/SafariForWebKitDevelopment"; should be -rwxr-xr-x ; they are lrwxr-xr-x
thinks that one should just be a file... but it's a link.

Mine is a link too, on El Capitan - [which I'm assuming you're not on, as you still have a 'Fix Permissions' option in Disk Utility] - to /Library/Application Support/Apple/Safari/SafariForWebKitDevelopment

I'm tempted to say in that case, leave it as is.
Checking perms on El Capitan from terminal gives no error on that one.

Edit:
I missed the first one -
Permissions differ on "tmp"; should be drwxrwxrwt ; they are lrwxrwxrwt

Mine is a link too - to /private/tmp so I'd leave that one alone too.

Related Question