Como descobrir o que está fazendo com que a propriedade de / usr / local mude de my-username para root

13

Eu uso homebrewcomo gerenciador de pacotes em determinados aplicativos de desenvolvimento da web. Para me manter brewatualizado, corro a update brewcada dois dias e também corro brew doctor. Normalmente, isso é bom e brewme diz que estou pronto para preparar.

De vez em quando, no entanto, recebo o seguinte erro:

Aviso: / usr / local / etc não é gravável.

Isso pode acontecer se você "sudo make install" software que não é gerenciado pelo Homebrew. Se uma fórmula tentar gravar um arquivo nesse diretório, a instalação falhará durante a etapa do link.

Você provavelmente deveria chown/ usr / local / etc

Aviso: O diretório / usr / local não é gravável. Mesmo que este diretório tenha sido gravável quando você instalou o Homebrew, outro software pode alterar as permissões nesse diretório. Algumas versões do componente "InstantOn" do Airfoil são conhecidas por fazer isso.

Você provavelmente deve alterar a propriedade e as permissões de / usr / local de volta para sua conta de usuário.

É fácil o suficiente redefinir as permissões novamente para o meu nome de usuário. Depois brewparece estar bem.

Mas o que está causando isso?

Existe um log que mostra o que está causando alterações nas permissões?

— Daniel Muller
fonte

3

Nenhum registro, mas observe que ter / usr / local de propriedade do rood é o padrão Unix e, portanto, qualquer construção nele o espera. Solução é não misturar um diretório com tanto gerenciador de pacotes (Homebrew) e compilação Unix padrão - Use outro diretório para um deles

— user151019

3

Adicionar um software ao mesmo local que o gerenciador de pacotes usa é uma má idéia, assim como alterar a propriedade e as permissões /usr/local. Mas se você insistir, poderá fazê-lo make installsem usar os sudopacotes que você instala.

— Fd0

1

A atualização do OS X geralmente redefine / usr / propriedade e permissões locais.

— mspasov

1

@Others ah eu li a citação de Homebrew, em vez da questão

— user151019

1

O que mais você instalou (manualmente ou através de qualquer outro gerenciador de pacotes) no seu Mac que foi configurado para instalação padrão /usr/local?

— dan

13

Eu tive exatamente o mesmo problema, e a atualização automática da Sophos foi a culpada. Eu descobri isso executando:sudo fs_usage | grep "usr/local"

Demorou um pouco, mas, eventualmente, vi o daemon "Installation", útil da Sophos, mexendo nas permissões de / usr / local.

Ainda estou tentando descobrir uma solução apropriada para esse comportamento.

EDIT: Acredito que a Sophos tenha corrigido esse problema, consulte o link nos comentários desta resposta. Parece estar consertado para mim, pelo menos!

— Outras
fonte

4

Há uma discussão aqui: community.sophos.com/products/free-antivirus-tools-for-desktops/… Isso deve ser corrigido em novembro de 2015

— JoeZuntz 23/15

@JoeZuntz Nice find! Impressionante que eles realmente estão dando um jeito.

— Outros

@other obrigado por esta informação. Consegui consertar tudo após a atualização para a versão 10.11.1 e o homebrew voltou a funcionar, mas mais frequentemente do que nunca, cada vez que fazia uma atualização de preparação, as permissões haviam mudado novamente. Estava me incomodando qual software continuava alterando as permissões em / usr / local.

— Tim X

@ TimX Sim, é meio ruim ... Felizmente, parece que a Sophos está corrigindo isso no final da próxima semana, 20 de novembro.

— Outros

4

Acontece que o Filewave é o culpado. O Filewave é um software de gerenciamento de sistema usado por nossa escola para enviar atualizações de software. Obrigado pela contribuição.

— Daniel Muller
fonte

2

Eu tenho apenas uma idéia aproximada de como obter o ladrão de permissão. Esta não é uma solução para o seu problema, mas mais algum tipo de solução alternativa.

Que tal escrever um watchdog no Automator ou com Hazel (ações da pasta) para assistir a essa pasta específica, mas em vez de adicionar uma função como Escala de imagens, você apenas usa um shellscript que executa vários comandos do shell:

Se a pasta for alterada de alguma forma, basta capturar instantaneamente as permissões e a identificação do processo que está acessando no momento fuser <foldername>.
então você consulta na tabela de processos a identificação do processo ( ps auxwwwwww | grep <process id>) e finalmente
escreva um e-mail para si mesmo com essas informações coletadas.

Infelizmente, não sou sadhu do Automator, mas descobri pelo Google que existem muitas soluções para um problema semelhante.

— Garex
fonte

0

Se você usar o Time Machine, poderá encontrar o tempo aproximado em que as permissões foram alteradas, explorando Backups.backupdbno Terminal. Use ls -ldnas pastas com registro de data e hora, por exemplo

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

O qual mostrará as informações do proprietário e do grupo.

Depois de ter a data em que a alteração ocorreu, você poderá descobrir o que mais poderia ter mudado no seu sistema. Uma técnica simples é usar o Arquivo do Finder ›Localizar e adicionar um Last modified datecritério. Outras boas ferramentas estão finde mdfindno Terminal.

— duozmo
fonte

-1

Este é um efeito colateral da atualização do seu sistema; O OS X provavelmente faz algum reparo geral de permissão durante o processo de atualização, já que / usr / local está aninhado em uma pasta de propriedade da raiz.

— Stan Hutcheon
fonte

AFAICT, a atualização para o El Capitan é o que causou o problema para mim

— Giuseppe

-3

Você usou Disk Utilityselect Macintosh HD, run Verify Disk Permissione, Repair Disk Permissionse necessário, em vez de fazê-lo manualmente?

Agora, isso não deve ser corrigido no seu problema, mas é um bom ponto de partida "conhecido" para ver quando a mistura caseira altera as permissões. Pode aparecer o problema subjacente, se você tiver sorte.

Também new update -vhá mais detalhado de saída, além de logs antigos aqui ~/Library/Logs/Homebrewcomo por Onde é que log homebrew?

— MichaelStoner
fonte

2

Disk Utilitynão verificaria nem repararia permissões, /usr/localpois esse diretório não existe em uma nova instalação do Yosemite.

— dan

Eu verifiquei essa hipótese completamente em Yosemite criando um novo /usr/localpertencente a mim e executando DU. Não há nenhum /usr/localno DUlog. E /usr/localainda me pertence.

— dan