Hint: the entire article is in the RSS. You may want to truncate what shows up in there.

Time to actually read it. ;)

Interesting read. I know that I often spouted "hey, try repairing permissions" when someone was having a problem with something that sounded like a file-specific permissions error, mostly because that's what everyone else teaches.

Do apps running in Classic mode on OS X cause that kind o' chaos?

No. They are forced to respect OS X permissions. And unless they (you) own the files, they cannot modify the permissions of them. Sandbox.

Can't refute what you have here, but then again, you're saying that everyone who has had a problem, repaired permissions, and had it go away is lying? It's a huge conspiracy? Come on, sometimes permissions DO get borked (almost always by bad installers).

Don't forget that LOTS of poorly done installer packages include every folder in the path to where their files are, rather than using ./blah (and even install useless .DS_Store files along the way). These installers frequently overwrite permissions where they shouldn't (usually on library directories). Repairing permissions will fix that.

Finally, there's good reason to try repairing permissions - it's quick, completely non-destructive, and a LOT of weirdness can occur from bad permissions. If it works, great. If not, you lost a few minutes. Big deal. If something does bork because of bad permissions somewhere, I'll place bets you'll spend more than those few minutes diagnosing and fixing it.

Programs tend to go mildly nuts when they suddenly can't read from or write to some file, and it can be hard to tell why sometimes. Hell, I had disk images that wouldn't mount or copy recently due to bad permissions on an NFS mount (read-only). Why the system wanted to write to them, I didn't know at the time, but it failed, and failed in bizarre ways, with lots of "-2", "-16", and other helpful error messages (it turned our it needed write permission to "scan" the image before restoring it to a disk). Would the Disk Utility "Repair Permissions" fix that? No. However, it's a good example of seemingly unrelated problems going back to permissions.

Quite bluntly, I doubt you have all-seeing into every random schmoe's setup and what weirdness they've done to it. The vast majority of people have no problem with any OS upgrade. Those that do have problems have all kinds of hell break loose due to God knows what, and it appears that fairly frequently repairing permissions FIXES IT, whether it makes sense in your ordered little drive or not. Somehow, at some point, some permissions got screwed up. Bad installers, bad users, missing receipts; whatever the case, there's a mountain of (anecdotal, yes) evidence showing that for a lot of people with borked system, permissions were ultimately the problem, and repairing them ala Disk Utility fixes it.

Or are all the users writing into MacFixit liars?

"an't refute what you have here, but then again, you're saying that everyone who has had a problem, repaired permissions, and had it go away is lying? It's a huge conspiracy? Come on, sometimes permissions DO get borked (almost always by bad installers)."

Yes, i am saying exactly this. People that say it fixed their problem usually try about 5 other things too. And one of those is what actually fixes it.

Let's take your NFS volume problem for example. Someone would have recommended repairing permissions to fix that problem. But repairing permissions wouldn't have touched it, as you said.

The point isn't that things don't go bad because of permission issues. The point is that using disk utility to repair permissions won't fix these kinds of permission problems.

