Come capire cosa sta causando il passaggio della proprietà di / usr / local da my-username a root


13

Uso homebrewun gestore di pacchetti per determinate app di sviluppo web. Per tenermi brewaggiornato corro update brewogni paio di giorni e corro anche brew doctor. Di solito, va bene e brewmi dice che sono pronto a preparare.

Di tanto in tanto, tuttavia, ottengo il seguente errore:

Avvertenza: / usr / local / etc non è scrivibile.

Questo può accadere se "sudo make install" non è gestito da Homebrew. Se una formula tenta di scrivere un file in questa directory, l'installazione non riuscirà durante il passaggio del collegamento.

Probabilmente dovresti chown/ usr / local / etc

Avvertenza: la directory / usr / local non è scrivibile. Anche se questa directory era scrivibile quando hai installato Homebrew, altri software potrebbero cambiare le autorizzazioni su questa directory. Alcune versioni del componente "InstantOn" di Airfoil sono note per farlo.

Probabilmente dovresti cambiare la proprietà e le autorizzazioni di / usr / local al tuo account utente.

È abbastanza facile ripristinare le autorizzazioni sul mio nome utente. Successivamente brewsembra andare bene.

Ma cosa sta causando ciò?

Esiste un registro che mostra cosa sta causando la modifica delle autorizzazioni?


3
Nessun registro ma nota che avere / usr / local di proprietà di Rood è lo standard Unix e quindi se ne aspettano tutti i build-in. La soluzione è non mescolare una directory con sia il gestore dei pacchetti (Homebrew) che la compilazione Unix standard - Usa un'altra directory per una di esse
user151019

3
L'aggiunta di software nella stessa posizione utilizzata da un gestore di pacchetti è una cattiva idea, così come la modifica della proprietà e delle autorizzazioni /usr/local. Ma se insisti, puoi farlo make installsenza usare i sudopacchetti che installi tu stesso.
fd0

1
L'aggiornamento di OS X di solito ripristina / usr / proprietà e autorizzazioni locali.
mspasov,

1
@Altro ah ho letto la citazione da Homebrew piuttosto che la domanda
user151019

1
Cos'altro hai installato (manualmente o tramite qualsiasi altro gestore di pacchetti) sul tuo Mac configurato per l'installazione predefinita /usr/local?
dan,

Risposte:


13

Ho avuto lo stesso identico problema e risulta che la colpa era dell'aggiornamento automatico di Sophos. Ho capito questo eseguendo:sudo fs_usage | grep "usr/local"

Ci è voluto un po 'di tempo, ma alla fine ho visto il demone "Installazione" utile di Sophos fare scherzi con le autorizzazioni di / usr / local.

Sto ancora cercando di capire un lavoro adeguato per questo comportamento.

EDIT: credo che Sophos abbia risolto questo problema, vedere il link nei commenti di questa risposta. Sembra che sia stato risolto per me almeno!


4
C'è una discussione qui: community.sophos.com/products/free-antivirus-tools-for-desktops/… Questo dovrebbe essere risolto a novembre 2015
JoeZuntz,

@JoeZuntz Nice find! Fantastico che in realtà stiano spingendo una correzione.
Altri

@others grazie per queste informazioni. Sono stato in grado di risolvere tutto dopo l'aggiornamento a 10.11.1 e ho fatto di nuovo funzionare homebrew, ma il più delle volte, ogni volta che sono andato a fare un aggiornamento brew, le autorizzazioni erano cambiate di nuovo. Mi stava infastidendo quale software continuava a cambiare i permessi su / usr / local.
Tim X

@TimX Sì, fa un po 'schifo ... Fortunatamente sembra che Sophos lo stia riparando alla fine della prossima settimana, il 20 novembre.
Altri

4

Risulta che Filewave è il colpevole. Filewave è un software di gestione del sistema utilizzato dalla nostra scuola per inviare aggiornamenti software. Grazie per l'input.


2

Ho solo una vaga idea di come ottenere il ladro di autorizzazioni. Questa non è una soluzione al tuo problema, ma piuttosto una sorta di soluzione alternativa.

Che ne dici di scrivere un cane da guardia in Automator o con Hazel (azioni della cartella) per guardare questa particolare cartella ma invece di aggiungere una funzione come Ridimensiona immagini basta usare uno shellscript che esegue diversi comandi di shell:

  • Se la cartella viene modificata in qualche modo, è sufficiente eseguire l'istantanea delle autorizzazioni e dell'ID del processo attualmente in accesso con fuser <foldername>.
  • quindi si cerca nella tabella dei processi l'id di processo ( ps auxwwwwww | grep <process id>) e infine
  • scrivi una email a te stesso con queste informazioni raccolte.

Sfortunatamente non sono un Sadhu di Automator, ma ho scoperto da Google che ci sono molte soluzioni per un simile problema.


0

Se usi Time Machine, puoi trovare il tempo approssimativo in cui le autorizzazioni sono state modificate esplorando Backups.backupdbin Terminal. Utilizzare ls -ldnelle cartelle con timestamp, ad es

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

Che mostrerà le informazioni sul proprietario e sul gruppo.

Una volta che hai la data in cui è avvenuta la modifica, puoi scoprire cos'altro potrebbe essere cambiato sul tuo sistema. Una tecnica semplice è quella di utilizzare il File del Finder ›Trova e aggiungi un Last modified datecriterio. Altri buoni strumenti sono finde mdfindnel Terminal.


-1

Questo è un effetto collaterale dell'aggiornamento del sistema; OS X probabilmente esegue alcune "riparazioni" generalizzate durante il processo di aggiornamento poiché / usr / local è nidificato in una cartella di proprietà di root.


AFAICT, l'aggiornamento a El Capitan è ciò che mi ha causato il problema
Giuseppe,

-3

Hai usato Disk Utilityseleziona, Macintosh HDquindi esegui Verify Disk Permissione, Repair Disk Permissionse necessario, anziché farlo manualmente?

Ora questo non dovrebbe risolvere il tuo problema, ma è un buon punto di partenza "noto" per vedere quando la birra fatta in casa cambia le autorizzazioni. Se sei fortunato, potrebbe mostrare il problema di fondo.

Anche new update -vper un output più dettagliato, oltre ai vecchi registri sono qui ~/Library/Logs/Homebrewcome da Dove si registra homebrew?


2
Disk Utilitynon verificherebbe o riparerebbe le autorizzazioni /usr/localpoiché questa directory non esiste su una nuova installazione di Yosemite.
dan,

Ho verificato completamente questa ipotesi su Yosemite creando una nuova /usr/localappartenenza a me e correndo DU. Non ce ne sono /usr/localnel DUregistro. E /usr/localappartiene ancora a me.
dan,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.