14 votes

Comment trouver la cause du changement de propriété de /usr/local de mon nom d'utilisateur à Root ?

J'utilise homebrew comme gestionnaire de paquets pour certaines applications de développement web. Pour garder brew update brew tous les deux jours et aussi brew doctor . Habituellement, c'est bien et brew me dit que je suis prêt à brasser.

De temps en temps, cependant, je reçois l'erreur suivante :

Attention : /usr/local/etc n'est pas accessible en écriture.

Cela peut se produire si vous "sudo make install" un logiciel qui n'est pas géré par par Homebrew. Si une formule tente d'écrire un fichier dans ce répertoire, l' install échouera lors de l'étape de liaison.

Vous devriez probablement chown /usr/local/etc

Avertissement : Le répertoire /usr/local n'est pas accessible en écriture. Même si ce répertoire était accessible en écriture lorsque vous avez installé Homebrew, d'autres d'autres logiciels peuvent modifier les permissions sur ce répertoire. Certaines versions du composant composant "InstantOn" d'Airfoil sont connues pour faire cela.

Vous devriez probablement changer la propriété et les permissions de /usr/local à votre compte d'utilisateur.

C'est assez facile de réinitialiser les permissions à mon nom d'utilisateur. Ensuite, brew semble bien fonctionner.

Mais quelle est la cause de ce phénomène ?

Y a-t-il un journal qui montre ce qui cause le changement des permissions ?

3 votes

Pas de journal mais notez que le fait que le répertoire /usr/local appartienne à rood est le standard Unix et que toute compilation dans ce répertoire s'y attendra. La solution est de ne pas mélanger un répertoire avec à la fois le gestionnaire de paquets (Homebrew) et la compilation standard Unix - Utilisez un autre répertoire pour l'un d'entre eux.

3 votes

L'ajout d'un logiciel au même emplacement que celui utilisé par un gestionnaire de paquets est une mauvaise idée, tout comme le fait de changer la propriété et les autorisations sur /usr/local . Mais si vous insistez, vous pourriez make install sans utiliser sudo pour les paquets que vous installez vous-même.

0 votes

@Mark J'ai également ce problème. Cela m'arrive de manière aléatoire, même si je n'ai rien installé depuis la dernière fois que j'ai eu ce problème.

13voto

Others Points 181

J'ai eu exactement le même problème, et il s'avère que la mise à jour automatique de Sophos était en cause. J'ai trouvé ça en exécutant : sudo fs_usage | grep "usr/local"

Cela a pris un certain temps, mais j'ai fini par voir le daemon "Installation" de Sophos, dont le nom est très utile, s'immiscer dans les permissions de /usr/local.

J'essaie toujours de trouver une solution appropriée à ce comportement.

EDIT : Je crois que Sophos a corrigé ce problème, voir le lien dans les commentaires de cette réponse. Il semble être corrigé pour moi au moins !

4 votes

Il y a une discussion ici : community.sophos.com/products/free-antivirus-tools-for-desktops/ Ce problème devrait être résolu en novembre 2015

0 votes

@JoeZuntz Belle trouvaille ! C'est génial qu'ils proposent un correctif.

0 votes

Merci aux autres pour cette information. J'ai pu tout réparer après la mise à jour vers 10.11.1 et j'ai réussi à faire fonctionner homebrew à nouveau, mais le plus souvent, à chaque fois que je faisais une mise à jour de brew, les permissions avaient à nouveau changé. Je me demandais quel logiciel changeait constamment les permissions sur /usr/local.

4voto

chrisan Points 111

Il s'avère que Filewave est le coupable. Filewave est un logiciel de gestion de système utilisé par notre école pour mettre à jour les logiciels. Merci pour votre contribution.

2voto

Martin Allert Points 898

J'ai juste une idée approximative de comment obtenir le voleur de permission. Ce n'est pas une solution à votre problème, mais plutôt une sorte de solution de contournement.

Que diriez-vous d'écrire un chien de garde dans Automator ou avec Hazel (actions sur les dossiers) pour surveiller ce dossier particulier, mais au lieu d'ajouter une fonction comme Scale images, vous utilisez simplement un script shell qui exécute plusieurs commandes shell :

  • Si le dossier est modifié de quelque manière que ce soit, il suffit de faire un instantané des permissions et de l'identifiant du processus en cours d'accès avec fuser <foldername> .
  • puis vous recherchez dans la table des processus l'identifiant du processus ( ps auxwwwwww | grep <process id> ) et enfin
  • écrivez un e-mail à vous-même avec les informations recueillies.

Malheureusement, je ne suis pas un sadhu d'Automator, mais j'ai découvert par Google qu'il existe de nombreuses solutions pour un problème similaire.

0voto

duozmo Points 2039

Si vous utilisez Time Machine, vous pouvez trouver l'heure approximative à laquelle les permissions ont changé en explorant Backups.backupdb dans Terminal. Utilisez ls -ld dans les dossiers horodatés, par ex.

ls -ld /Volumes/Backup/Backups.backupdb/Mac/2015-12-25-120000/Macintosh\ HD/usr/local 

qui affichera les informations sur le propriétaire et le groupe.

Une fois que vous connaissez la date à laquelle la modification a eu lieu, vous pouvez rechercher ce qui a pu changer sur votre système. Une technique simple consiste à utiliser la fonction Fichier ' Rechercher du Finder et à ajouter un fichier de type Last modified date critère. D'autres bons outils sont find y mdfind dans le terminal.

-1voto

Stan Hutcheon Points 984

Il s'agit d'un effet secondaire de la mise à jour de votre système ; OS X procède probablement à une "réparation" générale des autorisations pendant le processus de mise à jour, car le dossier /usr/local est imbriqué dans un dossier appartenant à Root.

0 votes

En fait, c'est la mise à jour vers El Capitan qui a causé le problème pour moi.

LesApples.com

LesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.

Powered by:

X