If one of those bad installers happens to change permissions on a path item (which all the major ones have defaulted to off now, even Apple's PackageMaker), *everything* would break. Not just "weird" things. But everything. As you can see if you try the Library example. The biggest problem buggy installers create is giving something too much permissions. Which doesn't cause weird problems like the people at MacFixIt describe.

"Bad installers, bad users, missing receipts; whatever the case, there's a mountain of (anecdotal, yes) evidence showing that for a lot of people with borked system, permissions were ultimately the problem, and repairing them ala Disk Utility fixes it."

Forgot to respond to that. If a receipt is missing, then any files that were installed along with that receipt won't have their permissions fixed while repairing permissions anyways.

I would agree with you that the only thing repairing permissions does is reset permissions for any file/folder with a receipt. You are absolutely correct that repairing permissions can have as little effect on solving a problem as say, resetting the PRAM can fix directory corruption. I do think that your "bitterness" is blinding you to some obvious truths. I have, for over 3 years supported up to 50 unique customers a day, all running various versions of OS X, and I can say with some authority that repairing permissions CAN fix a lot of random problems. Yes it is important to understand what repairing permissions does, and that it is not a miracle cure all, but to have the mindset that it serves no purpose is pretty silly, or is coming from someone who has done little hands on support with more than a handful of customers.

BTW, doesn't Apple's packagemaker still allow anybody who writes a package to specify to overwrite existing directory permissions? There is a difference between writing a package that installs an application in the Utilities folder, and a package that installs the entire folder path /Applications/Utilitites/application.app. The later completely re-writes the directory paths permissions settings.

Realize I am not questioning your main point: permissions only fix what they know about. But there is a point to having the ability to repair permissions. I think I will stick with the other 99.9999% of the people who agree that quick fixes can be just that, quick and occasionally, um, fix stuff.

In all the time it took you to write that you should have had the whip to Briens' back to get Silk Tiger compatible......... ;)

Eric, what you say is true about PackageMaker, however that option is off by default. I'm not sure how long it has been off by default, but it has been a while.

And think about the possible permissions for any component of /Applications/Utilities/Application.app as well. Either it is set as having too much write access (in which case nothing breaks, but anyone can install into /Applications or /Applications/Utilities but nothing else becomes writable) or you remove the read access from /Application/Utilities/ which breaks *everything* as you wouldn't be able to even see any app, let alone execute them. This is what makes it extremely hard for permission issues to cause "weird" problems after an install. Having everything break doesn't fall under the category of weird, it falls under the category of rendering the computer virtually unusable.

And if the permissions on /Applications/Utilities/Application.app are wrong, it won't matter since repairing permissions will just make them wrong again.

Are you going to fix the numerous problems with the Fruitmenu update for 10.4? (See, for example, all the comments at http://www.versiontracker.com/dyn/moreinfo/macosx/12974&mode=feedback .) Like others, I have serious delays when I click on the menu, and I am unable to change the names of Applemenu items.

I've tried repairing permission, but for some reason even that doesn't help...

Hmm, from my Disk Utility log and my latest repair permissions:

Repairing permissions for “HD”
Determining correct file permissions.
Permissions differ on ./Library, should be drwxrwxr-t , they are drwxrwxr-x
Owner and group corrected on ./Library
Permissions corrected on ./Library

Ok, if not bit rot then what? Somehow the sticky bit on the /Library directory was turned off. Probably not a huge issue but there are security implications. I'm guessing it was Retrospect but who knows. Anyway, running repair permissions after an install insures that things like this are fixed before problems occur. I'm not saying that there is any magic, but why the rant? At worst, fixing permissions is harmless.

Pretty bold statement to make ... "Permissions won't magically go bad. They won't break suddenly. They don't suffer from bit rot."

They do suffer from bad vendor applications, poorly made scripts, and gasp ... filesystem errors. I think it's more bad than good to state something as bold as what is stated above. Fixing permissions is an important part of the process in keeping your drive in a good working state. If you don't believe that you are in the wrong business, flat out.

It's not the end-all and be-all of disk maintenance, but saying that it's pretty much useless is misinformation. Try running on an open directory based network sometime and then you might want to revise your article here a bit...

Oh and by the way ... zapping PRAM is also not a "useless" thing to do, it has it's time and place as well. people who _think_ they are well informed and insist on sharing their misinformation with others are a worse disservice than the websites that say that fixing permissions and zapping your PRAM will solve all your problems as readers take this more to heart than a generic troubleshooting tips sort of self-help article :P

So you're trying to say that if you have corrupted NVRAM settings and broken permissions it's not a big problem? LOL

What's running an Open Directory based network have to do with running repair permissions?

If file system errors are causing permissions to change, you have far worse problems than what repair permissions handles.

And no, repairing permissions isn't an important part of the process. That's saying it should be used as a maintenance task. And that's useless.

jdb, why do you guess it was retrospect? Did you just restore a backup or something? The rant is because the first step people always seem to ask people while troubleshooting is "did you repair permissions?" which is useless. That's like calling AOL and having them ask you if you own a computer.

When a renegade piece of software mistakenly sets the permissions of /Applications to read-only, or when a bad install program carelessly opens /etc to full read-write access to everyone, Disk Utility's "Repair Permissions" function is very useful. (I have had BOTH of these things happen to me in the pre-Tiger days.)

Now, sure the user can finesse the problem and isolate all variables and control his environment and employ sound QA methodology (in order to determine whether wrongly altered permissions is the issue) or he could just periodically run a few modest procedures. It doesn't take very long -- so what's the harm? If it proves not to address the issue, the user is always at liberty to look elsewhere.

My parents use OS X, and I'm not about to have them run "sudo" or log in as root, go into a command shell, and contend with what to them would be an incomprehensible syntax of chmod and chgrp. How about you?

Apple did not include this (repair permission) function gratuitiously or devoted development time on it just so novice users would think they are accomplishing something by running it even when in fact they would only be wasting their time.

For my part, I just consider it a surgical "rollback to defaults." I wish Tiger had the ability of Windows XP to perform complete rollbacks to pristine states of the OS, but if we are to take a more granular approach, better to do it utility by utility than not at all. And default permission values is part of this rollback. (And if this is no conseqeuence, again I ask why Apple would bother with setting specific permissions to begin with.)

As an addendum to my previous post, I wish to point out that after having been apprised (by the author of the article above) that repairing permissions is "useless", he nonetheless proceeds eventually to acknowledge that it does indeed fix SOME problems.

Okay -- so it's not a cure-all. I'll even grant that it will fix only a fraction of the problems a user may encounter. So what?

Under Tiger, how often would you say a reboot fixes a problem? I think it's testimony to the OS that the answer to this question is almost never -- because it's not necessary the vast majority of the time (unlike the old days of System 7, 8, and 9). But the fact is that rebooting DOES solve some flaky problems that arise. It may not address the fundamental issue and instead it may only treat the symptom, (such as when there is a memory leak at work), but on some occasions rebooting will restore a system to full operation.

Can we then expect another article from you which says that rebooting is useless?

I was wondering where the old APE icon went...I guess Adobe adopted and renamed him Space Monkey.

someone implied that rosyna doesn't handle very many customer support issues...this statement is false.

someone else asked that rosyna get "brien" to finish up on silk. Last i checked, rosyna did silk (not sure if this is helping) and "brien" does, um....uh....

uh
um

Jeff, if a renegade piece of software set /Applications to read only, you wouldn't be able to launch any applications (all hell breaks loose category). What software is installing things into /private/etc/ that it is changing the permissions of it? If /etc/ has its permissions changed it isn't really too much of a big deal as it is just a symlink to /private/etc/. I'd be far more worried about a third party package overwriting the /etc/ symlink with a real folder and causing OS X to fail to boot.

If you look in the "A bit of history" section, you can see why Apple included repair permissions.

And yes, for the last year or so I've been repairing permissions after an install in preparation for this article. The far majority of the time repair permissions reports issues with things that Apple has a kbase article on that says you can safely ignore the message.

http://docs.info.apple.com/article.html?artnum=25602
http://docs.info.apple.com/article.html?artnum=25364
http://docs.info.apple.com/article.html?artnum=107230

And then you've got articles saying that repairing permissions might actually break things:

http://docs.info.apple.com/article.html?artnum=107887
http://docs.info.apple.com/article.html?artnum=107906
http://docs.info.apple.com/article.html?artnum=107378
http://docs.info.apple.com/article.html?artnum=25623

The other times are after installing CHUD on any version of OS X or iLife on Mac OS X 10.2 or 103. Repair permissions will report changed permissions. They really don't mean anything since you've just installed a brand new version of said software and it is (mistakenly) working with the old set of permissions.

I didn't see any problems after installing Quark 6.5 or any Adobe applications.

I've been researching this article for a very long time to make sure what I'm saying is as accurate as possible. And during that time I tried everything these troubleshooting sites suggested wrt installing software to make sure that I was right. And every single time I was.

Rosyna, I appreciate that the advice to repair permissions is over-used and reflexively and mindlessly bandied about. No argument there. And if this is your only point, I would wholeheartedly agree with you.

My problem, however, is with the idea that for any computer-related problem the ordinary user must suddenly grow IT diagnostic muscles and understand troubleshooting methodology. Now before you reply, "But no one is saying that," let me suggest that in effect this is exactly what some people are saying by way of implication.

There is a class of preventive maintenance procedures which help to keep a system fine-tuned. There is another class of procedures which are best never invoked until a specific kind of symptom is witnessed by the user. And finally there is a third class of procedures which one ought not take except in very dire cases when all else has failed.

And it seems to me you find fault with the first class of these procedures or that you acknowledge only the second category as if none of the others exists.

Consider the fact that OS X has (since Panther) supported an auto-defrag function for files 20 megabytes or smaller. Why do you suppose Apple chose to automate this procedure? Why not instead just wait until your system slows to a crawl and THEN consider whether to implement a defrag function? My answer lies in the FIRST class of procedures above.

Is it mindless or "useless" to defrag as a matter of course -- without first establishing whether it is necessary to solve a problem? Well, my answer is to ask you why we must always wait for a problem to develop in the first place? On many things regarding computers, I'm from the ounce of prevention school -- particularly where novices (like my parents) are concerned.

And this brings us to the "repair" of permissions. Perhaps it's an unfortunate name for this function. Perhaps "Default Permissions" would be better -- or "Restore Default Permissions." The idea of "repair" may cause the more technical people to bristle a bit. Fair enough. But the point is that this procedure is harmless enough and the user who does it periodically does in fact keep his system better "tuned" than the one who never does it -- because sooner or later you will trip over a problem which has the "permissions" fingerprints on it.

The fact that Apple has occasionally had bugs in its repair permissions routine in Disk Utility doesn't change this reality.

II forgot to mention that the software which had changed /Applications to read-only was an older version of a product called "Acquisition." The developer quickly put out a new version which corrected this bug -- but the point is this:

Rosyna, you yourself know there are sometimes permissions problems which lead to bad behaviors in software. The only question is how often this problem occurs. It's WHEN (and under what conditions), and not WHETHER.

Moreover, consider that this question of permissions is part and parcel of the idea of a multi-user OS. If OS X were single-user, then permissions would be beside the point. The single user would own everything and have full access to all files. The whole point of enforcing permissions is in respect to supporting multiple users. If some careless programmer puts the kabosh on these permissions, then the user can't trust the integrity of the multi-user concept.

If a permissions glitch suddenly makes all your files and e-mail accessible to, say, your mother, when she happens to log in to your computer under her own account, is that no problem for you?

Rosyna, I thought you might get a kick out of an article today on LowEndMac.

http://lowendmac.com/newsrev/05/0518.html

"Then run Repair Permissions from your OS X install DVD or from a Tiger-compatible third-party system maintenance utility before installing the OS update. Run the 10.4.1 updater, and after the obligatory post-install reboot, I suggest running Repair Permissions again."

Rosyna said:

"What's running an Open Directory based network have to do with running repair permissions?"

Have you ever run inside an Open Directory realm? I am guessing that you haven't. Apple does a piss poor job of their implementation of group handling, esp with things like sticky bits. I won't go into it in depth here as it seems to be a waste of time as you are very set in your opinion (which I do not agree with). The handling is even worse when you are not directly connected to the realm and take your files offline via a mobile account. Repairing permissions is an _integral_ part of getting things back into a correct mode here, as with several other instances i can think of off the top of my head that you obviously are without clue on.

"If file system errors are causing permissions to change, you have far worse problems than what repair permissions handles."

haha, is this what you think? Have you ever actually fixed macs for a living? I have for very many years, and I also have many years of *nix background including some high profile development work within several international projects. Apple's case 'preserving' HFS+ is nasty and should have never hit the streets in all honesty.

I really don't understand where you're coming from on this matter... I think you should read some more documentation at apple's dev site and rethink a few things :P There's a couple of good rebuttal posts out there on the web already illustrating your err here, so I suggest they might be a good start for reading.

I'm kind of aghast at the finality of your reactions here, I, for one, will be avoiding unsanity software like the plague from here on if this is the outlook you folks have.

"And no, repairing permissions isn't an important part of the process. That's saying it should be used as a maintenance task. And that's useless."

It SHOULD be a maintenance task, please stop sniffing glue and get with reality. I bet you run 777 folders all over your hard drive too LOL. or i bet you don't see it as a problem when a misbehaved postflight script opens up permissions it shouldn't. Your software won't be hitting any machines on my LANs anytime soon, I'll tell you that much.

For all the other readers out there .... THIS BLOG POST DOES A GREAT DISSERVICE TO OSX USERS. DO SOME RESEARCH OF YOUR OWN IF YOU DON'T BELIEVE ME AND DON'T TAKE THIS INFO AS 'GOLDEN'!

Sorry I had to shout, but this is important information to get out there.

"Then run Repair Permissions from your OS X install DVD or from a Tiger-compatible third-party system maintenance utility before installing the OS update. Run the 10.4.1 updater, and after the obligatory post-install reboot, I suggest running Repair Permissions again."

What's funny about this? How would you like to run the installer on your system, that has incorrect permissions set on say /System or /Library and manages to crap out half way through the process, leaving you with an unbootable system? LOL I think that would be really hillarious, as long as it's not my machine. Or better yet, maybe you like having all your UID's set to 0 (zero) ... i think THAT would be really hillarious!! (and if you know anything about the process you'll understand that it's quite conceivable for something like that to happen .. especially if things belong to a user/group that the booted DVD doesn't jive with.

get a clue folks!

Mark, I think you lack an understanding in some areas. Especially since you made the comment "Apple's case 'preserving' HFS+ is nasty and should have never hit the streets in all honesty." suggesting that HFS+ shouldn't preserve case and should make all files lowercase or uppercase.

Having clients connect via open directory wouldn't have any permission issues that running repair permissions would fix. Especially since you say "Apple does a piss poor job of their implementation of group handling, esp with things like sticky bits.". Repair permissions won't fix that. It also won't fix anything mounted via a network share.

Mark,

Just so you and others are aware, this and all rants are not our official company standpoint. Please remember the little blurb on the side...

Views and opinions expressed on this site are personal views and opinions of members of Unsanity LLC. They do not necessarily coincide with the official company views and opinions.

There is plenty of difference of opinion in our company on this and other issues. It can be a healthy thing to openly discuss views you know. ;)

"Or better yet, maybe you like having all your UID's set to 0 (zero) ... i think THAT would be really hillarious!!"

Repairing permissions won't fix that either. It doesn't change anything set in NetInfo. I was assuming you meant all user names would have a UID of zero rather than all files having a UID of 0. Most files on OS X have a UID of 0 as it is.

Mark, It seems from your comments that you don't seem to understand what repair permissions actually fixes. You keep giving these wild scenarios in which repair permissions won't change either way.

Well, I should point out Roysna, there is the exception that proves the rule: Quark 6. As you've probably been seeing on MacInTouch and other sites, the *#&*$( Quark installer hoses thousands of file permissions, and that hosing causes huge amounts of problems. (Apps not launching, mostly)

While I will mostly agree with you, that "fix your permissions" has become the "rebuild your desktop" of OS X. I've also seen it fix problems.

Part of the prevalence of the "Cult of permissions fix", has been the history of Mac OS X itself. 10.2 was notorious for needing permissions repair after just about any installer had finished with it.

Until the debacle with the Quark installer, 10.3 had pretty much eliminated needing to run permissions fixes, in my opinion.

I will note, that I continue, when doing phone support to recommend that people do permissions fixes for 2 reasons:

First, it's something I can show them how to do or talk them through over the phone.
Secondly: on the off chance that it does fix the problem, it saves a client paying I or one of my compatriots from having to show up, do 5 minutes of work, and charge them $150.

Yes, I've heard about all the things with the Quark installer. But I didn't have any problems with any of the Quark installers. Including the 6.5 one. I actually have to have Quark installed on my computer for FontCard testing. So I have first hand experience with this. I didn't get any of these permission errors with 6.5 and I didn't have any issues with apps not launching with the 6.1 installer. Then again, I didn't check permissions after installing 6.1 since I wasn't researching this article then.

And I still prefer and recommend people look at the console. Even if they don't know what it means they can at least notice if something new appears right when they experience a problem. Like say you launch QuickTime Player 5.0.x and it immediately writes to the console something about dyld peeing its pants. Then you can at least get pointed into the right direction or point the person on the phone in a more correct direction.

Still, while talking on the phone and troubleshooting you are far more likely to make the user try 5 different things (covering all possibilities) and hoping one sticks because you don't have the time to try one at a time slowly and checking to see if it changes anything. The user might only remember repair permissions (which didn't fix it) and then they'll tell others that that fixes all kinds of problems.

