Cómo averiguar qué está causando que la propiedad de /usr/local cambie de my-username a root

Lo uso homebrewcomo administrador de paquetes para ciertas aplicaciones de desarrollo web. Para mantenerme brewactualizado, ejecuto update brewcada dos días y también ejecuto brew doctor. Por lo general, esto está bien y brewme dice que estoy listo para preparar.

De vez en cuando, sin embargo, me sale el siguiente error:

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

Esto puede suceder si "sudo make install" software que no está administrado 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: No se puede escribir en el directorio /usr/local. Incluso si se podía escribir en este directorio cuando instaló Homebrew, otro software puede cambiar los permisos en este directorio. Se sabe que algunas versiones del componente "InstantOn" de Airfoil hacen esto.

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

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

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

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

No hay registro, pero tenga en cuenta que tener /usr/local propiedad de rood es el estándar de Unix y, por lo tanto, cualquier compilación allí lo esperará. La solución es no mezclar un directorio con el administrador de paquetes (Homebrew) y la compilación estándar de Unix: use otro directorio para uno de ellos
Agregar software a la misma ubicación que usa un administrador de paquetes es una mala idea, al igual que cambiar la propiedad y los permisos en /usr/local. Pero si insiste, entonces podría hacerlo make installsin usar sudopaquetes que usted mismo instale.
@Mark También tengo este problema. Me sucede al azar, incluso cuando no he instalado nada desde la última vez que tuve el problema.
@Otros necesitamos más información y otra pregunta sobre ese problema
@Mark ¿No es esa la pregunta? ¿Dónde dice que el problema involucró un software distinto del software instalado/actualizado por homebrew?
La actualización de OS X generalmente restablece la propiedad y los permisos de /usr/local.
@Otros ah, leí la cita de Homebrew en lugar de la pregunta
¿Qué más instaló (manualmente o a través de cualquier otro administrador de paquetes) en su Mac que estaba configurado para instalarse de manera predeterminada /usr/local?

Respuestas (6)

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

Tomó un tiempo, pero finalmente vi que el daemon "Instalación" de Sophos, llamado de manera útil, se metió con los permisos de /usr/local.

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

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

Hay una discusión aquí: community.sophos.com/products/free-antivirus-tools-for-desktops/… Esto debería solucionarse en noviembre de 2015
@JoeZuntz ¡Buen hallazgo! Impresionante que en realidad están impulsando una solución.
@others gracias por esta información. Pude arreglar todo después de actualizar a 10.11.1 y hacer que Homebrew volviera a funcionar, pero la mayoría de las veces, cada vez que iba a hacer una actualización, los permisos volvían a cambiar. Me estaba molestando qué software seguía cambiando los permisos en /usr/local.
@TimX Sí, apesta un poco... Afortunadamente, parece que Sophos lo parcheará a fines de la próxima semana, el 20 de noviembre.

Resulta que Filewave es el culpable. Filewave es un software de administración de sistemas utilizado por nuestra escuela para enviar actualizaciones de software. Gracias por el aporte.

Solo tengo una idea aproximada de cómo obtener el permiso del ladrón. Esta no es una solución a su problema, sino más bien una especie 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 función como Escalar imágenes, simplemente usa un shellscript que ejecuta varios comandos de shell?

  • Si la carpeta se cambia de alguna manera, simplemente tome una instantánea de los permisos y la identificación del proceso de acceso actual con fuser <foldername>.
  • luego busca en la tabla de procesos la identificación del proceso ( ps auxwwwwww | grep <process id>) y finalmente
  • escribir un correo electrónico a ti mismo con estas informaciones recopiladas.

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

Si usa Time Machine, puede encontrar la hora aproximada en que cambiaron los permisos explorando Backups.backupdben la Terminal. Úselo ls -lden 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á la información del propietario y del grupo.

Una vez que tenga la fecha en que ocurrió el cambio, puede averiguar qué más podría haber cambiado en su sistema. Una técnica simple es usar el Archivo de Finder › Buscar y agregar un Last modified datecriterio. Otras buenas herramientas son findy mdfinden Terminal.

Este es un efecto secundario de actualizar su sistema; OS X probablemente realiza alguna "reparación" general de permisos durante el proceso de actualización, ya que /usr/local está anidado en una carpeta propiedad de la raíz.

AFAICT, actualizar a El Capitan es lo que me causó el problema

¿Ha utilizado Disk Utilityseleccionar Macintosh HD, luego ejecutar Verify Disk Permissiony 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 Home-Brew cambia los permisos. Podría mostrar el problema subyacente si tienes suerte.

También new update -vpara una salida más detallada, además de los registros antiguos están aquí ~/Library/Logs/Homebrewsegún ¿Dónde se registra homebrew?

Disk Utilityno verificaría ni repararía los permisos /usr/localya que este directorio no existe en una nueva instalación de Yosemite.
Verifiqué esta hipótesis por completo en Yosemite creando una nueva propiedad /usr/localmía y ejecutando DU. No hay ninguna /usr/localdentro del DUregistro. Y /usr/localtodavía me pertenece.
Cómo averiguar qué está causando que la propiedad de /usr/local cambie de my-username a root
RespuestasAquíPolítica de privacidad1y, 0v