• On TechRepublic: Get 5 cool Microsoft apps -- for free
advertisement
mySimon mySimon mySimon Outdoor Gear mySimon Swimwear mySimon Home and Garden
May 4, 2006 7:45 AM PDT

mac.column.ted: Unravelling the Repair Disk Permissions controversy

by CNET staff
  • Font size
  • Print
  • 34 comments

Ted Landau
May 2006

Repairing Disk Permissions. Not exactly a topic that you would expect to spark much controversy. Yet, surprisingly, it is the focal point of a rather heated debate.

The command itself is innocuous enough. It is included as part of the First Aid component of Disk Utility. Apple's Help for Disk Utility states: "User permissions associated with files, folders, or applications can become damaged and prevent a file or application from opening. Permissions problems can also cause your computer to run slowly. Using Disk Utility, you may be able to fix these permissions problems...Repairing permissions may also be recommended after updating the system or installing new software."

Consistent with this, many users and Web sites (including MacFixIt and at least some postings on MacinTouch) recommend the use of Repair Disk Permissions, not only for specific signs of trouble, but as a part of generic troubleshooting and ongoing maintenance for your Mac.

In contrast, other members of the Mac community (writing in locations such as the Daring Fireball , Unsanity, and the MDJ) argue that running this command just for maintenance, in the absence of any particular symptom, is essentially worthless. Some critics go even further and claim there is no justification for ever selecting to repair permissions. Not only is it useless, they contend, but it may even cause new problems to appear. This viewpoint is often expressed with inflammatory rhetoric such as "covering yourself in Vaseline and rolling around naked in the dirt and repairing permissions are just as likely to fix your Mac OS X problem" (Unsanity).

