How to figure out what is causing the ownership of /usr/local to change from my-username to root

I use homebrew as a package manager for certain web development app. To keep brew up-to-date I run update brew every couple of days and also run brew doctor. Usually, this is fine and brew tells me I'm ready to brew.

Every now and then, however, I get the following error:

Warning: /usr/local/etc isn't writable.

This can happen if you "sudo make install" software that isn't managed by by Homebrew. If a formula tries to write a file to this directory, the install will fail during the link step.

You should probably chown /usr/local/etc

Warning: The /usr/local directory is not writable. Even if this directory was writable when you installed Homebrew, other software may change permissions on this directory. Some versions of the "InstantOn" component of Airfoil are known to do this.

You should probably change the ownership and permissions of /usr/local back to your user account.

It's easy enough to reset the permissions back to my username. Afterwards brew seems to be fine.

But what is causing this to happen?

Is there a log that shows what is causing the permissions to change?


Solution 1:

I had this exact same issue, and it turns out Sophos auto-update was to blame. I figured this out by running: sudo fs_usage | grep "usr/local"

It took a while, but eventually I saw Sophos's helpfully named "Installation" daemon messing with /usr/local's permissions.

I'm still trying to figure out an appropriate work around for this behavior.

EDIT: I believe Sophos has fixed this issue, see the link in the comments of this answer. It seems to be fixed for me at least!

Solution 2:

Turns out Filewave is the culprit. Filewave is a system management software used by our school to push software updates. Thanks for the input.

Solution 3:

I have just a rough idea how get the permission thief. This is not a solution to your problem, but more some sort of workaround.

What about writing a watchdog in Automator or with Hazel (folder actions) for watching this particular folder but instead of adding a function like Scale images you just use a shellscript which executes several shell commands:

  • If the folder is changed in any way, just snapshot the permissions and the currently accessing process id with fuser <foldername>.
  • then you lookup in the process table the process id (ps auxwwwwww | grep <process id>) and finally
  • write an email to yourself with these collected informations.

Unfortunately I am no Automator sadhu, but I found out by Google there are plenty of solutions for such a similar problem.