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

Question

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?

Answer 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!

Answer 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.

Answer 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.

Answer 4

If you use Time Machine, you can find the approximate time when permissions changed by exploring Backups.backupdb in Terminal. Use ls -ld in the timestamped folders, e.g.

ls -ld /Volumes/Backup/Backups.backupdb/Mac/2015-12-25-120000/Macintosh\ HD/usr/local 

Which will show owner and group information.

Once you have the date the change occurred, you can sleuth out what else might have changed then on your system. A simple technique is to use Finder's File › Find and add a Last modified date criterion. Other good tools are find and mdfind in Terminal.

Answer 5

This is a side effect of updating your system; OS X probably does some across-the-board permission "repair" during the update process as /usr/local is nested in a root-owned folder.

Answer 6

Have you used Disk Utility select Macintosh HD then run Verify Disk Permission and then Repair Disk Permission if needed, rather than doing it manually?

Now this shouldn't fix on your issue, but it's a good 'known' starting point to see when home-brew changes the permissions. It could show up the underlying issue if you are luck.

Also new update -v for more verbose output, plus old logs are here ~/Library/Logs/Homebrew as per Where does homebrew log?