Repair permissions in terminal

[kgdrum]

Thanks my sump brother

[MIDI Life Crisis]

Thanks my sump brother

Your sibling from another sump.

Your brother from another basin.

People must think we're crazy... or just from the same part of New Yourk.

[mikehalloran]

The MAS lines only show up after DP installs or updates. There are a few other older apps that require Permissions Repair if installed in OS 10.11.6. Probably meaningless with DP 9; must be run after an install of DP 7 in El Capitan.

Permissions repair won't show anything if there's nothing to fix. When done, you'll see the command line prompt again.

[monkey man]

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

... and way, way above mine, Mike.

I've only fired DP up once thus far as I'm running Safari, Mail, iTunes, Contacts and so on for a while and refining their prefs and settings before I make an image of things as they stand before I delve into installing KLC, Slate VMS and DP9 or 10 down the track.

On that single occasion I opened DP 8.07, and I'm not clear on the details 'cause I was all over the place trying to set up my Sys prefs and so on after running the upgrade, but I do remember there being an issue with bringing the app into focus. I think I COMMAND-TABed to select it and also clicked the dock icon, but to no avail. I futzed around clicking and dragging windows a bit and I think I managed to bring it to the fore, but there was definitely some sort of issue. I ignored this seeing as I figured I'd be on DP9 or 10 by the time I bought the AVB system, and accepted the fact that it might as well be off-limits in the meantime.

Now I'm wondering if this monkey should play the lab rat and run the Terminal routine to see if it causes DP to "miraculously" run perfectly. I've rebooted during the interim, so I suppose it'd be fair to first fire DP up again to see whether or not the couple of reboots have cured the problem. If it's still flakey, the permissions "repair" approach could be "tested", could it not?

Again, way over my pay grade, but I sort of grasped what stratology and Mike were saying... very-vaguely sort-of...

[stratology]

Again, way over my pay grade, but I sort of grasped what stratology and Mike were saying... very-vaguely sort-of...

What I'm saying is simple: repairing permissions has the exact same effect as barking at the moon.


I'm still willing to offer a $10,000 bet: show me one verified example on El Cap where repairing permissions actually resolves an issue.

So, you describe an issue that you think repairing permissions will resolve, then take the bet.
If the issue is actually resolved by repairing permissions, you get $10,000 from me, if it's not, I'll get $10,000 from you.

Please, someone, take the bet.

[monkey man]

Firstly, I very-much understand the bottom line of what you're saying, stratology, that there's literally no effect; it's the techie details that're way beyond me, but again, I understand in-principle.

As for your incredible offer, how could we possibly verify that the running of the "repair" was responsible should DP run perfectly? Notice I used inverted commas both here and in my previous post out of respect for your contention that it's in effect a Clayton's process.

To say I'd love to partake in the bet would be an understatement of the highest-possible order, given that I'm now in the worst financial position of my life so far (the 1-vitamin E-capsule-a-fortnight level, I'm calling it, and I've already had two additional illnesses since having to radically scale back all supplementation and food quality which are both essential to my being able to "get by" given my autoimmune conditions).

I have two "problems" with participating 'though, unfortunately for me:

1) There's the verification issue I pointed out, and you can surely trust me as I don't have a dishonest bone in my body, but being cognisant of the way the world seems to work these days, I couldn't possibly expect you to believe me if indeed the routine "solved" DP's reluctance to play ball. I've thought of filming the procedure, but I've never owned or had access to a camera or any new-fangled mobile "device" for that matter.

2) If I lost the bet, I'd obviously not be able to cough up. I'm currently living on $80 a month after rent and bills, which, as I suggested, allows me to eat my cheap veggies and sustain a 1/7->1/14 normal-dose of the supplements I need. I've managed to take the next small step in putting my system together with a few on-sale plugins of late, but only through the ditching of some of my gear, and we all know how little that stuff's worth and how shallow that pit is.