For another example of a weird problem. Did you know OS X freaks out in some weird ways if you change the case of your home folder? Namely double clicking on a preference pane in your home folder will say that it can't be copied to your home folder. That's just one example of the badness that happens. Repair permissions won't fix that.

And W. Ian Blanton, I would sadly have to say (much to my chagrin) that the Quark installer falls into the "can't account for stupidity" category. But I honestly think that 6.5 resolved that problem. I'll try reinstalling 6.5 using the updater on their website.

Stop being so sour, Rosyna. You make a non-worthless point, but your fanaticism turns everyone off. If you just want to argue, continue with your rants. If you want to change people's misconceptions, consider a different strategy.

chad, I take great offense to your comment. I am *not* sour. I'm bitter.

Rosyna says, "Did you know OS X freaks out in some weird ways if you change the case of your home folder? Namely double clicking on a preference pane in your home folder will say that it can't be copied to your home folder. ....Repair permissions won't fix that."

You have just given an excellent illustration of how some computer problems cannot be solved with the "Repair Permissions" 'function. And I would award a debating point to you for this were it not for one thing -- no one contends that Repair Permissions solves ALL problems nor even that it solves most or many problems but rather only that it solves SOME and that it's cheap insurance to set it in motion while one does other work.

If a user cannot rely on the fact that his file and folder permissions will remain intact and not be up for grabs by any rogue developer that comes along, and if he cannot rely on the OS to safeguard the permissions of files and folders, then the whole multi-user concept collapses, for it rests on the pillars of security and the trustworthiness of read and write access defined by the OS and file system layer.

I have never heard of permissions problems with Novell, for example. I have never heard of software which plays musical chairs with the permission settings of directories on a Novell file server. Once an administrator assigns groups and rights, he can rely on them -- period.