Regardless of who's right or wrong, I don't believe that insulting users is merited here, especially when these users are simply following advice suggested by Apple itself. As it turns out, I also do not agree with the position of these critics. So, although I may be stepping into a minefield, here's my own take on this subject and my resulting recommendations. [Disclaimer: I was not involved in the authorship of previous MacFixIt articles on this subject. This column is my separate opinion, and does not necessarily reflect the views of MacFixIt.]: Continued

  • Repair Disk Permissions works by checking a list of permissions stored in archive.bom files, located in the "receipt" packages found in the /Library/Receipts folder. Receipt packages are placed in this folder when you install files via Apple's Installer utility. When Disk Utility finds a discrepancy between a file's current permissions and the ones listed for it in the relevant .bom file, it "fixes" them.

  • That said, the effect of running the Repair Disk Permissions command is a limited one. It can only verify and repair permissions of files:

    (a) that were installed via Apple's Installer utility, thereby leaving a receipt package in the /Library/Receipts folder (meaning, for example, the command will have no effect on software "installed" via a drag-and-drop or via a different installer utility);

    (b) for which the relevant receipt package(s) have not been moved or deleted from the Receipts folder;

    (c) that have not been moved from their originally installed location (such as the /Applications folder for most applications).

    Finally, as stated in an Apple Knowledge Base article, "Certain files whose permissions can be changed during normal usage without affecting their function are intentionally not checked."

  • Almost all Apple-installed software meets the above requirements. In addition, so do numerous third-party programs that similarly use Apple's Installer utility. However, Repair Disk Permissions may not fix incorrect permissions for some of these third-party files. I am still not certain of the cause of these omissions, but I have confirmed that they occur (although check out this MacFixIt article for more details regarding the vagaries of repairing permissions of third-party software). The net result is that the Repair Disk Permissions command is mainly, and most reliably, limited to fixing problems with Apple software.

  • As pointed out by critics, it is possible that running Repair Disk Permissions could replace correct permissions with incorrect ones. How can this happen? One situation is when the permissions for already installed software are wrong because the settings in the relevant archive.bom file were never correct to begin with. The developer may address this problem in various ways. One way is to release a "patch" application that fixes the permissions (bypassing the use of the Installer utility). The problem is that, because this does not affect the contents of the Receipts folders, when your next run Repair Disk Permissions, and assuming that Repair Disk Permissions actually affects this particular software, it will cause the file's permissions to revert back to the original and incorrect permissions.

    Although technically a possibility, it is a very remote one. Why? First, Apple addresses and prevents this issue for its own software via a special file that is included with Mac OS X Updates. The file, called HintFile.plist and installed in /System/Library/PrivateFrameworks/DiskManagement.framework/Versions/A/Resources, contains any updated and corrected permissions. Essentially, Disk Utility uses this file to assign updated permissions to previously installed files, overriding what the files' original receipt package data would otherwise dictate. Second, for third-party software, as already pointed out, Repair Disk Permissions often has no effect anyway. In any case, it should be the responsibility of the developer to make sure that any method they provide for updating permissions is not undone when the user runs Repair Disk Permissions.

    Still, the above situation is a major reason that critics contend that Repair Disk Permissions should never be used simply as a maintenance procedure. In other words, if it ain't broke, don't try to fix it. However, even this distinction is sometimes lost. For example, the title of an Unsanity site's article is Exercises in Futility Part 2: Repairing Permissions Is Useless. There is no suggestion here of a distinction between using the command for maintenance vs. repair. Quite the contrary, it suggests that you should never use the command under any circumstances, no how, no way, nada, zilcho (although the subsequent text of the article is not quite as extreme as the title would suggest).

  • Apple continues to include the Repair Disk Permissions command as part of Disk Utility, and offers no warnings against its use. To me, this is a tacit indication that Apple sees no problem with using the command. In the spirit of the Hippocratic Oath ("First, do no harm"), if Apple truly felt that running Repair Disk Permissions was potentially harmful, it should say or do something about it. Of course, Apple may have a different view. Still, it seems unfair to characterize users who place their faith in Apple's wisdom as "purveyors of superstition" (MDJ; the cited text is not available online).

    Critics have a rebuttal to this as well. They contend that Apple doesn't really recommend using the command, except in very limited ways. For example, Daring Fireball states: "To be fair to everyone who persists in believing that it is a periodic maintenance task, there is at least one Apple support documentation that hints that it is, but note the title of that document: 'My Computer Keeps Freezing or I See a Flashing Question Mark'." I guess the author is suggesting that Apple really only recommends the procedure if you cannot start up your Mac.

    The MDJ similarly notes that the quote from Disk Utility Help, as cited at the start of this column, "says the procedure 'may be recommended after updating the system or installing new software.' (Emphasis added.) The article does not say who may recommend this, or when that would happen." Again, the implication is that Apple is not really saying that Repair Disk Permissions is recommended; only that it may be recommended in certain non-defined situations.

    Actually, Apple does offer stronger and more specific recommendations on this matter. In two recent Knowledge Base articles (Mac Maintenance Quick Assist and Printing Quick Assist), it clearly includes Repair Disk Permissions on a list of suggested maintenance procedures.

    In the end, Apple tech documents are not likely to be a source of definitive "proof" for either position in this debate. Like turning to quotes from the Bible in religious debates, there is at least some fuel to be found for both sides. I would welcome a direct unequivocal reply from Apple on this controversy. But so far, they have not done so.

  • Finally, you may ask: beyond the examples cited above, how could a file that started with correct permissions later wind up with incorrect ones? That is, why should the Repair Disk Permissions command be needed at all?

    For starters, problems can occur when an Installer utility incorrectly modifies permissions for folders or files that are not part of what it installs. This can happen because, once you give your admin password to an Installer utility, it has the power to modify the permissions of virtually any file and folder on your drive. A poorly written script, used as part of the installation, can wind up unintentionally and incorrectly changing permissions. This is a rare occurrence these days, but it can happen.

    Additionally, performing any of an assortment of popular hints and tips can result in the modification of permissions. For example, as I will cover in upcoming installments of my tutorial series on .plist files, there are times when you might want to modify the content of .plist files in the /Library and /System/Library folders, or even in Unix directories. Depending upon how you do this, the ownership and permissions of these files may be changed (e.g., the ownership is typically changed from System to you). Running Repair Disk Permissions will restore these permissions back to their intended settings. For example, when I recently ran Repair Disk Permissions, it corrected permissions for: ./Library/Preferences/SystemConfiguration/preferences.plist, ./System/Library/CoreServices/Finder.app/Contents/Resources/default_smart.plist, and ./private/etc/authorization (which is a .plist file despite the absence of the .plist extension in its name). These were all files that I had modified.

