Cómo averiguar qué está causando que la propiedad de / usr / local cambie de mi nombre de usuario a raíz
Utilizo homebrew como administrador de packages para cierta aplicación de desarrollo web. Para mantener el brew al día, update brew cada par de días y también corro el brew doctor . Por lo general, esto está bien y la brew me dice que estoy listo para preparar.
De vez en cuando, sin embargo, aparece el siguiente error:
Advertencia: / usr / local / etc no se puede escribir.
Esto puede suceder si el software "sudo make install" no es administrado por Homebrew. Si una fórmula intenta escribir un file en este directory, la installation fallará durante el paso del enlace.
Probablemente debería
chown/ usr / local / etc.Advertencia: el directory / usr / local no se puede escribir. Incluso si este directory era de escritura cuando instaló Homebrew, otro software puede cambiar los permissions en este directory. Algunas versiones del componente "InstantOn" de Airfoil son conocidas por hacer esto.
Probablemente debería cambiar la propiedad y los permissions de / usr / local a su count de usuario.
Es bastante fácil restaurar los permissions a mi nombre de usuario. Después, la brew parece estar bien.
Pero, ¿qué está causando que esto suceda?
¿Hay un logging que muestra qué está causando que cambien los permissions?
6 Solutions collect form web for “Cómo averiguar qué está causando que la propiedad de / usr / local cambie de mi nombre de usuario a raíz”
Tuve exactamente este mismo problema, y resultó que la actualización automática de Sophos era la culpable. Me di count de esto ejecutando: sudo fs_usage | grep "usr/local" sudo fs_usage | grep "usr/local"
Me tomó un time, pero al final vi el daemon de "installation" de Sophos, amablemente llamado, jugando con los permissions de / usr / local.
Todavía estoy tratando de encontrar una solución adecuada para este comportamiento.
EDITAR: Creo que Sophos ha solucionado este problema, consulte el enlace en los comentarios de esta respuesta. ¡Parece que está arreglado para mí al less!
Resulta que Filewave es el culpable. Filewave es un software de administración de sistemas utilizado por nuestra escuela para impulsar actualizaciones de software. Gracias por el aporte.
Tengo una idea aproximada de cómo get el ladrón de permissions. Esta no es una solución a su problema, sino más bien un tipo de solución alternativa.
¿Qué hay de escribir un perro guardián en Automator o con Hazel (acciones de carpeta) para ver esta carpeta en particular, pero en lugar de agregar una function como Escalar imágenes, simplemente utiliza un shellscript que ejecuta varios commands de shell:
- Si la carpeta se cambia de alguna manera, simplemente tome una instantánea de los permissions y la identificación del process que está accediendo actualmente con
fuser <foldername>. - luego busca en la tabla de processs la identificación del process (
ps auxwwwwww | grep <process id>) y finalmente - escriba un correo electrónico a usted mismo con estas informaciones recostackdas.
Lamentablemente, no soy Automator sadhu, pero descubrí que hay muchas soluciones para un problema similar.
Este es un efecto secundario de actualizar su sistema; Es probable que OS X realice una "reparación" de permissions general durante el process de actualización ya que / usr / local está nested en una carpeta propiedad de la raíz.
Si usa Time Machine, puede encontrar la hora aproximada en que cambiaron los permissions explorando Backups.backupdb en Terminal. Use ls -ld en las carpetas con marcas de time, por ej.
ls -ld /Volumes/Backup/Backups.backupdb/Mac/2015-12-25-120000/Macintosh\ HD/usr/local
Que mostrará la información del propietario y del grupo.
Una vez que tenga la date en que ocurrió el cambio, puede descubrir qué más podría haber cambiado entonces en su sistema. Una técnica simple es usar el Finder's File> Find y agregar un Last modified date criterio de Last modified date . Otras buenas herramientas son find y mdfind en Terminal.
¿Ha utilizado la Disk Utility select Macintosh HD luego ejecute Verify Disk Permission y luego Repair Disk Permission si es necesario, en lugar de hacerlo manualmente?
Ahora bien, esto no debería solucionar su problema, pero es un buen punto de partida "conocido" para ver cuándo el brebaje casero cambia los permissions. Podría mostrar el problema subyacente si tienes suerte.
También se encuentra aquí la new update -v para get una salida más detallada, más los loggings antiguos ~/Library/Logs/Homebrew según ¿Dónde se crea el logging homebrew?