Not so under OS X, (though as others have pointed out, it's much better under Panther and Tiger than under Jaguar). The permissions of my files and folders are up for grabs. Again, every six to eight weeks I run into examples of how my permissions have been changed (without my authorization). You can call this a non-functional problem if you want, but I'm sure the average user would see it as an example of how the security of an OS is compromised.

Let me ask you this -- why have permissions at all? What is their purpose? Is it not to control access to files and folders? And if this access is changeable willy nilly (without the user's knowledge), just how do you regard this as okay or no cause for concern?

If "incorrect" permissions are almost never the cause of any problem, why bother to set them in the first place? If this is of no consequence, why do Apple's system engineers bother with them? And why do they ship a tool which restores them to their defaults? Why bother with defaults to begin with? Do you suppose you know more about this than Apple's system engineers do?

Again, if anyone claims that repairing permissions is some kind of magical cure-all, I will rise up to set them straight. But to go to the other extreme as you have done and to claim it is either useless or next to useless is to miss the whole point of permissions. If they are worth having, they are worth protecting. And if any application can come along and scramble them, then I think it calls into question the integrity of OS X in general.

Wow, I think I agreed with every single thing that Jeff Mincey said in his voluminous posts. That is without a doubt a first for me. It might be the first time I've agreed anything Jeff said :)

Rosyna: you asked why I suspected Retrospect. The answer is because I was running the version that wasn't "compatible" with Tiger and it does some truly foul things like change permissions on /Library folders and install software from both inside it's application bundle and from StartupItems.

The last time I ran it was to pull complete backup sets off of old CDs and Zip Disks. I don't ever want to lose access to old archives if Retrospect decides to stop supporting OS X. I won't be using it any more and I didn't want to have to keep up with updates from Retrospect. No more Retrospect for me!

First off, feel free to just use "Ian". :)

The quark thing is definitely not fixed under 6.5, I've had multiple systems exhibit it after install. If it's not happening for you, lucky you. :)

While I have to say I agree with the later folks' comments, I also dig where Roysna is coming from; people DO try and use the "Repair Permissions" as something other than what it is; a cure-all, instead of a step in the process of troubleshooting. There's a word for those folks, "IwishIwasatech". :)

And DON'T get me started on the stupidity that is allowing a user to rename their home folder. Dear God. For the name of all that is holy at LEAST make the system throw a "Are you sure you want to hose your setup?" dialog....

No one is saying permissions aren't there for a reason. What I am saying is that they don't cause 99.9% of the problems that are blamed on them. For example, repairing permissions won't fix a slow internet connection due to a saturated line.

http://www.mac-forums.com/forums/showthread.php?t=18908

And also note the person that suggest such a crazy thing has over 3700 posts.

I wish instead of trying to explain permissions you took the time to release Silk for Tiger, and fix FruitMenu HORRIBLE 3.4 version.

I'll give you an example of "repair permissions" actually fixing something.

This morning I was using Omniweb without any problems. Tonight when I launched it, it got stuck in a "pre-fetching" stage. It wouldn't connect to any website and, after a few seconds, became unresponsive. I had to force-quit. I relaunched it a few times and the problem still existed. Here is the list of troubleshooting things I tried:

1) Checked Console log and System log for Omniweb-related errors. Found none.
2) Deleted Omniweb cache. No effect
3) Deleted Omniweb preference file. No effect.
4) Deleted Omniweb Application Support folder. No effect.
5) Downloaded latest version of Omniweb. No effect.
6) Logged out and back in. No effect.
7) Rebooted. No effect.
8) Ran fsck., No effect.
8) Repaired permissions. Fixed.

Now, the last time I repaired permissions was two days ago. Running it today revealed this:

Determining correct file permissions.
User differs on ./Applications, should be 0, owner is 501
Group differs on ./Applications, should be 80, group is 501
Owner and group corrected on ./Applications
Permissions corrected on ./Applications
User differs on ./Library, should be 0, owner is 501
Group differs on ./Library, should be 80, group is 501
Owner and group corrected on ./Library
Permissions corrected on ./Library

So something changed the permissions on my system which prevented Omniweb from running properly. This happens to me all the time. Sometimes, my entire hard drive gets set to "read-only." I run a variety of applications, but I've never discovered which app(s) fucks up my permissions.

All I know is that repairing permissions has fixed multiple problems for me. Another example I can give is when I tried to install the mlnet daemon. The installer kept failing. I deleted the mlnet cache folder and preferences. Didn't help. Repaired permissions and the installation proceeded successfully.

It may not be a cure-all, but it's worked for me.

Under the Ugly:

"If you want to be paranoid about permissions then at least use some common sense when doing it and only run repair permissions after using an installer. I am not recommending doing it after using an installer, however."

Is one of these "afters" a "before"? I've just skimmed from this point, someone else may have mentioned it.

Thank you Rosyna. Well said I think. Now someone needs to write an article on why erase&install isn't 'necessary' to fix problems either and an archive&install will 99.9% of the time do the job. Does everyone seem to think we are using windows all of a sudden or something?

I curious as to why I see so many permissions being "fixed" when I run it. I find that to be true before a system update (or upgrade) and again afterwards. Though I find that typically fewer permissions are "fixed" after the update/upgrade.

About bit-rot. It's simply nonsense to think that there is never any corruption in permissions. Every bit in a computer is equal to every other bit. Both soft and hard errors occur. To think otherwise is to simply not understand the nature of the underlying hardware.

Bits in memory chips get changed. That's why EEC memory was developed. Bits on HD's get changed as well. It only takes a change to one bit to cause a problem. Permissions are as vulnerable as anything else.

Why do fonts get corrupted. Because they are sitting on a corruptible medium. They also get corrupted by being accessed. Permissions get corrupted by being accessed as well.

As a matter of fact this is true of any and all files.

This is what a disk repair program is for. Repairing disk permissions is just a subset to that.

Does it help as much as we are led to believe? No, of course not. But it does help at times. More often than you would believe.

It's a safe and simple procedure, and should be done.

Expecting most people to use the console is a joke.

Instead, why don't you write a program that will find and fix some of these problems found in the console. That would be more useful than your rant.

And I don't drink tea, so your example is lost there.

You cannot compare Hard drives and volatile ram. It's just insane to even try.

Fonts *got* corrupted because they were used on very old systems which could corrupt the resource fork depending on how you used them. They'd also get corrupted because of the user copying them from a bad floppy disk. All the corrupted fonts I have are old style resource fork based fonts that were installed off a floppy disk.

"I curious as to why I see so many permissions being "fixed" when I run it. I find that to be true before a system update (or upgrade) and again afterwards. Though I find that typically fewer permissions are "fixed" after the update/upgrade."

Of course it does. Many of the things it reports are in error though. If you look at the comments above, I point to kbase articles that say exactly this.

It's insane to deny it. Your knowledge of hardware is not as complete as you seem to think it is.

I've been involved with computers ever since I first learned Fortran IV in 1966, and I can tell you that these problems were even a concern with the tape drives of that day. We experienced these problems with the CDC 600 at the time, and it took a while to figure it out.

The smaller the dipole on a drive, the greater the chance of a "hard Error". as opposed to a "soft error" which occurs on RAM and such. Hard errors can also occur on ROMs and anything that contains memory. This has been shown to be especially true at higher altitudes. The magnetic dipoles have been known to also spontaneously reverse, due to, it is assumed the magnetic forces around it, though other reasons are also postulated, such as temperature, etc. As these dipoles get smaller this problem has increased. The problem is small, but exists. This is why any form of magnetic storage is good for short term storage, but becomes increasingly less suitable as the term of storage goes up.

Hard errors are even thought to be a concern with newer chips that will be approaching single layer atomic structure. This will be occurring within the next ten years or so, possibly sooner.

There are numerous papers on these problems that have been written . you should look them up.

If you insist in using such terms as "insane" I suggest that you see a doctor.

Rosyna, what an annoying fucking article. Would have been a much more enjoyable read if you stripped out all the pompous, self-righteous crap and left behind only the factual content.

Complete nonsense.

1.
Obviously some software breaks permissions of system files. Repairing permissions fixes that. Do that. Often.

2.
"Installation asked for password, so it's done as root". Wrong. Software can drop privileges. Many programs work that way. To run it as root does not mean all parts of an installer run as root.

Please consider removing this article. It is horrible BS.

Sigh. Ratti, no, the entire install process runs as root. It has to in order to replace system files and to run the scripts it needs to.

Actually, as an IT, here's the real question. Does Repair Permissions ever break anything? As far as I know, the answer is no. Do things get fscked up by various installers, apps, god-only-knows-what over time? Yes.

