How to use Homebrew on a Multi-user MacOS Sierra Setup
Solution 1
(Deleted as of 2020, this answer is outdated)
Solution 2
You can also change the group permissions to admin or another group that both of your users are in:
chgrp -R admin /usr/local
chmod -R g+w /usr/local
Original source: https://gist.github.com/jaibeee/9a4ea6aa9d428bc77925
UPDATE:
In macOS High Sierra you can't change the owner, group or permissions of /usr/local
. So you have to change the group and permissions of the subfolders:
chgrp -R admin /usr/local/*
chmod -R g+w /usr/local/*
UPDATE September 2018, High Sierra 10.13.6
- Determine the path of the brew prefix, ie. the path that will be used to store files related to working with homebrew
- Check that all users on the system who need access to
brew
are in the admin group -
Optional Add a user to the admin group if a user needs access to brew
Will require access / privileges to use the sudo command
- Set the brew prefix path to be recursively owned by the admin group
- Set the brew prefix path to be recursively writable by all users who are in the admin group
- Verify the permissions of the brew prefix
- brew 🍻
echo $(brew --prefix)
echo $(groups $(whoami))
sudo dseditgroup -o edit -a $(whoami) -t user admin
sudo chgrp -R admin $(brew --prefix)
sudo chmod -R g+rwX $(brew --prefix)
ls -lah $(brew --prefix)
Solution 3
Every answer that tries to hack permissions, or use sudo
is wrong.
Do not use sudo
and do not share a single brew installation across user accounts.
The correct answer per the Homebrew docs is to use zero or one global brew installation on a machine, and for all other users install a local version of brew.
This is especially important on Mac, but works on Linux too.
This can be done by one of the following approaches
-
Git approach
: doing a git checkout of the source repo -
Untar-anywhere approach
: expanding a tarball into some directory – owned by your user
Git approach
For the git approach you'll need to clone brew.
Arbitrarily choosing my user home directory for my checkout:
cd $HOME
git clone https://github.com/Homebrew/brew.git
./brew/bin/brew tap homebrew/core
Untar-Anywhere Approach
As documented at docs.brew.sh, run this command in your home directory, which will create ~/brew
.
cd $HOME
mkdir brew && curl -L https://github.com/Homebrew/brew/tarball/master | tar xz --strip 1 -C brew
Finishing up
For either installation method, you'll need to change your PATH
to prefer the new brew bin directory, adding something like this to your shell's dot file.
export PATH=$HOME/brew/bin:$PATH >> ~/.zshrc # or ~/.bashrc
Then running this to reload and test
exec $SHELL
which brew # see that brew is found in your path
Since this is a new installation, you have to install all your desired brew packages (again).
Solution 4
Install homebrew for each user
According to the brew documentation you can install it inside each User Home folder
That way all packages are going to stay inside your user folder, and will not be visible or affect other users. As a good side effect if you delete that user, no trash is left behind on your system. So system wide pollution is minimised.
This comes at the cost of more storage being used, if you install the same package for multiple users. Just something to be aware if you have a very small SSD.
Instructions
-
If you currently have brew installed on your system globally, I recommend uninstalling brew first. (You can see where brew is installed running
which brew
) -
If you don't have Command Line Tools installed, you have to run this first:
xcode-select --install
-
Open terminal and Run:
- MacOS Catalina 10.15 or newer:
cd $HOME mkdir homebrew && curl -L https://github.com/Homebrew/brew/tarball/master | tar xz --strip 1 -C homebrew echo 'export PATH="$HOME/homebrew/bin:$PATH"' >> .zprofile
- MacOS Mojave 10.14 or older:
cd $HOME mkdir homebrew && curl -L https://github.com/Homebrew/brew/tarball/master | tar xz --strip 1 -C homebrew echo 'export PATH="$HOME/homebrew/bin:$PATH"' >> .bash_profile
- MacOS Catalina 10.15 or newer:
-
Close the Terminal window
-
Open Terminal again, and run this to ensure your installation is correct:
brew doctor
-
Done!
Disabling auto update
This is not required I also find useful to disable brew to update all packages before every time you install something.
- MacOS Catalina 10.15 or newer
echo 'HOMEBREW_NO_AUTO_UPDATE=1' >> $HOME/.zprofile
- MacOS Mojave 10.14 or older
echo 'HOMEBREW_NO_AUTO_UPDATE=1' >> $HOME/.bash_profile
Solution 5
EDIT: Please use the answer by Vitim, it's the correct one :)
Hacky workaround solution for macOS Mojave 10.14
This is a edited version of user4815162342's answer, which didn't work for me out-of-the-box.
- In System Preferences, go to Users & Groups, click the lock symbol in the bottom left corner to unlock user/group creation, then create a new group called
brew-usergroup
. Add all users who work with brew to the group (like in the attached screenshot from a german macOS).
-
In terminal, do this:
echo $(brew --prefix) echo $(groups $(whoami)) sudo dseditgroup -o edit -a $(whoami) -t user brew-usergroup sudo chgrp -R brew-usergroup $(brew --prefix)/* sudo chmod -R g+rwX $(brew --prefix)/* ls -lah $(brew --prefix)
Note that this doesn't change rights of brew folders anymore (like in other answers), it changes subfolders/files of brew folders.
brew install
should now work fine without errors.
Jon Gunter
Updated on July 05, 2022Comments
-
Jon Gunter almost 2 years
I have a Mac that is shared between two engineers. Both have separate user accounts. Both need to run
brew update
andbrew install...
occasionally.How do I set this up without getting errors like:
/usr/local must be writable!
?Yeah, I could have
UserA
take over the permissions of/usr/local
every time he wants to use brew (and same withUserB
), but that seems like a lot of unnecessary trouble. -
Wes Modes about 6 yearsThis seems like a huge security risk. Why not rather, add write permission to users in the admin group?
-
maniexx over 5 yearsThis is not actually a solution if you want to use multiple users. You would have to execute that command on each user switch.
-
maniexx over 5 yearsIf you are viewing this in the deep future, or on some weird configuration, and the updated solution doesn't work, check if
$(brew --prefix)
returns/usr/local
, and if not - use that value instead. -
FooBar over 5 yearsI had to add
sudo
otherwise I would getOperation not permitted
error messages -
Antonin Décimo over 5 yearsThe second line should be
echo $(groups $(whoami))
. -
Juan José Ramírez over 5 yearsDo not add
sudo
to avoidOperation not permitted
. add/*
to the command, ie:sudo chgrp -R admin $(brew --prefix)/*
. source -
Leonel Galán over 5 yearsThis solution is sound, however some packages might refuse to work with such permissions. Postgres, for example, throws:
FATAL: data directory "/usr/local/var/postgres" has group or world access DETAIL: Permissions should be u=rwx (0700).
-
n1000 over 5 yearsThis answer could use some cleaning up... What is the code block at the end? Another update?
-
jerryb about 5 yearszsh also complains when owner and perms are tweaked like this; compaudit errors every new shell.
-
Tamas Kalman about 5 yearsthis looks like as an elegant solution, but unfortunately it's not better than simply doing the same for admin (without creating an extra group). either way, i'm getting these error messages: cp: utimes: /usr/local/Cellar/readline/.: Operation not permitted cp: chmod: /usr/local/Cellar/readline/.: Operation not permitted
-
Sliq about 5 yearsI agree, I think the best would be to push the brew developers to fix this entire issue at the core!
-
Suragch about 5 yearsAlternatively, you could give the group the same privileges that the user has:
chmod -R g=u /usr/local/*
(as long as you have already set the group to admin). -
Suragch about 5 yearsThat sounds dangerous. What if 'joe' creates a Homebrew package that does bad things?
-
Sergey Papyan about 5 years@suragch I guess you can't avoid that danger if you're allowing joe to install any system wide packages not only this way, but in any way.
-
DrPsychick over 4 yearsI just now had the same
cp: utimes: /usr/local/Cellar/XXX/.: Operation not permitted
error, found that it was caused by a folder with group "staff" instead of "admin", although I ranchgrp -R admin /usr/local/
... strange, but fixed :)find /usr/local/ -not -group admin -ls
may be of help... -
ipatch over 4 yearsmight want to prepend
/bin/chmod
for those of us who installed GNU coreutils for macOS -
Carlos Pinzón over 4 yearsThis worked for me, but the repo must be cloned with https in my case.
cd $HOME; git clone https://github.com/Homebrew/homebrew-core.git; git clone https://github.com/Homebrew/brew.git
-
jerryb over 4 yearsthanks @CarlosPinzón ! the https URLs instead of the ssh URLs are much easier to use for most. I have updated my answer.
-
HNipps about 4 yearsThis didn't work on Mac OS High Sierra. @user4815162342 's answer worked for me.
-
SebMa over 3 years@jerryb Hi,
~/brew/bin/brew --version
outputsHomebrew 2.5.2-65-gfc6ef72 Homebrew/linuxbrew-core N/A
. Shouldn'thomebrew-core
be installed inside the~/brew/Library/Taps/homebrew/
directory ? -
jerryb over 3 years@SebMa yes i think you are right and there was a change, I'll update my answer. For "brew --version", my working system which I created recently returns
Homebrew 2.5.4\nHomebrew/homebrew-core (git revision 647782; last commit 2020-10-08
-
SebMa over 3 years@jerryb Why did you remove the
Homebrew/homebrew-core
component ? I believe you should this command :git clone https://github.com/homebrew/homebrew-core $HOME/brew/Library/Taps/homebrew/homebrew-core
to you procedure -
jerryb over 3 years@sebma after your feedback which reported issues with the homebrew-core checkout, i could not directly reproduce the problem problem report, but i re-tested my steps with a new home directory on Catalina, excluding the the homebrew-core checkout. Everything seems to work correctly, and brew checked out the homebrew-core itself into the correct location on first operation. I concluded that something changed in the internals so the extra checkout is not required. I am open to the fact that this is incorrect: do you have a reproduce-able set of steps that demonstrates the problem you suspect?
-
SebMa over 3 years@jerryb I use Linux. Have you tested it on Linux ?
-
jerryb over 3 years@SebMa i'm confused, isn't brew specific to Mac?
-
SebMa over 3 years@jerryb It's also compatible with Linux since 2019
-
jerryb over 3 years@SebMa I've updated my answer based on your feedback. I did test this on Ubuntu 16 and homebrew-core now appears to be automatically checked out first time running brew.
-
SebMa over 3 years@jerryb Here, I'm using Ubuntu 18.04 LTS. I needed to run a
./brew/bin/brew update
(before running./brew/bin/brew -v
) for homebrew to tap the homebrew/core. But actually, it does not work every time. I just removed the./brew/
directory and re-done thegit clone ...
and the./brew/bin/brew update
but this time it didn't tap the homebrew/core. I think this step has to be manually after the git clone :./brew/bin/brew tap homebrew/core
. Can you please add thebrew tap ...
command to your procedure ? -
Sliq over 3 yearsThat is the only answer that actually 1. installs brew only for this current user and 2. correctly sets the PATH so it's useable also after reboot! Thanks Vitim!
-
jerryb over 3 years@SebMa done, let me know if I got it right
-
thenetimp over 3 yearsThat is a terrible idea.
-
Clintm over 3 yearsfrom the docs
Pick another prefix at your peril!
-
jerryb about 3 yearsI finally found a use case where my solution does not work well: nvm hates to be outside of /usr/local/bin but its been years with this solution with zero trouble otherwise.
-
Benji about 3 yearsAs noted on the Homebrew installation documentation: "do yourself a favour and install to /usr/local on macOS Intel, /opt/homebrew on macOS ARM, and /home/linuxbrew/.linuxbrew on Linux" and goes on to say "Pick another prefix at your peril!" so I'm not sure this method would be advisable.
-
hdsenevi almost 3 yearsI like this answer as it keeps brew local to the user (not shared). But
brew doctor
returns the following. Is this expected?Warning: Your Homebrew's prefix is not /usr/local. Some of Homebrew's bottles (binary packages) can only be used with the default prefix (/usr/local). You will encounter build failures with some formulae. Please create pull requests instead of asking for help on Homebrew's GitHub, Twitter or any other official channels. You are responsible for resolving any issues you experience while you are running this unsupported configuration.
-
Tatjana Heuser almost 3 yearsWhile group permissions look like a viable option, there are several details where they will break: Without sticky bits, subdirectories created by
brew install
runs may result in sub-sub-directories unwritable for the shared group, or the wrong group altogether. Conflicting installtions within Homebrew (they do exist) may break the others installation, and selective versioning may cause dependency lockups. If no curation is available or desired, I'm afraid to each user his own instance might be the ugly answer. -
ipatch almost 3 yearsas great as this answer is, it does have its limitations. 1. if using a multi user homebrew install isolated within a $HOME dir for particular install, and one wants to use such install with github actions, ie. homebrew's
test-bot
will be unable to perform actions with the standard setup. this can be seen as a limitation of the actions runner provided by homebrew, but using a vanilla github actions with test-bot brew needs to be installed in/usr/local
-
zigg over 2 yearsI don't see evidence that the person who replied to you is an official maintainer. But this strategy is also similar to a tool I used to maintain: github.com/brewdo/brewdo It worked well for most cases, but I stopped maintaining it some years back due to occasional incompatibilities and the fact that Homebrew itself uses OS sandboxing to stop changes outside the Homebrew installation—an early reason why I started this tool. In any event, based on experience, I think this answer is overly simplistic and may work most of the time, but may be problematic down the road.
-
zigg over 2 yearsThis is great! I'm trying it out for a bit. Curious why you may not have included some of the other ACLs, like
writesecurity
(which appears to be required to, say, make a script executable). I ended up doingchmod -R +a 'group:admin allow readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,list,search,add_file,add_subdirectory,delete_child,read,write,append,execute,file_inherit,directory_inherit' *
against all/usr/local
directories after a fresh Homebrew install. -
Exploring over 2 yearsThis would not work in a multi-user environment.
-
Sliq over 2 years@jerryb Really good answer, but it mixes up folders, sometimes it's
brew
and sometimeshomebrew
, so maybe you can update the answer a bit to remove any confusion ;) Thanks Jerry! -
jerryb over 2 years@Sliq thanks so much for the feedback. You are right and I believe I have edited and fixed the issue you mention.
-
jerryb over 2 yearsI like that you include the xcode step for git, and the brew doctor.
-
dijonkitchen about 2 yearsI need the
-i
flag as well. Setting an alias helps for regular use:alias brew='sudo -Hiu $HOMEBREW_MAIN_USER brew'
-
David Scholz almost 2 yearsIf this answer is outdated, then you should actually delete it and not edit it to indicate that it is outdated.
-
blackgreen almost 2 yearsYou can go ahead and delete your answer if you want. It's no longer accepted