So what does all of this mean in terms of if and when you should use Repair Disk Permissions?:

  • If you are having symptoms that Repair Disk Permissions could potentially help, especially problems opening files, run the command. The possible gains outweigh the minimal risks.

  • If you have "hacked" files outside of your Home directory, such as the .plist files I just mentioned, running Repair Disk Permissions can restore the correct permissions to these files. While things may run smoothly even if you do not do this, it's better for the files to have the intended permissions. If you know what you are doing, you could instead manually reset the permissions (via the file's Info window settings or via Terminal), but I see no reason to avoid using Repair Disk Permissions here.

  • Running the command periodically as part of a maintenance routine could potentially fix problems that might otherwise be overlooked. For example, the last time I ran the command, it reported and fixed errors to /System/Library/Automator/Activate Fonts.action. Still, if you are inclined never to run this command for strictly maintenance reasons, I would not argue with you. The potential benefit from doing so is minimal at best. And there remains a small risk that it could make matters worse.

  • You may occasionally see recommendations to run Repair Disk Permissions at specific other times, especially before and/or after installing a Mac OS X Update. In this case, I agree with those (such as Daring Fireball) that contend this has little or no merit. Anecdotes to the contrary are likely mistaken as to cause and effect.

In the end, I recommend being skeptical of extreme positions, whether a claim that it is essential to run Repair Disk Permissions regularly or never to run it at all. As is usually the case, the truth lies somewhere in between.

This is the latest in a series of mac.column.ted columns by Ted Landau. To see a list of previous columns, click here. To send comments regarding this column directly to Ted, click here. To get Ted's latest book, Mac OS X Help Line, click here.