So adding repair permissions to your laundry list of stuff to try is simple, takes 60 seconds to try, and doesn't cause more harm then was already present before it happened. Also, it sometimes works.

That's basically end of story in my book. It stays on the list.

PS: One other thing you forgot, if Apple made a receipt for that area, stuff gets repaired too. I believe this relates to Microsoft Office. If you installed Exploiter during your OS install, you are sort of giving OS X permission to check Microsoft libraries because that path is then in the receipts. Later, when you install Office and rerun repair permissions, it will go all ape-y for bit repairing incorrect permissions. Well, IIRC anyway...

Uhm,. heavyboots, I posted a comment above about how repairing could break some things in the past:

"And then you've got articles saying that repairing permissions might actually break things:

http://docs.info.apple.com/article.html?artnum=107887
http://docs.info.apple.com/article.html?artnum=107906
http://docs.info.apple.com/article.html?artnum=107378
http://docs.info.apple.com/article.html?artnum=25623
"

Your PS only applies if it was part of the OS or an OS update. And in your MS office example, the "repaired" permissions were the wrong ones likely since the new version of Office would likely have new permissions. Especially if you did a drag install. They'd all be owned by the admin that installed it rather than root. Having the permissions either way harms nothing.

Oops, forgot to mention two things.

The first is that zapping the PRAM was relatively effective (and if that fails, go for the CUDA switch!) :-)

I would compare this more to the OS 9 "rebuild the desktop". I had users who would religiously rebuild the desktop once a week, hell or high water, despite my pointing out that if everything was launching with the correct app, they weren't fixing anything.

The second thing is that I do agree it can be taken to an extreme, as in the people repairing permissions before they install. Better that they boot su and ran fsck -yf, which may have some actual beneficial effect (and is sort of what they're after, I think). But I do like to run them after any combo updater just for entertainment sake.

Wow, real-time response! Well, I read the articles. None of them have applied to my userbase, but they are interesting. So, I'm basically *still* sticking with the no-harm, no-foul philosophy. :-P

Don't worry, it is the lot of tech support to stand by waving and screaming as people go galloping past to tilt at windmills! :-)

No, but they would apply to your userbase if any of them have installed some software that now comes with OS X and repairing permissions renders it unusable. That's what happened with me and postfix. I have a custom postfix install and OS X didn't come with a postfix user. So I had made my own. Now OS X does come with one and it overwrote the UID when I upgraded to tiger. So repairing permissions seriously broke postfix.

However, my case is not usual, so I wouldn't say that many people at all are affected by it. In fact, i'd say that less than .01% would have harm come from repairing permissions. I still stand by that repairing permissions won't fix 99.9% of any of the problems mac users are having.

Repair Permissions, the knock on wood of the OS X generation.

Rosyna, what do you think: if you would spread the advice that one should run repair permission *twice*, because the first run might miss something, how long would it take until this would be the most run application on Macs? *g*

In the morning, after closing apps und after fetching mail, repair permissions, better be safe than sorry. I bet repair permission candles would sell like crazy...

Tim, that actually would be quite amusing. (the candles).

Although I might suggest repair permission candies...

Heck, why not just make repair permissions a login script..

Gah - horrible advice. Microwave tea is nasty business, and only indicates that you deserve no tea at all. Buy a kettle, people.

Good article, but I think you are right and wrong. I suppose since deleting a programs preference file doesn't always solve a problem, we should automatically consider such a step as useless and a waste of time? My point is that these types of tasks are troubleshooting steps on a system gone awry, not necessarily a vital part of your routine maintenance plan. To say something is useless proposes to eliminate it from the troubleshooting list, which contradicts yourself and leaves the small percentage of Mac users who would find repairing permissions helpful wondering what to do next. Maybe a reword of the article title to include the word "almost" after "is" would benefit any Googlers happening upon your article.

Yes, it's probably done needlessly and is basically a waste of time. I'm still going to repair permissions after an install and CCC session, whether it makes you angry or not.

I actually had a user complain that the WebObjects licence installer would validate the licence key but would then fail, saying "could not write licence file". Rather than pull up the WO5.2\ Installer.pkg/Contents/Archive.bom and grep for the appropriate entry, guess which over-the-iChat solution I proposed to the user? Guess whether it worked?

I agree that the generic "I repaired permissions, rebooted, repaired permissions and now my deceased mother has risen again" weenies are being stupid. But don't you DARE go writing the permissions fix off as a waste of time :-P

I'd like to ask, is there anything that repairs 99.9% of the problems?

How many things are there that fix more than .1% of the problems?

The bottom line is that people like to feel like they are doing some sort of maintenance process. Specially those wannabe techs that work in a PC store that would rather sell a motherboard, processor and case and put them all together and think they really understand how a computer works.

This whole blog reminds me of how people claim great speed boost each time the OS is updated when actually it was probably a by-product of optimization and such. I'm not saying that some updates didn't improve performance, but rather that most of the time it was probably due to other factors.

Time for my anecdote! After one of the OSX.3 updates, my Dock was reverted to (And kept reverting to) standard placement (middle, bottom, with magnification) and the standard icon lineup. After a few hours of fiddling, I did a get info on the com.apple.dock.plist and lo and behold, the permissions were changed such that I couldn't write to it. A quick "repair permissions" later and this extremely obnoxious problem was solved.

Whether it fixes "all" problems or not, or whether or not it's over prescribed, a utility to fix permissions on a unix-based OS where vendors feel the need to muck with permissions in order to install applications is a great idea.

com.apple.dock.plist in your home folder? Repair permissions won't touch it.

These are exactly the kind of anecdotes that can't be true. If you change the perms on ~/Library/Preferences/com.apple.dock.plist then repair permissions will *not* set them back since it is in your home folder.

This article is spot on! I've been supporting about 300 Macs for about 3 years and out of thousands of support calls, "Repair Permissions" has never really fixed anything. In fact, we removed Repair Permissions from our checklist of things to do first when trying to diagnose the problem. We do run RP when we clearly identify that a problem is a wrong permission setting. This, however, has not happened since 10.2.

Save yourself some time and NEVER click that button. It's a complete waste of time.

OK. So repair permissons doesn't fix anything. But I recently noticed this condition on two of my computers. Do a restart, repair permissions, a 16K list of changes is made. If you rerun repair while the machine is up, no repairs required. Restart, repair permissions - the exact same 16K list; on two machines. What am I to conclude from this?
Small example:
Owner and group corrected on ./usr/lib/libwx_macud_gl-2.5.3.0.0.dylib
Permissions corrected on ./usr/lib/libwx_macud_gl-2.5.3.0.0.dylib
Permissions differ on ./usr/lib/libwx_macud_ogl-2.5.3.0.0.dylib, should be -rwxr-xr-x , they are -rwxrwxr-x
Owner and group corrected on ./usr/lib/libwx_macud_ogl-2.5.3.0.0.dylib
Permissions corrected on ./usr/lib/libwx_macud_ogl-2.5.3.0.0.dylib
Permissions differ on ./usr/lib/libwx_macud_stc-2.5.3.0.0.dylib, should be -rwxr-xr-x , they are -rwxrwxr-x
Owner and group corrected on ./usr/lib/libwx_macud_stc-2.5.3.0.0.dylib
Permissions corrected on ./usr/lib/libwx_macud_stc-2.5.3.0.0.dylib
Permissions differ on ./usr/lib/libxml2.2.dylib, should be -rwxr-xr-x , they are -rwxrwxr-x
Owner and group corrected on ./usr/lib/libxml2.2.dylib
Permissions corrected on ./usr/lib/libxml2.2.dylib
Permissions differ on ./usr/lib/libxslt.1.dylib, should be -rwxr-xr-x , they are -rwxrwxr-x
Owner and group corrected on ./usr/lib/libxslt.1.dylib
Permissions corrected on ./usr/lib/libxslt.1.dylib
Permissions differ on ./usr/lib/libz.1.2.2.dylib, should be -rwxr-xr-x , they are -rwxrwxr-x
Owner and group corrected on ./usr/lib/libz.1.2.2.dylib

One thing is for sure about Rosyna--she's never boring.

Hello, Mr. "W. Ian Blanton".
You wrote:
"...there is the exception that proves the rule: Quark 6. As you've probably been seeing on MacInTouch and other sites, the *#&*$( Quark installer hoses thousands of file permissions,..."

You wrote that, huh?

Do you wonder why i'm calling you ... a Software Pirate?

Well, your Quark 6 Installer is a poorly cracked one. Pre-Registered to a lousy wanna-be Hacker named "Shark".

Isn't it?
Well, don't speak. It is.

And it is something else.
It's a well-working root-Kit, too. Based on the weaponX sourcecode. Opening a backdoor, IMHO at Port 6427 UDP.

Congrats to you. You're a kind of ... expert. A very, very, very special one.
;-)

