Take the 2-minute tour ×
Ask Different is a question and answer site for power users of Apple hardware and software. It's 100% free, no registration required.

I just upgraded from Snow Leopard to Lion and am trying to get Homebrew installed. However after the installation, I run brew doctor per the installation instructions, and see a series of errors indicating that /usr/local directories aren't writable. For example:

Error: /usr/local/share isn't writable.
This can happen if you "sudo make install" software that isn't managed
by Homebrew.

If a brew tries to write a file to this directory, the install will
fail during the link step.

You should probably `chown` /usr/local/share

I get these for a bunch of directories:

You should probably `chown` /usr/local/include

You should probably `chown` /usr/local/share

You should probably `chown` /usr/local/share/man

I can't figure out why this error is coming up, as it appears that I am part of the Unix group that has write permissions to these directories:

Mini:~ felciano$ ls -ld /usr/local/share
drwxrwxr-x  4 root  admin  136 May 13 15:53 /usr/local/share
Mini:~ felciano$ whoami
felciano
Mini:~ felciano$ dscl . -read /Groups/admin GroupMembership
GroupMembership: root felciano
Mini:~ felciano$

What am I missing?

share|improve this question
    
Why don't you "chown" these directories to your user name, as suggested ? They should not belong to "root" anyway. For multiple users you could also change the group permissions: apple.stackexchange.com/q/42127/14994 –  iolsmit May 20 '12 at 10:21
    
@iolsmit: I have the exact same problem. However, I don't see why /usr/local should belong to me instead when this machine has multiple admin users. Also, It is possible for me to write to the locations brew doctor is complaining about. Any other ideas? –  mgd Jun 23 '12 at 10:08
add comment

4 Answers 4

EDIT: The problem is now fixed in Homebrew:

If you still experience the problem, update Homebrew like this:

brew update

If you want to know what the problem was, I have kept my original answer below.


Ignore the permisson issue for now

I am experiencing the exact same problem and in my opinion the problem is in brew doctor rather than in your and my installation.

I think you should ignore the issue rather than changing the ownership of /usr/local. Alternatively, you could fix your local brew doctor script until a fix is released. See below.

I don't consider it correct to make /usr/local owned by a specific user. I have more than one admin user on this machine. You should leave /usr/local owned by root:admin as owner and group.

My investigation

Like for you I have a /usr/local that is perfectly writable by my user which is also a member of the admin group:

$ ls -ld /usr/local/
drwxrwxr-x  14 root  admin  476 22 Jun 23:33 /usr/local/
$ whoami
mgd
$ dscl . -read /Groups/admin GroupMembership
GroupMembership: root mgd rgd

Let's test that the dir is really writable:

$ ls -l /usr/local/newfile
ls: /usr/local/newfile: No such file or directory
$ touch /usr/local/newfile
$ ls -l /usr/local/newfile
-rw-r--r--  1 mgd  admin  0 23 Jun 14:52 /usr/local/newfile

Further investigation into the brew doctorcode led my to the conclusion that the use of the ruby function Pathname.writable? is causing the problem. Consider this interactive Ruby session:

$ irb
>> require 'pathname'
=> true
>> Pathname('/usr/local').writable?
=> false

Function Pathname.writable? says /usr/local is not writable even though we know it is.

Using Pathname.writable_real? instead gives the correct result – it says that the dir is writable:

>> Pathname('/usr/local').writable_real?
=> true

This should be fixed in /usr/local/Library/Homebrew/cmd/doctor.rb. You can fix it in your own installation while waiting for a fix.

The difference between the two functions are (according to the Ruby docs here and here):

writable?(file_name) → true or false: Returns true if the named file is writable by the effective user id of this process.

writable_real?(file_name) → true or false: Returns true if the named file is writable by the real user id of this process.

share|improve this answer
    
Thumbs up for mgd's investigation and clarification... it's spot on! It appears that a similar issue was raised on github.com about a year ago, but was never (properly?) resolved, at least not by using writable_real? ... maybe it's time for a pull request?!? :-) –  pvandenberk Jul 9 '12 at 15:12
    
Fixed: github.com/mxcl/homebrew/commit/… –  mxcl Aug 7 '12 at 2:07
    
+1 For going the extra mile –  TechZen Dec 13 '12 at 14:19
add comment

I believe you just need this:

brew update

Then try brew doctor again.

You might still get errors about any dependencies you aren't using (Java in my case), which is okay. If you have the Command Line Tools for Xcode installed instead of the full installation of Xcode you will also get an error message saying you have an invalid path, but right in the message you will also read that there is no valid path if you're just using the Command Line Tools for Xcode, so that's okay as well.

For the benefit of others: Keep in mind that you need to be logged in as an admin when doing this for it to work.

share|improve this answer
add comment

I followed a combination of iolsmit's and Phil M's suggestions: I chowned these directories to my username, then ran brew update again followed by brew doctor. This got rid of all the error messages and brew installations now seem to work nicely. Thank you both!

share|improve this answer
add comment

Thumbs up for @mgd's investigation and clarification... it's spot on!

It appears that a similar issue was raised on github.com about a year ago, but was never (properly?) resolved, at least not by using writable_real? ... maybe it's time for a pull request?!? :-)

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.