Cómo averiguar qué está causando que la propiedad de / usr / local cambie de mi nombre de usuario a raíz

13

Utilizo homebrew como administrador de paquetes para ciertas aplicaciones de desarrollo web. Para mantener brew actualizado, ejecuto update brew cada dos días y también ejecuto brew doctor . Por lo general, esto está bien y brew me dice que estoy listo para preparar.

De vez en cuando, sin embargo, recibo el siguiente error:

  

Advertencia: / usr / local / etc no se puede escribir.

     

Esto puede suceder si "sudo make install" es un software que no es administrado por   por Homebrew. Si una fórmula intenta escribir un archivo en este directorio,   la instalación fallará durante el paso del enlace.

     

Probablemente deberías chown / usr / local / etc

     

Advertencia: el directorio / usr / local no se puede escribir.   Incluso si este directorio era grabable cuando instaló Homebrew, otros   El software puede cambiar los permisos en este directorio. Algunas versiones de la   Se sabe que el componente "InstantOn" de Airfoil hace esto.

     

Probablemente debería cambiar la propiedad y los permisos de / usr / local   volver a su cuenta de usuario.

Es bastante fácil restablecer los permisos a mi nombre de usuario. Después, brew parece estar bien.

Pero, ¿qué está causando que esto suceda?

¿Hay un registro que muestre qué está causando que cambien los permisos?

    
pregunta Daniel Muller 29.03.2015 - 14:29

6 respuestas

4

Resulta que Filewave es el culpable. Filewave es un software de administración de sistemas utilizado por nuestra escuela para impulsar las actualizaciones de software. Gracias por la entrada.

    
respondido por el Daniel Muller 29.09.2015 - 02:44
12

Tuve exactamente el mismo problema, y resulta que la actualización automática de Sophos fue la culpable. Descubrí esto ejecutando: sudo fs_usage | grep "usr/local"

Tomó un tiempo, pero al final vi el útil daemon de "Instalación" de Sophos jugando con los permisos de / usr / local.

Todavía estoy tratando de encontrar una solución adecuada para este comportamiento.

EDITAR: Creo que Sophos ha solucionado este problema, vea el enlace en los comentarios de esta respuesta. ¡Parece estar arreglado para mí al menos!

    
respondido por el Others 06.10.2015 - 17:10
2

Tengo una idea aproximada de cómo obtener el ladrón permiso. Esto no es una solución a su problema, sino más bien algún tipo de solución.

¿Qué hay de escribir un watchdog en Automator o con Hazel (acciones de carpeta) para ver esta carpeta en particular, pero en lugar de agregar una función como imágenes de escala, solo usas un shellscript que ejecuta varios comandos de shell:

  • Si la carpeta se modifica de alguna manera, simplemente haga una instantánea de los permisos y la identificación del proceso que está accediendo actualmente con fuser <foldername> .
  • luego busca en la tabla de proceso el id de proceso ( ps auxwwwwww | grep <process id> ) y finalmente
  • escriba un correo electrónico a usted mismo con estas informaciones recopiladas.

Desafortunadamente, no soy un sadhu de Automator, pero descubrí que con Google existen muchas soluciones para un problema similar.

    
respondido por el Garex 28.09.2015 - 12:50
0

Si usa Time Machine, puede encontrar el tiempo aproximado en que se cambiaron los permisos al explorar Backups.backupdb en la Terminal. Use ls -ld en las carpetas con marca de tiempo, por ejemplo,

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

Que mostrará información de propietario y grupo.

Una vez que tenga la fecha en que ocurrió el cambio, puede descubrir qué otra cosa podría haber cambiado en su sistema. Una técnica simple es usar el archivo del buscador ›Buscar y agregar un criterio Last modified date . Otras buenas herramientas son find y mdfind en la Terminal.

    
respondido por el duozmo 13.01.2016 - 15:51
-1

Este es un efecto secundario de actualizar su sistema; Es probable que OS X realice alguna "reparación" de permisos en todo el tablero durante el proceso de actualización, ya que / usr / local está anidado en una carpeta de raíz.

    
respondido por el Stan Hutcheon 28.09.2015 - 16:49
-3

¿Has usado Disk Utility select Macintosh HD y luego ejecutas Verify Disk Permission y luego Repair Disk Permission si es necesario, en lugar de hacerlo manualmente?

Ahora esto no debería solucionar su problema, pero es un buen punto de partida 'conocido' para ver cuándo los cambios en los permisos se hacen en casa. Podría aparecer el problema subyacente si tienes suerte.

También new update -v para resultados más detallados, además de registros antiguos aquí ~/Library/Logs/Homebrew según ¿Dónde se registra el homebrew?

    
respondido por el MichaelStoner 28.09.2015 - 11:13

Lea otras preguntas en las etiquetas