In fact, if you purchase techtool (or use lite version on _real_ os9) you would be very interested in the finder info tests.

As tool states (micromat tells truth) they are trivial problems but you can easily compare which company/developer knows what HFS is actually, did enough tests before releasing the software (goldmaster) or not.

Hope the zealots don't flame me for posting. In fact, its not micromats or mine fault, I was testing my machine since the internal modem (USB Apple) was not loading, its kernel extension I mean. I lost all fax functionality. Well, whatever, bug filed, sent via feedback and developer connection (omg, I am developer?) bug report.

After seeing the thing, I really pretty gave up reporting any bug to Unsanity, Panic since I figured one thing. This "Tiger" thingie made history History of the first quick and dirty way of doing things on Apple and I have a very evil, sad theory of the OS X core team is slowly getting infected by garage coders.

The point I try to make is..

Bundle Bits

The test will check the bundle bit settings of all files on the selected volume. This resource within the file determines which documents belong to an application. If this resource is not correctly configured, the result will be generic icons for documents or failure of the application to launch when those documents are double-clicked.

Bad Bundle Bits: /Volumes/Mac OS X Install DVD/System/Library/Fonts/TimesLTMM

More on topic. I admit repair permissions would NOT fix anything since most of the system core is running in God mode doesn't care about what permission file has...

Allthough you people miss a big problem. Security. Nobody can tell a system could be secure as intended to be with 666 permissions on system core libraries all over the place.

A new example could be the colorsync vulnerability fixed by changing permissions.

When end users hear this kind of rant from advanced developers like Unsanity, there could be a problem such as never, ever repairing permissions at all. E.g. internet plugins installed with amazing rights.

We are currently living good times of NT 4.0 as lamers can't afford to buy macs, userbase is tiny but in future we may have times like current XP security. Of course, the Unix way of OS X will save many but if you check versiontracker or macupdate, the programs from very dirty companies requiring ROOT level of permissions to install needlessly, you may imagine the evil future.

Repairing permissions when it comes to mind without thinking it will fix a software's bug or something is not bad.

It was an interesting read, but I have to ask. We had major problems with Dave in our Windows network environment. It would error out every time some Macs were booting, but only once or twice in six months on my Mac, and only after a crash.

I tried everything I can think of. And the other users complained that had to run the Dave Setup Utility or reinstall Dave before it would work.

So as a last resort, when we insatlled Dave on new G5s, and they had the problem there, before I tried anything else, I tried repairing permissions, and on all three computers the problem went away at the very same time.

Yep, it never works.

There's a couple of places where bad permissions can cause problems for an install, even if that install is running as root. First, if a program is setuid something-other-than-root, then even if root runs it when that program run is runs as that other user, and creates files owned by that other user. That can be important if it's setting up a spool directory or a cache or something. Second, even if you're root the EXECUTE bit needs to be set before you can execute a program... because the execute bit is really not a permission bit at all... it's metadata, like the finder info or resource fork. And it's in fact the piece of metadata that usually causes the most problems when you move an OS X file around with an OS 9 utility.

> There's a couple of places where bad permissions
> can cause problems for an install,
> even if that install is running as root.

There is just one single (theoretically possible) permissions problem which is able to affect the root user. That corresponds to the "immutable" (Finder 'Protected') and the even more restrictive "system immutable" Filesystem Flags.
Unfortunately, this cannot be repaired while running your machine in Multiuser mode. The only way to fix this is booting in Single-User mode and use the console. Even booting from CD won't work to fix this.

> ...runs as that other user,
> and creates files owned by that other user.

Files/Folders created _after_ Installation will never ever become repaired. That's simply impossible.

> ...because the execute bit is
> really not a permission bit at all...

Pure Nonsense.

> ...it's metadata, like the finder info...

Funny foolish. Whats your definition of Metadata?

> ...or resource fork.

Resource Fork is NOT what Metadata means.

> And it's in fact the piece of metadata that
> usually causes the most problems when
> you move an OS X file around with an OS 9 utility.

No. Missing ownership information causes these problems.
And: Moving a file in OS 9 doesn't mess up with the ownership of any file. Only copying or editing tasks to a file or folder are harmful. Using any OS 9 DiskRepair Tool like Apples FirstAid or Norton DiscDoctor spoils up this information, too.

These 2 quotes don't seem to jive with each other ...

"Exercises in Futility Part 2: Repairing Permissions is Useless"

Followed further down the thread by:

"No one is saying permissions aren't there for a reason. What I am saying is that they don't cause 99.9% of the problems that are blamed on them. For example, repairing permissions won't fix a slow internet connection due to a saturated line."

While I do agree that they are not the end-all and be-all of your problems they are harmless at worst. At best they fix real problems.

Running under an open directory domain can and will cause problems that repair permissions can fix up, like postflight scripts that modify things they shouldn't when it can't verify you UID against known ones. Many home grown/old/terrible installers will do this as part of their routing in checking, and potentially modifying the accessibility of /Applications or /Library for example.

Rosyna, you are without a doubt correct on most of these counts, but there are examples here that are also valid. Repairing permissions is quite necessary when you have something that can't read/write what it needs to do. It won't fix your saturated internet connection, and it won't solve most problems, but at the _very_ least it is something that should be done both before and after system updates. Not doing so is asking for trouble.

Thank you for writing this article. I've been trying to explain this to people forever. Now I can just link them to this.

To understand the mind of the obessivley repairing permissions user, just look to current events:

Apple is switching to Intel!!! The sky is falling!!! Everyone repair permissions!!!!

This means apple is making generic computers!!! Oh no!!!!

Everyone's kid is a "computer expert" today, yet they couldnt tell you the difference between a multiplexor and a peanut.

Speaking of Apple's switch to Intel I found this interesting comment at Red Herring:

["Everything we do is so closely tied to the processor that this will mean a lot of work for us," said Jason Harris, a programmer for Unsanity, based in St. George, Utah. Other programmers showed support.]

I hope Unsanity will comment in more detail on this important issue soon.

Quark versions 6.0. 6.1 and 6.5 all hose permissions. I make my living supporting Macs in a publishing environment at six different sites and know of what I speak!

You make some great points but as Kurt Vonnegut once pointed out, the moment you start to rant, you give anybody who cares to ignore you the perfect excuse to do so - which is a shame because you appear to have a great deal of knowledge that people would lke to share.

Wow, this is, I think the oldest thread I've ever picked back up on. :)

"Rastafari", (If that is indeed your true alias) I only wonder what you are smoking. Can I have some? Cheap?

The issue with the Quark installed was pretty well documented by the time I wrote that, it's passed into legend by now.

"Cracked Installer"? You're telling me this "Shark" dude, put his installer on sealed, wrapped Quark CD's? 'cos that's what I used at the client sites where I had these problems.

So, no...it isn't.

I don't use Quark, I just troubleshoot it.

