MOTUnation.com

mikehalloran wrote: Do Repair Permissions in Terminal. Copy the following and paste:
sudo /usr/libexec/repair_packages --repair --standard-pkgs --volume /

Can you clarify how I do this?

Julia123 wrote:

mikehalloran wrote: Do Repair Permissions in Terminal. Copy the following and paste:
sudo /usr/libexec/repair_packages --repair --standard-pkgs --volume /

Can you clarify how I do this?

There might be another way, but I would:

Copy the command line Mike gave. Open Terminal (Utilities folder). Paste. Hit Enter. It will ask for your password. Enter password. Hit Enter again. Permissions repair will begin. When finished, quit Terminal.

Tritonemusic wrote:

Julia123 wrote:

mikehalloran wrote: Do Repair Permissions in Terminal. Copy the following and paste:
sudo /usr/libexec/repair_packages --repair --standard-pkgs --volume /

Can you clarify how I do this?

There might be another way, but I would:

Copy the command line Mike gave. Open Terminal (Utilities folder). Paste. Hit Enter. It will ask for your password. Enter password. Hit Enter again. Permissions repair will begin. When finished, quit Terminal.

That's the best way. If you type it in, it's too easy to make a mistake.

Terminal commands often tighten up with later versions of the OS. Generally, the later ones work backwards (there are exceptions) but earlier ones are often incompatible. Here's an example:

To show/hide files, the following set

defaults write com.apple.finder AppleShowAllFiles TRUE

killall Finder

defaults write com.apple.finder AppleShowAllFiles FALSE

killall Finder works in all builds of OS X.

This version, defaults write com.apple.finder AppleShowAllFiles Yes or No stopped working in OS 10.9—no matter how many web sites say differently.

Maybe a bit off-topic...I was just wondering if there's an advantage to Repairing Permissions via Terminal vs. repairing via Disk Utility.

For example, I run the sudo daily weekly monthly routines with Terminal (if my computer was shut down recently) just because it's quicker than using something like Onyx. Do they do the exact same thing?

Those of us who moved to El Cap have no choice. It's Terminal or nothing as it's been removed from Disk Utility. Also removed (but can be replaced) is the Quicktime 7 features...

https://support.apple.com/en-us/HT205081

Wow, you make me realize how out of touch I am with the current Mac OS. Thanks a lot for pointing that out.

For example, I run the sudo daily weekly monthly routines with Terminal (if my computer was shut down recently) just because it's quicker than using something like Onyx. Do they do the exact same thing?

Short answer: There is no reason to run daily/weekly/monthly repair routines. Many of the "problems" that are fixed are actually designed in to make your Mac run faster. Once you move to booting from an SSD, don't run Onyx or many other such utilities ever again—they can really slow down your system. De-frag, especially, has no value on an HHD since Apple went to SATA—on an SSD, it's a really, really bad idea.

The long answer is pretty long and goes into why.

Before OS 10.11, running Repair Permissions in Disk Utility is ok. It's not as thorough as some of the other ways but, for the DP user, it doesn't need to be. The other ways involve booting from the Repair Partition first.

Thanks for the helpful info, MH.

MIDI Life Crisis wrote:Those of us who moved to El Cap have no choice. It's Terminal or nothing as it's been removed from Disk Utility.

Wrong. It's also been removed from Terminal. If you look at the diskutil manpage, it states "Starting with Mac OS X 10.11, the verify- and repairPermissions verbs have been removed."

The sudo /usr/libexec/repair_packages command only repairs permissions on packages, so it's not a replacement for the 'repair permissions' command that was available in Disk Utility or via diskutil.


The reason Apple has removed the repair permissions feature is that it's superfluous. Repairing permissions as a troubleshooting step is an Internet myth, it never resolves any issues.
linky link

stratology wrote:Repairing permissions as a troubleshooting step is an Internet myth, it never resolves any issues.
linky link

... and yet your source clearly states in one rant, that it has fixed problems, even though he then denies he said it in another rant.

I've heard the "Permissions myth" story from more credible sources. An Apple tech who does maintenance for the local public school board tells me he has never had to repair permissions on his own Macs or on any of the huge number he has looked after, right back into pre OS X versions.

On the other hand, people here have had numerous experiences where DP installs didn't work, permissions were repaired, and then DP did work. That could be a coincidence if it happened a few times, but you could make the same argument about the sun coming up every morning. After a few thousand years, some might think it's more than a coincidence.

Need we quote Oscar Wilde here?

It's all above my f#%$ing pay grade...

bayswater wrote: On the other hand, people here have had numerous experiences where DP installs didn't work, permissions were repaired, and then DP did work.

In this old article, Apple explains that the 'repair permissions' feature never touches apps or files not installed by Apple (like DP or any MOTU installed files), nor anything in the home folder, or any user created files.


If you're wondering what a permissions repair actually did in the past, you can look it up in Console.app, in the DiskUtility.log.
Logs are searchable, so you can verify that nothing with, say, 'com.motu.' in the name was touched.

Presumably, there is more code being accessed in a DP session, than the DP code itself. Any file operation, for example, is presumably passed on to external code such as OS X. So while permission repair may not touch anything that a third party installed, it does not necessarily follow that repairing permissions will not have an effect on the performance of applications not installed by Apple.

I've heard reasonable arguments on both sides of this. But in my case, permissions are repaired as part of scheduled backups running in background twice a week. So unless someone can show how repairing permissions causes problems, I'll just let that happen.

Where to begin?

Wrong. It's also been removed from Terminal. If you look at the diskutil manpage, it states "Starting with Mac OS X 10.11, the verify- and repairPermissions verbs have been removed."

So what? That statement has the dual peurpose of being both correct and absolutely meaningless. With DP, it is the packages that need to be repaired.

Search this board. There are many threads that go something like, DP isn't… Repair Permissions… No, I read (insert armchair expert here) who says I don't have to… Repair them anyway… Hey, it works now.

DP 4.x through 7.24. If you had this problem and didn't do all the steps, DP would not authorize correctly:
http://www.motu.com/techsupport/technot ... issionsFix

Then this
http://www.motu.com/techsupport/technot ... -under-osx

If you did not repair permissions as part of either procedure, DP wasn't going to work.

Although Auth Files permissions were no longer an issue with DP 8, you do have these going back to DP 4 and they still show up after a DP 9 install—and users having issues till they are repaired.

Just for kicks, I did fresh installs, ran a little test and found problems with DP 7.24, 8 and 9 in El Capitan. I then ran Repair Permissions where I found the usual suspects:

Group differs on "Library/Audio/Plug-Ins/MAS", should be 0, group is 80.
Permissions differ on "Library/Audio/Plug-Ins/MAS", should be drwxr-xr-x , they are drwxrwxr-x .
Repaired "Library/Audio/Plug-Ins/MAS".

Ran the test again and there was no issue.

This is the best article I have read on the subject in El Cap.
http://osxdaily.com/2015/11/04/verify-r ... -mac-os-x/

Oh, I did test the command line in 10.8/9/10 and it runs but isn't as thorough as running it from Disk Utility.

A little bird tells me that Repair Permissions and Disk Utility are due for an overhaul to fix the problems caused by the current build in El Cap but they aren't likely to make their way into the next OS release.

bayswater wrote:But in my case, permissions are repaired as part of scheduled backups running in background twice a week. So unless someone can show how repairing permissions causes problems, I'll just let that happen.

You're correct that, when the feature was available, it didn't do damage. Didn't do any good either, like barking at the moon. I've worked in a professional support environment for years, there was not a single instance when repairing permissions actually resolved an issue. Simple things, like a reboot, or deleting prefs, are much more effective.