13

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?

  • 3
    No log but note that having /usr/local owned by rood is the Unix standard and so any build into there will expect it. Solution is don't mix a directory with both package manager (Homebrew) and standard Unix compilation - Use another directory for one of them – Mark Sep 25 '15 at 17:19
  • 3
    Adding software to the same location as a package manger uses is a bad idea, and so is changing the ownership and permissions on /usr/local. But if you insist then you could make install without using sudo for packages that you install yourself. – fd0 Sep 25 '15 at 17:42
  • 1
    Upgrading OS X usually resets /usr/local ownership and permissions. – mspasov Sep 26 '15 at 7:59
  • 1
    @Others ah I read the quote from Homebrew rather than the question – Mark Sep 26 '15 at 13:22
  • 1
    What else did you install (manually or through any other package manager) on your Mac which was configured to default install in /usr/local? – dan Sep 28 '15 at 13:10
13

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!

  • 4
    There's a discussion here: community.sophos.com/products/free-antivirus-tools-for-desktops/… This should be fixed in November 2015 – JoeZuntz Oct 23 '15 at 15:04
  • @JoeZuntz Nice find! Awesome that they actually are pushing a fix. – Others Oct 23 '15 at 17:12
  • @others thanks for this info. I was able to fix everything after upgrading to 10.11.1 and got homebrew working again, but more often than not, each time I went to do a brew upgrade, the permissions had changed again. It was bugging me what software kept changing the perms on /usr/local. – Tim X Nov 14 '15 at 21:42
  • @TimX Yeah it kinda sucks... Luckily it looks like Sophos is patching it at the end of next week, November the 20th. – Others Nov 15 '15 at 7:09
4

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

2
+50

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.

0

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.

-1

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.

  • AFAICT, upgrading to El Capitan is what caused the problem for me – Giuseppe Oct 31 '15 at 7:02
-3

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?

  • 2
    Disk Utility wouldn't verify or repair permissions on /usr/local since this directory doesn't exist on a new install of Yosemite. – dan Sep 28 '15 at 13:14
  • I checkd this hypothesis fully on Yosemite by creating a new /usr/local belonging to me, and running DU. There isn't any /usr/local within the DU log. And /usr/local still belongs to me. – dan Sep 28 '15 at 14:00

You must log in to answer this question.

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