I wish you hadn't have made the offer! LOL One of the threads of my life has been one of being so close, and yet so far, and I couldn't begin to tell you how shockingly-huge the effect winning that dough would have on it. Insane!

Anyway, I do hope that you can see that I'm in no position to judge the validity of your or Mike's position. All I can know for sure is that Mike appears to know his Mac stuff better than anyone I've ever "met", and that you appear to be all over it like white on rice too. The only difference between your perspectives, it seems, is that your take on this is based upon a solid grounding in Apple's programming and clearly-defined rules, along with your professional experience, whereas Mike's formidable one is drawn from, like yours, decades of professional involvement at one level or another (I think he currently maintains roughly 35 Macs), that is partly-shaped by years of DP users' troubleshooting endeavours. There wouldn't be a single long-term member here who hasn't seen multiple instances of permissions repairs' seeming to have cured various issues. I'm one of them. Most long-term users could probably say the same thing. Running the task immediately-following DP updates became the thing to do as a matter of course many years ago here, based upon the real-world efficacy of the process.

So, the fact that this under-the-hood stuff's so far beyond me it's not funny means I have no choice but to watch you guys nut this thing out whilst marvelling at the knowledge base you bring to the table. I mightn't understand the details, but I s'pose it's like watching a sport for which one doesn't know the rules - one can still derive pleasure from it if one gets the gist of it.

Lastly, I think I'll be shaking my head all day and trying to forget about the bet offer. I've never even seen that kind on dough, and must therefore find a way to erase the knowledge of your offer from memory! I admire your supreme confidence, which is no doubt well-founded, and this makes this debate even more interesting to me.

I can hear the trailer now [cue "that" trailer voice]:

"In a world... where few understand the deep, dark depths of the mothership...
two men... each shaped by his own passion... hardened by the fire of his battles with the behemoth...
strive to solve the great, unknown puzzle of our time... while we mere mortals shiver in awe.

Mikehalloran... stratology, and a cast of... dozens of Unicorns... in an epic tale of the search for the truth... at any cost.

The adventure of the decade.
Miss it without permission... and you'll surely... CRASH."

OK, so the "dozens of Unicorns" phrase lacked gravitas, but you get the idea. Pity I can't even afford popcorn at the moment. At least I've still got my 3D glasses I made using lolly wrappers I found at the local garbage tip.

[Exits pause mode by destroying play button with fist and reclines in fishnet hammock, banana in hand...]

Let the show resume!

[bayswater]

My suggestion is we just keep barking at the moon, or flinging poo at the moon (monkeys only please).

[stratology]

As for your incredible offer, how could we possibly verify that the running of the "repair" was responsible should DP run perfectly?

I wasn't referring particularly to DP, but to any kind of issue.

One way to verify that repair permissions resolves an issue would be to create a clone of the hard disk before permissions are repaired.

Anyway, if you're looking for any technical details, please just ask, I'll try to explain it (if I know anything about it ).


The main reason that I know that repair permissions never resolves any issues is from experience in a professional support environment. In 6 years of working full time, I only once heard a rumour that one of my co-workers had actually resolved an issue by repairing permissions. He was a new hire, and he also did a re-boot, so the consensus in the team was that it was most likely the reboot that actually resolved the issue. (It was some issue with the Flash plug-in in Safari..).

The Apple articles linked above, and the fact that the feature was removed in El Cap, are just additional indications of the lack of usefulness of the feature.


Most actual permission issues that show up come from users manually changing permissions, like doing a 'Get Info' on the Home folder or Macintosh HD, and applying the current permissions to enclosed items. Bad idea , and 'repair permissions' cannot solve these kinds of issues, of course.

[monkey man]

Dang! I'm guilty of doing that for sure, although not for a year or two now. Thank you for that, stratology. I'll no longer alter permissions from the GI window.