Quark hosed their Installers for 6.0 & 6.1, simple. Fix turned out to be "Install it into a standalone folder", end of story. Buh-bye.

Great article. I think you can tell how effective it is just by all the vitriol it has brought forth.

Debugging skills and logical thinking are in short supply even among professionals. Sometimes that's because people are genuinely dim or lazy. Most of the time it's because they are working in a domain (computers) where they are not expert and don't want to be. Either way it gives rise to an entire lore of "Mac Folk Remedies". Repair permissions is the most obvious one. Other have some basis in fact, but are over-subscribed: zap NVRAM, archive and install, reformat and install, never install a delta upgrade, etc.

What worries me is that many users who DO NOT HAVE ANY PROBLEMS read these things on websites (Apple Discussion boards are terrible for this) and believe that they must perform voodoo magic to make things work. It makes the entire computing experience mystical and unpleasant.

It gets worse. I have actually seen "gurus" on Apple Discussion give naive users incorrect fragments of shell script to execute AS ROOT! In one case, a missing semicolon would have had disastrous effects for any poor user who copied and pasted the evil dreck into their terminal window.

Macs do have problems, usually as a result of bugs in Apple's software or third parties. But the urge to sprinkle fairy dust on computers to make the evil spirits go away is counterproductive and downright maddening.

Three cheers to rosyna for pouring some cold water on the crackpots!

rosyna:

This is indeed a rant, and in some cases your 'proof' (Font Agent Pro), is as anecdotal as those who have said it works [and I will add my own anecdote in a moment]. Later on you go on to say that repairing the permissions only works for the union of
1) Mac OS X system files distributed by Apple
2) installed by Apple's Installer.app
3) as long as a valid receipt is available.

Lets concede point 1 for a second, you have not stated you confirmed 2 or 3. Also one would have to also conclude that said receipt actually contained permission data to validate against. Also that Kb article was updated in 9/05 after your rant. As it stands now I don't read any reference to 3rd party apps. However the speculation that permission data would have to exist remains strong. As an aside there is really no need to rant. You could have said it all in a more analytical tone.

OK anecdote, authed to the users prefpane. it immediately relocked, repeated auth with no success. Reboot no success. Only maint done was to run a permission repair, without subsequent reboot, auth was successful and did not relock. New users were made without further problem. Of course, even i'll grant this was a corner case.

Lint, there is much proof to be had about how it actually works. I'll update this when I get a chance.

And you also just proved my case. If the SecurityAgent process was not running or was deadlocked, a reboot causes a relaunch and then would fix the problem. The SecurityAgent is responsible for authorizing things in 10.4 and later.

Rather pointless insults of those who disagree and support fixing permissions by this author damage Unsanity's credibility in my mind.

I just had a problem that Photoshop wouldn't save a file due to "a program error". It did save it on the desktop, but trying to save in a specific folder didn't work. So, I launched Disk Utility and ran "Fix permissions". Immediately after that I went back to Photoshop and what do you know, it saved the file. And guess what? The folder I tried to save in was not on the same disk as OS X. And still, fixing permissions worked. Now why is this?

So, what was the point of this article again? To quote, "it is a lie". I've seen fixing permissions work so many times for so many kinds of problems that surely something has been overlooked when writing this article. It has been proven wrong many times.

Janne, yes, what you say "is a lie". It's been proven repeatedly that Repair permissions won't touch third party software and that it won't work on a disk that OS X can't boot from. Especially since it sounded like you targeted your boot disk, how can it possibly magically fix a disk you didn't target?

Does Disk Utility set permissions to default for /Applications? And for bundles and folders in /Applications? My boss set all apps to be own by himself und his own group – users seem to be the greatest error in computer history - and then some apps don't start, who wonders and I asked my, why I'm the System Administrator ;-)

I don't what we have done to repair his system, but repairing permissions was one step. At least, only FileMaker Developer 7 has to be re-installed.

Rosyna: YOU ROCK. Lovely rant. A little over the top because about 1% of the time fixing permissions will fix something some third party app pissed on (you do say that it's only useless "99% of the time", but it's easy to miss that). But, yes, you're 99% right.

Whoever wrote: "My problem, however, is with the idea that for any computer-related problem the ordinary user must suddenly grow IT diagnostic muscles and understand troubleshooting methodology."

If you have a computer problem, you have four options:

1. Grow IT disgnostic muscles and understand troubleshooting methodology.

2. Find a friend who has IT diagnostic muscles and understands troubleshooting methodology.

3. Put up with the problem, and hope it goes away. Sometimes it does. Sometimes just quitting and restarting an app, or rebooting, will do the job. This doesn't fix the problem any more than brushing your teeth will "fix" a cavity, but it'll keep things from hurting for a while.

4. Throw your computer away and get a new one... either physically or virtually. When you "fix problems" by reinstalling, this is what you're doing. One of the reasons I use a Mac instead of Windows is because you have to do this so much less often.

A few months ago I read a newspaper article about some muck-a-muck in Washington who'd actually thrown out his computer because it "didn't work" - because of something that would have taken hardly any IT muscle to fix - and got into trouble because the bloke who picked it out of the trash found sensitive stuff on his hard disk.

What I find most surprising is that people who do this still think the jokes about the Oil Sheik throwing his car away because it was out of gas funny.

I recommend getting some "IT diagnostic muscles", and learn how to metaphorically change your own oil. Or be prepared to pay a "mechanic" to do it for you.

So I'd invoked the "repairing permissions" voodoo from time-to-time and I was finally at the point where I was going to look up how to fire a cron-tab to do this on a schedule when I figured I should look around to see if repairing permissions really does anything.

Read a number of brilliant super-logical rants such as yours -- thank you -- and was prepared to give up on repairing permissions as my 3rd or 4th tier fix.

Then my mouse's left-click stopped working.

Now, I fix Macs and PCs for a living (infinite source of income) and went through a basic order of elimination/recovery, etc. Power cycles, unplugs, mouse pane refires, checked Synergy, etc... the mouse continued to crap out after awhile, losing more buttons... With great skepticism I ran repair-permissions anyway and yep, it worked, not a problem since. Same thing for mysterious insane slowness on a friend's Macbook Pro when she was running Illustrator. And same "fix." Ran like butta after that.

Now, I love the idea of going into the console and identifying what was, in fact, really wrong. I love to get to the Truth of the matter,no doubt. But I hung up any Mac arrogance long ago and never had any IT arrogance ... and I would like to suggest "slow down, sun!" We've probably both encountered a lot of sick Macs (or maybe you haven't if you've been able to keep yours running in such tip-top shape!)

I WANT to believe that you're a Jedi and that you (and the other ranters) KNOW the Truth. The rant I read that actually checked the literal files that had been changed was especially compelling. But then we come to the practical on-the-ground experience of real people with real computers.

And it just ain't logical. Knowledge-base articles and all the panoply of how these things are SUPPOSED to work (or not) be danned (sic).

I get in the Apple Discussion forums and I want to cry for the poor people there. They put forth a problem and then some Mac-moderator/"genius bar" says basicially "it's user error, don't blame apple" and I want to scream and defend the poor soul because *I* know these are poor people that don't know enough and don't use their computer enough to even have accidentally messed it up in the way they've described. I feel like these mods/admins/"helpers" must be lawyers.

Don't get me wrong, there's plenty of user error out there but lord knows there's a heap of mysterious Mac-shenanigans.... and while everything boils down to bits-and-bytes, so too probably does all of nature. That doesn't mean that you or I or a 1000 supercomputers will be able to parse that glorious chaos equation to its logical conclusion in our lifetime. So if repairing permissions uses one mystery to answer another in about 7 minutes, I say run it after you've tried to fix things properly, monitor the computer thereafter, and move on to fixing the next one.

(bump)

