39

I just upgraded to El Capitan, and when I tried updating brew I got the following error:

$ brew update
Error: 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.
  sudo chown -R $(whoami):admin /usr/local

Before I proceed with the chown recommendation, given that El Capitan just came out, is that the right way to proceed here? Why is this step necessary, and what are any potential undesirable consequences of running this command?

In case it helps, I found two issues about El Capitan in brew: 40837 and 41665 but a solution to this problem wasn't immediately clear. What can I do to continue to use brew in El Capitan reliably?

Improve this question
4
  • 2
    Well did you do as the message suggested, change ownership of /usr/local?
    – user3439894
    Commented Oct 3, 2015 at 22:32
  • This raises an excellent question for the case of multiple users (or one user with multiple accounts having different profiles) on the same machine.
    – Walt Stoneburner
    Commented Dec 20, 2015 at 15:23
  • 4
    Typing sudo chown -R gives me the willies. It doesn’t matter what the other parameters are. I have more than Homebrew in /usr/local, and it’s not an obviously-safe command. I confirmed via Time Machine that installing El Capitan chowned, exclusively, /usr/local, and not subdirectories. I was thus able to get away with doing a non-recursive reversion, i.e. sudo chown $(whoami):admin /usr/local. YMMV.
    – duozmo
    Commented Jan 11, 2016 at 5:02
  • @duozmo is right. The -R in sudo chown -R is really heavy handed. That's tantamount to Brew claiming domain over the entirety of /usr/local
    – HairOfTheDog
    Commented Nov 22, 2016 at 0:44

8 Answers 8

Reset to default
31

I mean they give you the solution right there. I had the same problem and I just ran:

  sudo chown -R $(whoami):admin /usr/local

and it worked.

Improve this answer
7
  • 1
    +1 I also needed to reset my user's permissions as described. No further issues after this little tweak - homebrew and my packages have been very reliable on 10.11.
    – bmike ♦
    Commented Oct 3, 2015 at 22:40
  • 22
    This doesn't really answer the question: One might assume that Apple locked down /usr/local for a reason and that this fix is NOT appropriate for El Capitan. I'm googling now to see if Apple provides some guidance. The question is "... given that El Capitan just came out, is that the right way to proceed here?"
    – Michael Welch
    Commented Oct 6, 2015 at 19:54
  • 1
    @MichaelWelch The answer was posted before that edit.
    – DisplayName
    Commented Oct 7, 2015 at 0:08
  • 1
    Sorry @DisplayName I should have looked at the timestamps.
    – Michael Welch
    Commented Oct 7, 2015 at 1:32
  • 2
    This is the correct answer. See github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/… - I ran $ brew doctor and discovered that a flac dependency was missing. After $ brew install flac I had to stubbornly run $ brew update a couple more times.
    – Ando
    Commented Oct 13, 2015 at 17:30
9

We no longer need to break our heads about this. I risked the advice and did the suggested permission change. Then, on updating to the latest homebrew I got this reassuring message:

Homebrew no longer needs to have ownership of /usr/local. If you wish you can return /usr/local to its default ownership with: sudo chown root:wheel /usr/local

Improve this answer
2
  • So how to solve this issue?
    – Rajesh Maurya
    Commented May 3, 2018 at 9:00
  • @RajeshMaurya use the solution by karolus
    – JannieT
    Commented May 3, 2018 at 11:32
8

Per some of the security questions above, the dialog does give instructions to reset after a successful brew update. After running

sudo chown -R $(whoami) /usr/local

And then

brew update

After the update has successfully run, the dialog should indicate doing this:

sudo chown root:wheel /usr/local

After that has been run, that should alleviate any security concerns with MacOS 10.12

Improve this answer
1
  • chown: /usr/local: Operation not permitted
    – Rajesh Maurya
    Commented May 3, 2018 at 9:01
6

The given solution did not work for me:

sudo chown -R $(whoami):admin /usr/local

This variation worked for me:

sudo chown -R $USER /usr/local/

Improve this answer
4
  • 1
    sudo chown -R $USER /usr/local/ worked for me on the latest macOS
    – Alex Trott
    Commented Sep 25, 2016 at 10:38
  • 1
    chown: /usr/local/: Operation not permitted
    – Rajesh Maurya
    Commented May 3, 2018 at 9:01
  • add sudo then type in root level password
    – Brian Spiering
    Commented May 3, 2018 at 15:12
  • 1
    Still chown: /usr/local/: Operation not permitted even if I type in the root password.
    – 2myCharlie
    Commented Jul 13, 2018 at 0:03
0

I fix it by use this command sudo chown -R admin /usr/local.

Improve this answer
-1

please look at the SIP with : 

csrutil status

the system integrity protection is fixed at "enable", with the last Apple attribute 'restricted": 

csrutil
Improve this answer
1
  • 3
    How does this solve the problem stated in the question?
    – nohillside ♦
    Commented Oct 9, 2015 at 6:30
-1

It worked for me.

sudo chgrp -R admin /usr/local
sudo chmod -R g+w /usr/local
Improve this answer
1
  • 1
    Both of these solutions do not work for me. It still shows: chown: /usr/local: Operation not permitted
    – 2myCharlie
    Commented Jul 13, 2018 at 0:02
-2

the system integrity protection needs to be disabled. You can do it with this.

sudo nvram boot-args="rootless=0";osascript -e 'tell app "loginwindow" to «event aevtrrst»’

This disables System Integrity Protection system wide. I believe you can also do it from the Recovery Mode. You still have to type in your root password when doing things with sudo, but you aren't locked out by SIP. You also don't then go opening up directories inadvertently trying to set permissions.

Improve this answer
1
  • 3
    There is no need to disable SIP in order to change ownership below /usr/local.
    – nohillside ♦
    Commented Oct 17, 2015 at 14:30

You must log in to answer this question.

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