Given your tech-support experience where in all that time there was no definitive proof that the repairs of the various end-users had accomplished anything, it's perfectly understandable that you're supremely confident about this.

If I had to guess as to a possible explanation for the go-to status of the repair over the years in these here parts, I'd have to suggest that in many or most cases, folks rebooted for good measure as well. I certainly saw the "repair permissions and reboot" phrase more times than I can count.

Could this be it? Not being Mike, I'm tempted to say that yes, the fact that these two actions were most-often bundled together would indicate that this is a real possibility. We as a collective might've been fooled by Mr. Clayton.

That said, Mike seemed to have had a different angle on it when he mentioned the app's interaction with files unrelated to the installation itself (of DP). This is where I walk the plank and swim back to my hammock, dry my hands and get stuck into the popcorn! At least I'm learning stuff too. Just what, I've no idea, but I'm convinced I'm learning something.

Oh, and thank you once again for your contributions, stratology. I for one am loving this.

[Points at ball and blows whistle with gusto...]

My suggestion is we just keep barking at the moon, or flinging poo at the moon (monkeys only please).

You'll be relieved(!) to know that MLI is working on a Scatopult™, Stoivo. Mightn't reach the moon, but we're lookin' at a very, very long throw, mate.

[bayswater]

Mightn't reach the moon, but we're lookin' at a very, very long throw, mate.

That will be perfect. Remember, it must be ineffective.

[Phil O]

The supposed workaround sudo /usr/libexec/repair_packages starts with 'sudo', this is why it cannot execute successfully: under El Cap, the root user has no privileges to modify anything in /System and other system relevant folders (details linked above).
So even if the command finds 'incorrect' permissions (this is allowed when you use sudo, because it only reads file properties), they cannot be repaired, because sudo does not give the command sufficient privileges to change system files.

So here's what I don't understand. Why when I ran this command, did I get the following:
1) It asks me for a password
2) The script runs
3) It finds permission errors (and in non-Apple files)
4) It reports correcting the errors
5) If I run the script a second time, the errors are gone (suggesting that it changed something)
Seems to me like it's executing successfully. Or am I missing something.

Phil

[stratology]

The supposed workaround sudo /usr/libexec/repair_packages starts with 'sudo', this is why it cannot execute successfully: under El Cap, the root user has no privileges to modify anything in /System and other system relevant folders (details linked above).
So even if the command finds 'incorrect' permissions (this is allowed when you use sudo, because it only reads file properties), they cannot be repaired, because sudo does not give the command sufficient privileges to change system files.

So here's what I don't understand. Why when I ran this command, did I get the following:
1) It asks me for a password
2) The script runs
3) It finds permission errors (and in non-Apple files)
4) It reports correcting the errors
5) If I run the script a second time, the errors are gone (suggesting that it changed something)
Seems to me like it's executing successfully. Or am I missing something.

Phil

Were any of the files where permissions were supposed to be changed in /System, /bin, /sbin or /usr? These are the system file locations I was referring to.

What was the original issue you were trying to resolve? Did executing the command resolve it?

[monkey man]

Mightn't reach the moon, but we're lookin' at a very, very long throw, mate.

That will be perfect. Remember, it must be ineffective.

Lemme get this straight, Phil: You're reminding me of my M.O.?

Thank goodness for that; I almost forgot due to my "ineffective" memory. Ineffective lapses thereof would be a Godsend, of course...

OK, nothing to see here. Sorry. Let the game resume...

[Phil O]

Were any of the files where permissions were supposed to be changed in /System, /bin, /sbin or /usr? These are the system file locations I was referring to.

What was the original issue you were trying to resolve? Did executing the command resolve it?

I don't recall the locations. Some could have been in those locations as some were Apple files, but most were files from an install of DP.

The original problem was an inability to verify plug-ins subsequent to an install of DP. And yes, it solved the problem.

Phil

[stratology]

And yes, it solved the problem.

Meaning, you didn't take any other steps, like a reboot?