Resources

  • MacFixIt
  • MacinTouch
  • Daring Fireball
  • Unsanity
  • MDJ
  • Continued
  • Apple Knowledge Base artic...
  • MacFixIt article
  • article
  • Mac Maintenance Quick Assi...
  • Printing Quick Assist
  • tutorial series on .plist...
  • Daring Fireball
  • click here
  • click here
  • click here
  • More from Mac Musings
  • Recent posts from MacFixIt
    Address Book: Search not working properly
    iTunes 9.0.3 breaks AirTunes connection for some
    Apple releases Aperture 3.0
    Manage iCal's automatic e-mail generation for invitations
    CNET TV Apple Byte: Apple faces critics
    Weekly Utilities Update: Net Monitor, MiniUsage, TimeMachineEditor, more...
    Odds and Ends: Essential video codec packs for OS X
    Address Book: Unable to add, view contacts
    Add a Comment (Log in or register) Showing 1 of 2 pages (34 Comments)
    by donikatz May 4, 2006 8:28 AM PDT
    great column! i'd just like to point out that while repairing permissions before and after an os update is no longer necessary in 10.3 or 10.4, it was definitely necessary in 10.2. poor scripting on apple's part back then? dunno, but permissions errors after os updates were a major source of headaches. i would recommend that legacy users who are still incrementally patching their jaguar systems should continue to repair permissions after os x updates.
    Reply to this comment
    by Rosyna--2008 May 4, 2006 8:38 AM PDT
    The very first point in this article is wrong. It doesn't scan the /Library/Receipts/
    folder. It only looks for about 15 specifically named receipts that are hard coded
    into disk utility. All of them are ones that are included with OS X only. No third
    party software receipts are every checked.
    Reply to this comment
    by jacksonbrowny May 4, 2006 8:38 AM PDT
    >
    This is a reply to a previous comment by Rosyna--2008


    Then how, pray tell, did repairing permissions resolve an issue with a third-
    party application -- Parallels -- as discussed in this article?: http://
    www.macfixit.com/article.php?story=20060413075624652

    BTW, aren't you Rosyna who wrote the highly flawed Unsanity article?
    Reply to this comment
    by bmichel May 4, 2006 8:38 AM PDT
    >>
    This is a reply to a previous comment by jacksonbrowny


    Repair disk permissions find ANY .bom files within the /Library/Reciepts folder and compares them to files on the hard drive. The package files within the reciepts folder contain an archive.bom file, which lists all of the files related to that specific package or app, and what all of their permissions should be. If you look in your Library/Reciepts folder, you will notice a bunch of 3rd party packages, i.e. I have symantec installed, so I have about 6 different symantec packages in my reciepts folder.

    I personally think Repair Disk Permissions should only be done if you have a permissions issue (i.e. A file that should be working doesn't because of permissions issues) and generally do not run it as part of my maintence. I don't think it really hurts anything, unless you've been changing permissions of a lot of different files.
    Reply to this comment
    by Rosyna--2008 May 4, 2006 8:38 AM PDT
    >>
    This is a reply to a previous comment by jacksonbrowny


    How did it fix the problem? Simple. It didn't.

    "We then used Apple's Disk Utility to repair permissions. Although Disk Utility
    did not specifically report any repairs, and there was no recognition of any
    changes in the Finder (the Parallels icon was still a generic folder, with the
    locked symbol and the circular red "No Access" indicator)"

    That alone says nothing changed.

    I've just tried repeatedly on my Mac. It fails every time. Note that there is a
    bug in the Finder that will make the Get Info window display the incorrect
    permissions. Every time I ran repair permissions Parallels remained
    unlaunchable and the permissions remained as 055 rosyna:wheel. In order to
    get the permissions to stick, I had to relaunch the finder.

    The fact he couldn't launch it beforehand was more likely a bug in the Finder
    Tool that didn't correctly set the permissions.
    Reply to this comment
    by May 4, 2006 8:38 AM PDT
    >>>
    This is a reply to a previous comment by Rosyna--2008


    Hi, this is Ben Wilson (one of the authors involved in the original MacFixIt
    piece). Despite your assertions to the contrary, repairing permissions did
    indeed resolve the (user-created) issue with Parallels. We're not sure where
    you're getting your information from -- or how exactly you are performing
    your version of the permissions fix -- but this test was repeated multiple
    times on different systems with the exact same result. The Finder was never
    re-launched during any of these tests.

    Again, the exact procedure:

    "We set permissions for this application to "No Access" under the "Ownership
    and Permissions" section of the Get Info window, and set the owner as current
    logged in administrator. We then locked the file. The Parallels application icon
    switched a generic folder icon, and the application could not be launched --
    providing no error message, but simply not launching.

    "We then used Apple's Disk Utility to repair permissions. Although Disk Utility
    did not specifically report any repairs, and there was no recognition of any
    changes in the Finder (the Parallels icon was still a generic folder, with the
    locked symbol and the circular red "No Access" indicator), the application now
    launched correctly.

    "This series of operations -- changing the file from "Read and Write" access
    to "No Access" back and forth, then repairing permissions again -- was
    repeated several times with similar results. An application that was unable to
    launch because of incorrect permissions before running Disk Utility could
    subsequently be launched."

    BTW, I was wondering how exactly your determined that Disk Utility only
    scans a specific set of Apple-only software, since this is patently false
    information as corroborated by Apple, numerous third-party developers and
    other users.

    Thanks for your feedback.
    Reply to this comment
    by Rosyna--2008 May 4, 2006 8:38 AM PDT
    >>>>
    This is a reply to a previous comment by benwilson


    Actually, it seems the fact it doesn't launch at all is a Finder bug.

    I have been able to reproduce what you're seeing. However, repair
    permissions is definitely *not* fixing it. The problem remains the Finder.

    Try this. Get yourself in the same situation. Then type:

    sudo du -s /

    In the terminal (this just gets the file size of all files on the boot HD).

    Then magically you can launch Parallels again.

    Furthermore if you type:

    ls -AFldo /Applications/Parallels/Parallels.app

    Before and after the permissions repair, you will see that the permissions
    haven't changed at all.

    How do I know that Repair permissions only searches specific files? Simple. I
    know how to look it up.

    The DiskManagementTool is what actually does the repairing of permissions
    (you can see this in Activity Viewer when you are repairing permissions). It
    has a list of hardcoded receipts it checks against. You can see this list by
    typing

    strings /System/Library/PrivateFrameworks/DiskManagement.framework/
    Resources/DiskManagementTool | grep Receipts

    This produces a list of 46 items:

    /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom
    /Library/Receipts/Essentials.pkg/Contents/Archive.bom
    /Library/Receipts/AdditionalEssentials.pkg/Contents/Archive.bom
    /Library/Receipts/BSD.pkg/Contents/Archive.bom
    /Library/Receipts/BSDSDK.pkg/Contents/Archive.bom
    /Library/Receipts/X11User.pkg/Contents/Archive.bom
    /Library/Receipts/X11SDK.pkg/Contents/Archive.bom
    /Library/Receipts/CommonAccessCard.pkg/Contents/Archive.bom
    /Library/Receipts/CommonCriteriaTools.pkg/Contents/Archive.bom
    /Library/Receipts/Internal.pkg/Contents/Archive.bom
    /Library/Receipts/FatLibraries.pkg/Contents/Archive.bom
    /Library/Receipts/DevDocumentation.pkg/Contents/Archive.bom
    /Library/Receipts/DevExamples.pkg/Contents/Archive.bom
    /Library/Receipts/DevSDK.pkg/Contents/Archive.bom
    /Library/Receipts/DeveloperTools.pkg/Contents/Archive.bom
    /Library/Receipts/Java.pkg/Contents/Archive.bom
    /Library/Receipts/DevInternal.pkg/Contents/Archive.bom
    /Library/Receipts/DevFatLibraries.pkg/Contents/Archive.bom
    /Library/Receipts/AddressBook.pkg/Contents/Archive.bom
    /Library/Receipts/Automator.pkg/Contents/Archive.bom
    /Library/Receipts/Mail.pkg/Contents/Archive.bom
    /Library/Receipts/MigrationAssistant.pkg/Contents/Archive.bom
    /Library/Receipts/OxfordDictionaries.pkg/Contents/Archive.bom
    /Library/Receipts/iCal.pkg/Contents/Archive.bom
    /Library/Receipts/iChat.pkg/Contents/Archive.bom
    /Library/Receipts/iTunes.pkg/Contents/Archive.bom
    /Library/Receipts/MicrosoftIE.pkg/Contents/Archive.bom
    /Library/Receipts/Safari.pkg/Contents/Archive.bom
    /Library/Receipts/AdditionalFonts.pkg/Contents/Archive.bom
    /Library/Receipts/AdditionalAsianFonts.pkg/Contents/Archive.bom
    /Library/Receipts/BrotherPrinterDrivers.pkg/Contents/Archive.bom
    /Library/Receipts/EpsonPrinterDrivers.pkg/Contents/Archive.bom
    /Library/Receipts/CanonPrinterDrivers.pkg/Contents/Archive.bom
    /Library/Receipts/HewlettPackardPrinterDrivers.pkg/Contents/Archive.bom
    /Library/Receipts/LexmarkPrinterDrivers.pkg/Contents/Archive.bom
    /Library/Receipts/GimpPrintPrinterDrivers.pkg/Contents/Archive.bom
    /Library/Receipts/ElectronicsForImagingPrinterDrivers.pkg/Contents/
    Archive.bom
    /Library/Receipts/RicohPrinterDrivers.pkg/Contents/Archive.bom
    /Library/Receipts/XeroxPrinterDrivers.pkg/Contents/Archive.bom
    /Library/Receipts/QuickTimeStreamingServer.pkg/Contents/Archive.bom
    /Library/Receipts/ApplicationsServer.pkg/Contents/Archive.bom
    /Library/Receipts/ServerFatLibraries.pkg/Contents/Archive.bom
    /Library/Receipts/ServerInternal.pkg/Contents/Archive.bom
    /Library/Receipts/ServerAdminTools.pkg/Contents/Archive.bom
    /Library/Receipts/ServerSetup.pkg/Contents/Archive.bom
    /Library/Receipts/ServerEssentials.pkg/Contents/Archive.bom

    Notice how the /Library/Receipts/ folder itself is *not* on that list? The items
    in this list are the only items it will ever check. Ever. Some of them were never
    released to consumers (I imagine because they were around for the dev
    versions of 10.0.0). Some are very old, like the IE one.

    Everyone that says it checks third party receipts is wrong. Including if Apple
    says it Apple also said that SuperDrives didn't support DVD+R for the longest
    time, even though they did. All of these packages listed above were included
    with at least one Version of OS X client or OS X Server. Parallels is not in that
    list.
    Reply to this comment
    by Gennx30 May 4, 2006 8:38 AM PDT
    >>>>>
    This is a reply to a previous comment by Rosyna--2008


    Ive always wondered if this could be a source of problems: OLD BOM files in receipts-ie: iTunes: 6.0.0; 6.0.1; 6.0.2; 6.0.3; 6.0.4; etc...?
    Would deleting all but 6.0.4 make any difference one way or the other?
    Reply to this comment
    by Rosyna--2008 May 4, 2006 8:38 AM PDT
    >>>>>>
    This is a reply to a previous comment by Gennx30


    No, the BOM names I listed before are absolute. It doesn't check for newer
    BOMs. that's why the Hints.plist file has to exist since if permissions are
    changed from the Default in the 10.x.0 install for security reasons (like /Library/
    Widgets/ was) there would be no way for it to know about the new, correct
    permissions if not for the hints file. Removing the other versions but the base
    iTunes.pkg should be fine. But, in this example, do not remove iTunes.pkg.
    Although I wouldn't recommend removing any of them since the Installer.app
    does check these to handle upgrades and deleting them may result in
    Installer.app suggesting you reboot when no reboot is required.
    Reply to this comment
    by Gennx30 May 4, 2006 8:38 AM PDT
    >>>>>>>
    This is a reply to a previous comment by Rosyna--2008


    yeah thats what I actually meant-keep the original BOM for iTunes AND the very latest 6.0.4-toss the others in between-have seen no problems from that
    Reply to this comment
    by ted1--2008 May 4, 2006 8:38 AM PDT
    >>>>>
    This is a reply to a previous comment by Rosyna--2008


    <Everyone that says it checks third party receipts is wrong.>

    FWIW, as far as I have been able to tell in my own testing, it seems you are
    correct. That is, every time I have modified a third-party file for which there is
    a receipt package, it failed to have any effect. At the very least, no repair was
    listed in Disk Utility's output.

    Assuming this is so, the confusion apparently stems from the fact that the
    command may fix third-party SOFTWARE but not through accessing a third-
    party receipt file. Rather, it works because the software is included in Mac OS
    X's basic installation (as in the Flash plug-in example cited here).

    Still, except for my suggestion that the command may in fact read third-paty
    receipts (which I already said was rare and not reliable at best), it does not
    affect any of the points and recommendations I made about the command in
    general. At least not in my view.

    - Ted
    Reply to this comment
    by Rosyna--2008 May 4, 2006 8:38 AM PDT
    >>>>>>
    This is a reply to a previous comment by ted1--2008


    No, but your article appears to suffer the same issue mine did. It was written
    with the idea that third party software was repaired when repairing
    permissions. This changes the entire "feel" of the article, intentional or not.

    The reason I know first hand about third party software not being affected as
    we make software that is *extremely* permission sensitive (for security
    reasons). However, due to the way people incorrectly backed up their
    software (by not unchecking "ignore permissions" on the backup disk) our
    software was frequently owned by uid 501 or user nobody. This would also
    happen if people used the migration assistant. So we looked into seeing if it
    was possible to fake a Receipt so repair permissions would look at it. This
    involved largely reverse engineering the repair permissions process. It all lead
    to the fact there was no way to get OS X to repair us without modifying a core
    receipt file (a system installed one) and that was *far* too dangerous to even
    attempt. So the idea was ultimately scrapped.

    It's actually good for security that third party software cannot get their
    permissions repaired. The last thing anyone would want is software that
    installs a package that overwrites OS X's permissions in a bad way or software
    that insists on having permissions that are a huge security risk. Like
    enforcing permissions on an application owned as root that is world writable.
    So not being able to repair permissions on third party software ends up being
    a security *feature*.
    Reply to this comment
    by Doctor J May 4, 2006 8:38 AM PDT
    >
    This is a reply to a previous comment by Rosyna--2008


    Theory must agree with observation. Here's the report:


    Determining correct file permissions.

    User differs on ./Library/Internet Plug-Ins/Flash Player.plugin/Contents/
    Info.plist, should be 0, owner is 501

    User differs on ./Library/Internet Plug-Ins/Flash Player.plugin/Contents/
    MacOS/Flash Player, should be 0, owner is 501

    User differs on ./Library/Internet Plug-Ins/Flash Player.plugin/Contents/
    version.plist, should be 0, owner is 501

    User differs on ./Library/Internet Plug-Ins/flashplayer.xpt, should be 0,
    owner is 501

    Permissions differ on ./Library/Internet Plug-Ins/flashplayer.xpt, should be -
    rw-rw-r-- , they are -rw-r--r--

    Permissions differ on ./private/var/log/secure.log, should be -rw------- ,
    they are -rw-r-----

    The privileges have been verified or repaired on the selected volume
    Reply to this comment
    by Rosyna--2008 May 4, 2006 8:38 AM PDT
    >>
    This is a reply to a previous comment by Doctor J


    Except it's not quite third party software. It was included with OS X so it's listed
    in the OS X packages. Specifically, it's listed in /Library/Receipts/Essentials.pkg/
    Contents/Archive.bom which DiskManagementTool does look at.

    The reason it incorrectly marks them as wrong is because you installed a Flash
    plugin update from Adobe/Macromedia's website. Since you installed it as an
    admin, it does not ask for a password. And because it doesn't ask for a
    password, it cannot set the owner to root (it's a security feature). Then when you
    run permissions again, it sees the file is listed in /Library/Receipts/
    Essentials.pkg/Contents/Archive.bom and resets the permissions to what's
    inside that file.
    Reply to this comment
    by ted1--2008 May 4, 2006 8:38 AM PDT
    >>>
    This is a reply to a previous comment by Rosyna--2008


    <The reason it incorrectly marks them as wrong is because you installed a
    Flash plugin update from Adobe/Macromedia's website.>

    Regardless of the reason above, if you assume that having Disk First Aid
    modify the permissions is a desirable change, then this argues in favor of
    running Repair Disk Permissions at least occasionally for maintenance
    reasons and/or after installing certain third-party software. Otherwise, the
    "incorrect" permissions for Flash would remain - at least until they
    precipitated a symptom that was clear enough to indicate to the user that
    running the Repair Disk Permissions command was needed.

    - Ted
    Reply to this comment
    by Zeds Dead May 4, 2006 8:38 AM PDT
    >
    This is a reply to a previous comment by Rosyna--2008


    I manage a large number Macs. About once every 6 months, repair
    permissions helps get a Mac that is misbehaving working correctly. I can't be
    there to hold the user's hands for everything they install, so I have no idea
    how their permissions got out of whack. But they did. And after repair
    permissions, things work again.

    Why is that such a problem? I'm not lying here--I'm just saying it happens.
    And I completely don't understand why you have such a huge need to stop
    users from doing something that has a better chance of helping their system
    then harming it?

    Admittedly, it may be in the class of items like "rebuilding the desktop" from
    OS 9, and I stop users if I see them starting to run it frequently and with no
    reason why they're doing it, but seriously. It hasn't ever broken a system I
    manage to run permissions. It HAS fixed one.
    Reply to this comment
    by Rosyna--2008 May 4, 2006 8:38 AM PDT
    >>
    This is a reply to a previous comment by Zeds Dead


    The problem is that so many people that say that repairing permissions fixed
    something didn't actually have anything fixed. One of the common reasons is
    that they also reboot after doing a permissions repair. This causes every single
    system service to relaunch anew. So if one of them was deadlocked beforehand
    (like coreaudiod) and was causing the actual problem then it was the reboot that
    "fixed" it. Not the permissions appear. But people will attribute it to permissions
    repair since it has a pretty log file that up until 10.4.6 logged a bunch of useless
    status messages every single time you hit repair permissions.
    Reply to this comment
    by BrianMarsh May 4, 2006 8:38 AM PDT
    >>>
    This is a reply to a previous comment by Rosyna--2008


    I do not reboot after running repair permissions, and have had it fix problems

    mostly in 10.2 days, mostly printing issues (likely bad installers)

    very rarely in 10.3 & 10.4 has it fixed a "strange" issue on a clients machine
    (and if I'd have known how much this would blow up now, I'd have kept log
    files of what was fixed) again, without a restart, things start working again.
    (in many cases, the client had restarted several times, or even shut down to
    bring the machine to me)

    almost as often I've seen filesystem corruption be the cause of problems as
    well

    but as many have indicated, it is usually more efficient to actually trace the
    problem, and fix it, over the phone this is a daunting task with an average
    user (even something as simple as reading a log file will result in many errors
    in words) and can take 10x longer then in person.
    having the user run repair permissions and try to see if that fixes things is
    quick, and even if it's not what actually fixed the issue for the client, has
    often enough for me got them up and going immediately until a time when I
    can possibly trace the real problem if it comes back.

    In Mac OS 9 (and earlier) zapping PRAM & rebuilding desktop were rarely
    needed, but were quick & easy (and I had enough users with suddenly generic
    icons, and couldn't double-click on a file to open the right program) to make
    it worth while to try first, when that didn't work, try to trace what's really
    going on, or arrange to visit in person.

    not everyone has direct access to a machine that isn't working properly, not
    everyone has high-speed internet (to make ARD/VNC worth using)
    Reply to this comment
    by RockySalim May 4, 2006 8:38 AM PDT
    >
    This is a reply to a previous comment by Rosyna--2008


    Regardless of theory, the outcome is important.

    In the medical field, there are all kinds of explanations for why certain treatments work. For example, chewing a certain bark was found to reduce inflamation and relieve pain. At the time people believed the tree had magical powers, but we later discovered that the tree produced an aspirin-like drug in its bark.

    The same is true of permissions and OSX. UNIX operating systems are very reliable and typically do not have the same issues as windows machines. Usually if something is not working, it is a configuration or permission issue.

    We have a few hundred Macs that we support. Most are on 10.3.9, but we have a few others in the mix. We have four tools that fix almost anything. Three of these correct permissions. These are the disk utility, Applejack and Onyx. The ramaining tool is Disk Warrior. Applejack also has additional utilities such as an fsck-like disk repair and Onyx also has maintenance and optimization scripts.

    We frequently have to find solutions by trial and error. No matter how we choose to explain it, more than half our Mac issues are resolved by correcting permissions.

    If you want to call it magic, so be it. But we have to do what works and that's why I look at permissions first when troubleshooting an issue.
    I will say, though, that we do not generally correct permissions unless there is a problem of some kind.

    -rocky
    Reply to this comment
    by Rosyna--2008 May 4, 2006 8:49 AM PDT
    And the point of the Unsanity article is. You can either waste time by repairing
    permissions, or you can go about correctly diagnosing a problem. Incorrect
    permissions on an Automater Action is not going to make your computer
    explode or misbehave.

    Just because Disk Utility throws a status message, doesn't mean there is
    something wrong.
    Reply to this comment
    Showing 1 of 2 pages (34 Comments)
    advertisement

    About MacFixIt

    MacFixIt is CNET's troubleshooting resource for all things Mac. The information here helps you navigate the ins-and-outs of Mac ownership with how-tos, troubleshooting information, news, reviews, and more.

    Add this feed to your online news reader