Comment réparer les autorisations homebrew?


601

J'ai désinstallé et installé Homebrew 3 fois maintenant car il semble ne jamais me permettre d'installer quoi que ce soit car il me refuse les autorisations à la fin de la plupart des installations.

À titre d'exemple, je publierai ce scénario de téléchargement de libjpeg auquel je suis actuellement confronté.

J'essaie d'installer libjpeg et j'obtiens:

$ brew install libjpeg
==> Downloading https://downloads.sf.net/project/machomebrew/Bottles/jpeg-8d.mountain_lion.bottle.1.tar.gz
Already downloaded: /Library/Caches/Homebrew/jpeg-8d.mountain_lion.bottle.1.tar.gz
==> Pouring jpeg-8d.mountain_lion.bottle.1.tar.gz
Warning: Could not link jpeg. Unlinking...
Error: The brew link step did not complete successfully
The formula built, but is not symlinked into /usr/local
You can try again using `brew link jpeg'
Error: Permission denied - /usr/local/opt/jpeg

«brew link jpeg» se traduit par

Error: Permission denied - /usr/local/opt/jpeg

Voici ce que mon médecin-brasseur lit

$ brew doctor
Warning: "config" scripts exist outside your system or Homebrew directories.
./configure scripts often look for *-config scripts to determine if
software packages are installed, and what additional flags to use when
compiling and linking.

Having additional scripts in your path can confuse software installed via
Homebrew if the config script overrides a system or Homebrew provided
script of the same name. We found the following "config" scripts:

/Library/Frameworks/Python.framework/Versions/2.7/bin/python-config
/Library/Frameworks/Python.framework/Versions/2.7/bin/python2-config
/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7-config
Warning: You have unlinked kegs in your Cellar
Leaving kegs unlinked can lead to build-trouble and cause brews that depend on
those kegs to fail to run properly once built. Run brew link on these:

jpeg

Ce problème d'autorisation a rendu impossible l'utilisation de brew sur quoi que ce soit et j'apprécierais vraiment toutes les suggestions.

Réponses:


955

J'ai pu résoudre le problème en utilisant chownsur le dossier:

sudo chown -R "$USER":admin /usr/local

Vous devrez également (très probablement) faire de même sur /Library/Caches/Homebrew:

sudo chown -R "$USER":admin /Library/Caches/Homebrew

Apparemment, j'avais utilisé sudoauparavant d'une manière qui a modifié mon autorisation de dossier /usr/local, à partir de maintenant, toutes les installations avec infusion se sont avérées réussies.

Cette réponse est une gracieuseté du tracker de problèmes homebrew de gitHub


14
Merci pour cela. J'ai également dû courir sudo chown -R $USER:admin /Library/Caches/Homebrewpour me débarrasser de mes problèmes d'autorisations.
alexpls

64
changer la propriété de / usr / local à un utilisateur spécifique n'est pas une solution. C'est un hack terrible et une solution de contournement si vous avez un système à utilisateur unique. Mais alors vous pourriez aussi bien chown -R / $ USER: $ USER
fijiaaron

17
@fijiaaron Alors, quelle serait une meilleure solution?
juil

47
chowning / usr / local: solution complètement folle. J'espère sincèrement que ce n'est pas vraiment la ligne du parti.
John Clements

15
Pour ceux qui se plaignent que cette solution va gâcher les systèmes multi-utilisateurs (@fijiaaron, @JohnClements, @hmijail, @Alex) - c'est exactement pourquoi les autorisations de groupe ont été inversées. Sur macOS, le admingroupe est composé de tous les utilisateurs admin (c'est-à-dire de tous les utilisateurs de comptes utilisateurs macOS qui peuvent sudo, entre autres), donc en chown -R …:adminsuivant chmod -R g+w /usr/local(comme suggéré par @AndreaDeGaetano), vous ne ferez rien de mal ici et vous n'aurez aucun problème avec d'autres utilisateurs utilisant également /usr/local/ brew.
Slipp D. Thompson,

480

Nouvelle commande pour les utilisateurs sous Mac OS High Sierra comme il est impossible de chownle /usr/local:

bash/zsh:

sudo chown -R $(whoami) $(brew --prefix)/*

fish:

sudo chown -R (whoami) (brew --prefix)/*

Référence: Can't chown / usr / local in High Sierra


Ouais @Jeffpowrs J'ai le même problème dans macOS 10.13.2
andrewwong97

4
J'utilise la coquille de poisson et j'ai dû utiliser ce qui suit: sudo chown -R (whoami) (brew --prefix)/*
Tarellel

2
Relativement. Pour ce que j'essayais de faire, je devais sudo mkdir /usr/local/Frameworks, suivi de la commande chown comme cela apparaît dans cette réponse.
Dan Burton

1
Merci. Cela a sauvé la journée.
Aashutosh Rathi

2
QUE DIEU VOUS BÉNIT, FRÈRE!
Mendigo dos Bytes

285

Comme première option pour quiconque atterrit ici comme je l'ai fait, suivez ce que cela vous suggère de faire:

brew doctor

C'est le chemin le plus sûr, et entre autres, il m'a suggéré de:

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

qui a résolu ce problème d'autorisations.

Le PO a fait exactement cela mais n'a apparemment pas obtenu la suggestion ci-dessus; vous pourriez, et il est toujours préférable de commencer par là, et alors seulement chercher des solutions non triviales si cela n'a pas aidé.


4
Confirmé que cela corrige tout problème que vous pourriez avoir avec des autorisations en date du 05/2017
Anton Babushkin

3
Peut également confirmer que cela résout tous les problèmes d'autorisation et a ensuite pu facilement mettre à niveau ma version de nœud - 06/06/2018 - Merci
Richlewis

2
brew doctor ne trouvera pas tous les problèmes. Le problème que j'avais était / usr / local / Frameworks n'existait pas et créer cela et définir la propriété sur cela l'a corrigé. le brassage lui-même n'a pas remarqué que c'était un problème.
Joe W

2
Je reçois chown: /usr/local: Operation not permittedne fonctionne pas à partir du 5 juillet 2019
tavalendo

1
Le conseil avec le médecin est peut-être l'un des meilleurs conseils ici, car il résout (ou aide à résoudre) différents problèmes à tout moment!
ecth

82

Si vous êtes sur OSX High Sierra, /usr/localne peut plus l'être chown. Vous pouvez utiliser:

sudo chown -R $(whoami) $(brew --prefix)/*


Merci. M'a sauvé!
Matthias

3
J'ai trouvé que $ (brew --prefix) m'a juste donné / usr / local, ce que High Sierra a insisté pour que je ne puisse pas changer les autorisations en ... mais puisque brew voulait des autorisations en "/ usr / local / Frameworks" dans mon cas , J'ai pu utiliser "$ (brew --prefix) / Frameworks" à la place, et "brew link python @ 2" a bien fonctionné pour moi après cela.
alpheus

Tous les utilisateurs Mac avec plusieurs utilisateurs, utilisez ceci!
Erik Nguyen

Merci sur OSX High Sierra, et apparemment nous ne pouvons plus afficher / user / local comme dans les versions précédentes de MAC OSX. Cela a fonctionné pour moi!
Jose Mhlanga

29

Je n'avais pas le /usr/local/Frameworksdossier, donc ça l'a corrigé pour moi

sudo mkdir -p /usr/local/Frameworks
sudo chown -R $(whoami) /usr/local/Frameworks

La première ligne crée un nouveau dossier Frameworks pour l'homebrew (brassage) à utiliser. La deuxième ligne donne à ce dossier vos autorisations d'utilisateur actuelles, qui sont suffisantes.

Les commandes utilisées sont les suivantes:

mkdir - créer des répertoires [ -p aucune erreur si existant, créer des répertoires parents au besoin]

chown - change le propriétaire du fichier et le groupe [ -R opère récursivement sur les fichiers et les répertoires]

whoami - imprimer un ID utilisateur efficace

J'ai OSX High Sierra


27

J'ai eu ce problème .. Une solution de travail consiste à changer la propriété de /usr/local l'utilisateur actuel au lieu de root:

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

Mais ce n'est vraiment pas une bonne façon. Principalement si votre machine est un serveur ou multi-utilisateurs.

Ma suggestion est de changer la propriété comme ci-dessus et de faire tout ce que vous voulez implémenter avec Brew .. (mise à jour, installation ... etc) puis de réinitialiser la propriété à la racine en tant que:

  sudo chown -R root:admin /usr/local

Cela résoudrait le problème et conserverait la propriété dans le bon ensemble.


4
hmm .. et quand nous obtenons "opération non autorisée" pour chown?
Ewoks

@Ewoks est-ce sur MacOs?
Maher Abuthraa

1
Oui, Sierra High: S
Ewoks


15

La commande de la réponse la plus votée ne fonctionne pas pour moi.

Il a obtenu une sortie:

chown: / usr / {my_username} dmin: nom d'utilisateur illégal

Cette commande fonctionne très bien (le groupe pour / usr / local l'était admindéjà):

sudo chown -R $USER /usr/local

5
Ajouter quelques citationssudo chown -R "$USER":admin /usr/local
orkoden

2
@skywinder Votre réponse a fonctionné pour moi. Je n'ai pas eu à utiliser de guillemets sur $ USER.
Anna S

sudo chown -R "$ USER": admin / usr / local où vous remplacez $ USER par votre nom.
lft93ryt

cela a abouti àError: Running Homebrew as root is extremely dangerous and no longer supported. As Homebrew does not drop privileges on installation you would be giving all build scripts full access to your system.
signe d'été

3
chown: /usr/local: Operation not permitted
Krishnadas PC

13

Je ne voulais pas encore me moquer des autorisations de dossier, j'ai donc fait ce qui suit:

brew doctor
brew upgrade
brew cleanup

J'ai ensuite pu continuer à installer mon autre formule d'infusion avec succès.


1
Cela a bien fonctionné pour mes problèmes. Je m'étais déjà SUDOed moi-même des autorisations. \
Komsomol

12

Si vous souhaitez une approche légèrement plus ciblée que la couverture chown -R, vous pouvez trouver cefix-homebrew script utile:

#!/bin/sh

[ -e `which brew` ] || {
    echo Homebrew doesn\'t appear to be installed.
    exit -1
}

BREW_ROOT="`dirname $(dirname $(which brew))`"
BREW_GROUP=admin
BREW_DIRS=".git bin sbin Library Cellar share etc lib opt CONTRIBUTING.md README.md SUPPORTERS.md"

echo "This script will recursively update the group on the following paths"
echo "to the '${BREW_GROUP}' group and make them group writable:"
echo ""

for dir in $BREW_DIRS ; do {
    [ -e "$BREW_ROOT/$dir" ] && echo "    $BREW_ROOT/$dir "
} ; done

echo ""
echo "It will also stash (and clean) any changes that are currently in the homebrew repo, so that you have a fresh blank-slate."
echo ""

read -p 'Press any key to continue or CTRL-C to abort.'

echo "You may be asked below for your login password."
echo ""

# Non-recursively update the root brew path.
echo Updating "$BREW_ROOT" . . .
sudo chgrp "$BREW_GROUP" "$BREW_ROOT"
sudo chmod g+w "$BREW_ROOT"

# Recursively update the other paths.
for dir in $BREW_DIRS ; do {
    [ -e "$BREW_ROOT/$dir" ] && (
        echo Recursively updating "$BREW_ROOT/$dir" . . .
        sudo chmod -R g+w "$BREW_ROOT/$dir"
        sudo chgrp -R "$BREW_GROUP" "$BREW_ROOT/$dir"
    )
} ; done

# Non-distructively move any git crud out of the way
echo Stashing changes in "$BREW_ROOT" . . .
cd $BREW_ROOT
git add .
git stash
git clean -d -f Library

echo Finished.

Au lieu de faire un chmodà votre utilisateur, il donne au admingroupe (auquel vous appartenez vraisemblablement) un accès en écriture aux répertoires spécifiques dans /usr/locallesquels homebrew utilise. Il vous indique également exactement ce qu'il a l'intention de faire avant de le faire.


1
Notez que certains des chemins semblent avoir changé un peu, vous devrez peut-être chgrp et chmod quelques répertoires supplémentaires, mais je préfère toujours cela à tout le chown à votre approche utilisateur!
ashirley

8

Dans mon cas, le / usr / local / Frameworks n'existait même pas, alors j'ai fait:

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

Et puis tout a fonctionné comme prévu.


1
Cela a résolu mon problème et il n'a pas été détecté comme un problème par le médecin de brassage.
Joe W

7

Cela a résolu le problème pour moi.

sudo chown -R "$USER":admin /Users/$USER/Library/Caches/Homebrew
sudo chown -R "$USER":admin /usr/local

2
Cela résout ce problème mais j'annulerais cette étape après avoir réussi la liaison. Juste pour des raisons de sécurité.
ora-600

7

J'ai résolu mon problème avec ces commandes:

sudo mkdir /usr/local/Cellar
sudo mkdir /usr/local/opt
sudo chown -R $(whoami) /usr/local/Cellar
sudo chown -R $(whoami) /usr/local/opt

1
Merci! C'est la seule chose qui Mac OS 10.13.4m'a aidé Dans mon cas, j'ai dû créer sudo mkdir /usr/local/Frameworks et sudo chown -R $(whoami) /usr/local/Frameworkspouvoir lier python!
A1m

6

Pour un Mac multi-utilisateur, cela a fonctionné pour moi:

sudo chown -R $(whoami):admin $(brew --prefix)/*

5

Toutes ces suggestions peuvent fonctionner. Dans la dernière version de brew doctor, de meilleures suggestions ont cependant été faites.

Tout d'abord - corrigez le désordre dont vous avez probablement déjà fait /usr/localpreuve en l'exécutant en ligne de commande:

sudo chown -R root:wheel /usr/local

Prenez ensuite possession des chemins qui devraient être spécifiquement destinés à cet utilisateur:

sudo chown -R $(whoami) /usr/local/lib /usr/local/sbin /usr/local/var /usr/local/Frameworks /usr/local/lib/pkgconfig /usr/local/share/locale

Toutes ces informations sont disponibles si vous exécutez sudo brew updatepuis lisez tous les avertissements et erreurs que vous rencontrerez ...


Définir la propriété de tout dans / usr / local sur root: wheel est dangereux et inutile. Le chemin correspondant est / usr / local / Cellar
ben26941

1
vous n'avez pas besoin de toucher à ces autorisations, sauf si vous avez .. dites déjà allé de l'avant et en avez pris possession pour votre utilisateur de développement - ou dans le cas où brew les a déjà mutilés parce qu'il a fait une installation avec sudo. brew its self recommande ce correctif dans ce cas - ce qui, à mon avis, est beaucoup moins dangereux que de laisser le sudo derrière.
Max Dercum

1
Pourriez-vous alors fournir un lien vers la recommandation de brassage?
ben26941

1
Meilleure réponse. Cela a fonctionné après avoir effectué une migration à partir d'un autre Mac.
BuffMcBigHuge

4

Pour moi, ça a marché après

brew doctor

Les commandes de modification des autorisations ont entraîné une autre erreur

chown: /usr/local: Operation not permitted


3

Il y a un script tueur sur github qui corrige les perms sur les répertoires / usr / local et brew pour être accessible à toute personne membre du groupe «admin».

https://gist.github.com/jaibeee/9a4ea6aa9d428bc77925

C'est une meilleure solution que la réponse choisie, car si vous chown les répertoires / usr / local / ___ à $ USER, alors vous cassez tous les autres utilisateurs admin de homebrew sur cette machine.

Voici les tripes du script au moment où j'ai posté ceci:

chgrp -R admin /usr/local
chmod -R g+w /usr/local

chgrp -R admin /Library/Caches/Homebrew
chmod -R g+w /Library/Caches/Homebrew

chgrp -R admin /opt/homebrew-cask
chmod -R g+w /opt/homebrew-cask

2

Sur MacOS Mojave, je n'avais pas non plus l'autorisation sur chownle dossier / usr / local ( sudo chown -R "$USER":admin /usr/local).

sudo chown -R "$USER":admin /usr/local/*a fonctionné pour moi cependant, modifiant les autorisations de tout dans le dossier local.

J'espère que cela aidera d'autres personnes avec le même problème.


1

En fait, c'est vraiment simple, exécutez cette commande: brew doctor

Et il vous dira quoi faire, pour résoudre les problèmes d'autorisation, par exemple dans mon cas:

C'était le problème:

Warning: The following directories are not writable by your user:
/usr/local/share/man/man5
/usr/local/share/man/man7

Et c'était la solution:

You should change the ownership of these directories to your user.
  sudo chown -R $(whoami) /usr/local/share/man/man5 /usr/local/share/man/man7

1
cd /usr/local && sudo chown -R $(whoami) bin etc include lib sbin share var opt Cellar Frameworks

1

Dans mon cas, j'ai des problèmes pour supprimer et réinstaller SaltStack.

Après l'exécution:

ls -lah /usr/local/Cellar/salt/

J'ai remarqué que le propriétaire du groupe était "personnel". (BTW, j'utilise macOS Mojave version 10.14.3.) Le groupe du personnel pourrait être lié à la configuration de mon lieu de travail, mais je ne sais pas vraiment. Quoi qu'il en soit, j'ai conservé le groupe pour m'empêcher de casser quoi que ce soit.

J'ai ensuite couru:

sudo chown -R "$USER":staff /usr/local/Cellar/salt/

Après cela, j'ai réussi à le supprimer avec cette commande (pas en tant que root):

brew uninstall --force salt

0

Si vous n'avez pas le dernier Homebrew: j'ai "corrigé" cela dans le passé en forçant Homebrew à s'exécuter en tant que root, ce qui ne pouvait être fait qu'en changeant la propriété des exécutables Homebrew en root. À un moment donné, ils ont supprimé cette fonctionnalité.

Et je sais qu'ils donneront beaucoup d'avertissements disant qu'il ne devrait pas fonctionner en tant que root, mais allez, cela ne fonctionne pas correctement sinon.


0

J'ai tout essayé sur cette page, j'ai fini par utiliser cette solution:

brew uninstall --force brew-cask; brew untap $tap_name; brew update; brew cleanup; brew cask cleanup;

Ma situation était similaire à celle de l'OP, mais mon problème était spécifiquement dû à l'exécution de sudo avec brew cask, puis à l'obtention d'un mot de passe incorrect. Après cela, j'étais coincé avec des autorisations empêchant l'installation.


0

Pour résoudre les erreurs relatives aux autorisations Brew lors de l'exécution du dossier

brew prune

Cela résoudra les problèmes et nous n'avons pas à afficher de répertoires.


1
cela ne fonctionne plus, vous devez le faire maintenantbrew cleanup --prune-prefix
Sliq

0

Je suis sur Catalina et j'ai eu cette erreur:

touch: /usr/local/Homebrew/.git/FETCH_HEAD: Permission denied
touch: /usr/local/Homebrew/Library/Taps/homebrew/homebrew-cask/.git/FETCH_HEAD: Permission denied
fatal: Unable to create '/usr/local/Homebrew/.git/index.lock': Permission denied
fatal: Unable to create '/usr/local/Homebrew/.git/index.lock': Permission denied

Je n'avais qu'à chown le Homebrewrépertoire

sudo chown -R "$USER":admin /usr/local/Homebrew

0

J'ai utilisé ces deux commandes et enregistré mon problème

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

sudo chown -R $(whoami) /usr/local/etc/bash_completion.d /usr/local/lib/python3.7/site-packages /usr/local/share/aclocal /usr/local/share/locale /usr/local/share/man/man7 /usr/local/share/man/man8 /usr/local/share/zsh /usr/local/share/zsh/site-functions /usr/local/var/homebrew/locks

-5

essayez également d'exécuter cette commande

sudo chmod + t / tmp

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.