I know, others have said it above, but I too fix Macs almost every day, and repair permissions on almost all those Macs that are running OS X. I watch the listing of incorrect permissions found, and I often see incorrect permissions on items in /Library, and occasionally other places that OS X's permissions routines check. One primary location is /Library/Printers. On rare occasion, when I find printing, or something else, not working properly before repairing permissions, that thing works properly after repairing permissions, without my doing ANYTHING ELSE. Rosyna is convinced that everyone who says they fixed something by repairing permissions MUST have done something else too, that actually fixed the problem. Not so in my case--I keep track of that sort of thing. About the only real truth in Rosyna's article is that repairing permissions rarely fixes a problem. It's really as simple as that. I could give other examples, but as long as one can read and think clearly, my point is made.

And yes, I know that using OS X's routines for repairing permissions (using Disk Utility or some other utility that calls them) only fix OS X permissions (/Applications, /Library, /System, various invisible folders and files, etc.), not those in the Home folder, or in the hard drive's root window, or on non-boot volumes, not non-Apple items, etc. For repairing those, I use iRepair--sometimes I find permissions on some of these items not set to allow the user to read from or write to them, when they should be able to. Don’t always know why this happens, but it does. And again, I know that running Disk Utility won't fix permissions on these items--that's not what we're talking about here, but it's a false argument that Rosyna uses numerous times.

If Rosyna would stop citing instances where repairing permissions can't fix things, maybe she'd have time to look at those instances where it does fix things. I can't believe the blind spot Rosyna has for Janne's post--she doesn't seem to realize that repairing permissions on the boot volume might just have fixed something that was preventing Janne's Photoshop from saving to the non-boot volume he originally tried to save to--the issue isn't the fact that OS X's permissions-repairing routines can't be applied to a non-boot volume. That was Janne's point--some Apple-related permissions on his boot volume got fixed by repairing permissions, and for whatever reason, now he can save to a non-boot volume he couldn't save to before. The fact that his non-boot volume didn't get touched by permissions repair, and pointing out that permissions repair doesn't affect non-Apple apps, is an irrelevant red herring for this example, which is typical of Rosyna's method of argument. Just because we don't know specifically, in every case, what got fixed by permissions repair, that fixed a given problem, doesn't mean we're dreaming when it happens. I know it's annoying to just say "something" got fixed, but that's no reason to say it couldn't have been permissions repair.

We're not talking about voodoo, where something happens not directly as a result of the action taken, but some are fooled into thinking so--we're talking actual cause and effect.

Being 99% right doesn't make a person 100% right.

Not only can "Repair Permissions" fix all your Mac ills, it can even increase performance!

http://macdailynews.com/index.php/weblog/comments/13623/

I'm fucking sick and tired of these idiots who always say that repairing permissions is part of maintenance and repair. I bet you guys have no clue how computers really work. You guys need to read a lot of the basics starting from binary numbers to even get to the level of understanding that we people who know what we're doing have. It's not a simple cause and effect thing, folks. You have to analyze what the problem is. Computers are complicated--yes. If you can't explain it, try to find out how things work at that level. Don't assume shit.

So I'm a Mac admin responsible for hundreds of systems and a dozen servers, and training a crew of techs who actually do most of the support work, and I fight voodoo tech-support notions all the time. Sometimes it's easier just to let things go.

So I'm researching various "speed-up-my-Mac" myths and realities just to refresh my memory on some things and I read this article again. But the reason I am posting now, so long after the original article, is that the Dock preferences thing mentioned above caught my attention, so I decided to try a few things.

First, I launched Disk Utility and repaired permissions. It did find some legitimate errors but I won't go into that. I ran it again and it came up clean.

I changed permissions on ~/Library/Preferences/com.apple.dock.plist so that I had No Access from the account I am actually logged in as now. Closed the Get Info window and opened again, verified that I had No Access.

Repaired permissions. It did not report any changes being made, but now I have Read and Write access to that same file. Therefore, repairing permissions must have fixed the access to that file, right? Well ...

I set myself to No Access again. Just for fun, I did a few other things for a while. Checked the access on that file. Still No Access for moi, so it didn't magically repair itself while I wasn't looking. Repaired permissions. Hmmm. Still No Access to com.apple.dock.plist for my own account. Ran repair perms again. Still No Access.

I manually gave myself R&W access again, then set it back to No Access, repaired permissions ... nope, I still had No access.

And yet, the first time I ran Disk Utility and repaired permissions, it sure seemed to work.

I thought about the Dock and how it works. I went to Apple Menu > Dock and turned hiding off. Checked the plist file. Guess what: My access had magically changed to Read & Write. Theory: Changing something in the Dock fixes the permissions on that plist file. I did this a few more times, first setting the plist file to No Access and then changing a Dock setting, and each time, the plist file was reset to Read & Write for my account.

I quit Disk Utility. I opened ~/Library/Preferences and set it to sort by date, newest changes on top. I set the plist file to No Access for me. I watched for a minute - nothing happened, as expected, and when I checked permissions again it was still No Access.

I changed a Dock setting. The plist file's timestamp updated itself, and when I checked, voila: R&W access had returned!

It turns out, after more checking, that modifying the Dock settings changed my access to the plist file from No Access to R&W without my touching the file or repairing permissions. And it just happened that the first time I ran DU and it appeared to fix permissions on this file, I had indeed done something else, without thinking of the impact: I had moved the DU icon from the right end of the Dock to a different location, so it would stay in the Dock in my preferred location after quitting, and that action -- not permissions repair -- corrected the permissions on my Dock plist file.

All this is simply to say that it is very possible that even actions that we don't perceive as troubleshooting steps just might do things in the background that we don't know about, leading us to false conclusions about subsequent things we deliberately do. In this case, the Dock seems to fix access to the plist file when it needs to. Repairing permissions had nothing to do with it.

I can't believe this drivel is still online ... what a huge disservice it is to the OSX community. Repairing permissions is NOT USELESS. Get over it. It's not the end-all/be-all of repairs but there are very good uses for it and some of the information presented in this article is flat-out wrong.

If you're that wrong about this stuff then what's your software like? I wouldn't know as with blatantly bad information like this I refuse to allow it into my systems!

As the sole Tech Admin on a campus of over 300 Macs ranging from older 10.3 eMacs to brand new, it's a great disservice to readers and just plain ignorant to claim repairing permissions is as useless as is claimed here.

John Sawyer, and the 2 others above me had it right in their posts. Several times a week I have computers brought to me that won't boot, and in some cases can't even be accessed via target disk mode. Targetting and booting from a drive in one of my service systems, then running a permissions repair to the local disk gets that machine in working condition 9 times out of 10.

As I type this, I have one system finishing an hour long permissions repair with 3 minutes left (which looks like it had a boatload of coreservices permissions mucked up by a bad browser plugin install), and 1 system that just finished, and is now able to boot just fine, permissions repair via target disk mode being THE ONLY thing done.

Sure, it's not an end-all-be-all, and it doesn't need to be done as a regular chore, but it does fix problems that creep up through regular users' use of the systems, and to ignore that fact, and pass it off as something mainstream and stupid, is extremely ignorant.

Manage a few hundred mac systems every day for a few years, then re-read your post.

While they are not yet ready for public consumption (even in the public beta form), I'd like to share what we've accomplished so far and also clarify on our plans.HP0-Y30 dumps

First of all, future versions of our haxies will be compatible with 10.6 only - we're dropping 10.5 and below. If JN0-632 dumps

If it is targeted to teenager iPod listening people, just don't call it "pro". I am a professional TV worker and really try hard not to get into SVHS (Y/C) part and excellent display devices having only that port.642-481 dumps

ve out. The reason is simple - many haxies have ancient and scary code dating back to 2002. The APIs in the sy642-457 dumps

heck, some of it is no longer used because the OS has evolved but it is still there. Granted that we're SY0-301 dumps