In Mac OS X, what causes the change in file permissions?

For example, consider that the operating system was terminated abnormally.

On a subsequent boot, randomly (or possibly those files that were open at the instant of termination) files have their permissions changed. They differ.

What is the cause?


2 Answers 2


First of all - random errors creep into any system. Modern hard drives have billions of bits stored and when you ask for a file to be written as 0101011 sometimes the machine writes 0101001 and if it's writing the permissions bits, there's your answer. If you do the math, assuming 99.99% accuracy would mean more than one error is on everyone's hard drive most of the time.

Things get cut off in the middle of finishing. Electrical noise crops up and messes up the signal, cosmic rays hit your memory chip and flip a bit, some program code isn't perfect so the math gets done wrong.

Then you have all the times another program wants to change the permissions and there is disagreement. Permission errors are usually logged to the system log so when you have a problem, have a look, maybe run permission repair to fix up the programs installed by apple.

When in doubt - go to the source:

  • Thanks for a succinct answer. The majority of the permission errors I have observed in my Mac occur with Java (1.6.0 jdk), and the JavaVM.Framework. They occur repeatedly.
    – meh
    May 11, 2011 at 17:02
  • Something like that sounds programatic or software since random errors should be distributed randomly. FSeventer or fs_usage might be worth deploying to see who is accessing those files. Highly concerning to have developer code self destructing like that. I might add them to a spotlight and time machine exclusion list temporarily to see if it's a collision of worlds between fseventsd / mds and java file IO. Curious if your filesystem is HFS+ journaled case-insensitive. I've seen other fs choices go wonky from time to time.
    – bmike
    May 11, 2011 at 21:27
  • @neoneye, @bmike : Used FSEventer. The permissions change occurs in the same aforementioned directory, and each time Disk Utility "repairs" it, the permissions revert to their previous state, and this seems to be stuck in an endless loop. Possibly a conflicting configuration change by an application, or recurring false alarms by Disk Utility? I don't see any changes occurring prior to running Disk Utility though.
    – meh
    May 12, 2011 at 5:34
  • Wow. Keep in mind that Disk Utility just reads the receipts database that say how Apple wanted the files to be installed. If another program modifies them, Disk Utility doesn't agree with the changes so it's a game of cat and mouse. We know the cat is Disk Utility - fs_usage might let you know which program is the mouse.
    – bmike
    May 12, 2011 at 15:54
  • Disk utility repairs the permissions, yet on a subsequent re-run of Disk Utility, the same permissions which got repaired are repaired again. I kept fs_usage running, there was no application/process which attempted an access to said directories/files. Could it be that Disk utility's attempted repairs on these folders/files aren't working at all?
    – meh
    May 13, 2011 at 12:22

The answer above is wrong - if one bit on the disk changes, the ECC on the disk will correct it, or the e.g. a application image will become unusuable - cause a "segmentation violation". Change a bit in the node that refers to a file - and the file may be useless.

Do not muck around when you answer "bmick". You obviously do not know enough about hardware and operating systems. In better servers, even the RAM will use ECC to avoid single bit errors.

I see this consistently in the Java VM framework. And the bug is probably what you describe: That a new version of Java VM has changed SUID, the Disk Utilty use a wrong repository for what file permission is supposed to be.

Now Apple, the "Disk Utility" is GNU Open source. Update your repositories when new 3rd party OS components are installed. This makes the software run with apparent hang-ups. The modifications blocks access to files and makes the applications hang and even loose files and make databases corrupt.

To help you, Thunderbird works fine on Linux/Ubuntu, and I can even access the MacOS files from the Ubuntu partition. On MacOS I loose files - and get "Permission Inconsistency". You can look at the Linux list of bugs with HFS+, where they describe this error - that file permission is changed, where this is blamed on the journal update of files that remain open when the system is taken down - "Synced()".

Now, HFS+ on Linux will close the files, and flush the journal. MacOS' journal is not flushed on time, and updated later, and when a "Force Quit" is done you risk an error. Then you update with the wrong answer you introduce errors and for others to replicate these errors are very difficult, because they have exercised extensive effort to find out what they do wrong.

We will not use Ubuntu to correct MacOS, it is so much easier to use Ubuntu without the bugs.

  • Thanks for chiming in with the Java VM expertise. Reading the comments after the question was posed, it sure looks like this was a case of "some program code isn't perfect so the math gets done wrong"
    – bmike
    May 27, 2011 at 20:45
  • I just troubleshot and fixed an error for a customer where file uploads hanged forever. It turned out the execute permissions on /private/tmp were removed, so quicklook stood there with its mouth open, blocking the upload. I've always wondered why I can use a Mac for light desktop use for 3 months and end up with 100 permissions changed behind my back, but use any distro of Linux for 2 years and never see a permission change unless I initiate it. This answer explains it partly, but this still feels like one of the uglier parts of OSX to me
    – labyrinth
    Dec 8, 2015 at 15:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .