He deshabilitado SIP, tengo permisos de lectura/escritura con terminal, pero no con Finder. ¿Qué causa esto?

Sistema: macOS Catalina 10.15.2

Antecedentes: he sido usuario de *nix durante muchos años. Utilizo un servidor Linux remoto donde se usa el directorio raíz (es decir, hay carpetas donde los usuarios pueden leer y escribir, como /data y /analyses), y he usado macOS de la misma manera hasta ahora. Recibí una nueva MacBook de mi lugar de trabajo este año. Administro la máquina, por lo que puedo cambiar cualquier cosa que pueda hacer el root.

Con el interés de continuar usando el sistema de organización de archivos en nuestro servidor remoto, he deshabilitado SIP y estoy montando / con lectura/escritura en cada arranque (de manera similar a como se hace aquí ) . Puedo trabajar en las carpetas /datay /analysesusando la Terminal sin problemas, pero cuando se trata de usar Finder, este no es el caso. No es posible crear y eliminar carpetas y archivos con Finder. Este no es el caso con otras aplicaciones GUI (por ejemplo, puedo usar un editor de texto como Sublime para editar archivos de texto sin formato en estas carpetas, o crear y guardar nuevos en el directorio de mi elección).

Problema: cuando uso Finder para mover o modificar estos archivos (por ejemplo, arrastrar un archivo a la Papelera), aparece un mensaje de advertencia: "file" can't be modified or deleted because it's required by macOS. Puedo eliminar o modificar estos archivos con otras aplicaciones, incluida Terminal, pero por comodidad me gustaría que me ayudaran a encontrar una solución a este problema con Finder (por ejemplo, ¿hay algo que pueda cambiar con los permisos de Finder? o con los permisos establecidos por macOS para los directorios en los que estoy trabajando).

Lo que ya probé: cambiar los permisos/propiedad de archivos y carpetas con chmody chown, sin efecto en el comportamiento de Finder

p.d. A menos que esté seguro de que ayudará directamente a resolver este problema con Finder, gracias de antemano por dejar de lado las conferencias sobre por qué debería volver a habilitar SIP, ya las he escuchado todas. :)

La respuesta corta es... Es por diseño (o debería decir, falta de diseño) ¡y no puedes cambiarlo! Comuníquese con Apple en: Comentarios sobre el producto
@ user3439894 Estaría feliz de aceptar esto como una respuesta si lo escribe como tal, con un poco más de detalle explicando por qué este comportamiento no se puede cambiar.
Tendría que regresar y rehacer la investigación que hice cuando macOS Catalina estuvo disponible para poder ubicar fuentes más autorizadas; sin embargo, la respuesta corta sobre por qué el usuario no puede cambiarlo es porque es un codificador duro en el código fuente de Finder . Al igual que al cambiar la configuración para permitir que se muestren las carpetas ocultas, Apple no permite que se muestren en el Finder ni te permite usar ⇧⌘G ( Ir a la carpeta… ) para llevarte allí, y hubo un tiempo en que solían hacerlo, pero ahora está codificado en el código fuente , por lo que no se puede. /dev
@ user3439894 gracias, eso es básicamente todo lo que necesitaba saber. si es posible o no y más o menos por qué. apreciar su experiencia!
Por cierto, hay una aplicación paga llamada Path Finder , que tiene una versión de prueba gratuita y es un administrador de archivos para macOS . Podría intentarlo y ver si puede hacer las cosas que desea que Finder no haga. (No estoy afiliado con el desarrollador de este producto).

Respuestas (2)

Si necesita crear directorios fuera de la raíz, la mejor opción es usar firmlinks, que se puede configurar usando /etc/synthetic.conf. Desde la página del manual:

...
synthetic.conf is intended to be used for creating mount points at / 
(e.g. for use as NFS mount points in enterprise deployments) and symbolic
links (e.g. for creating a package manager root without modifying the
system volume).  synthetic.conf is read by apfs.util(8) during early sys-
tem boot.
...

Si crea /datay /analysesen otro lugar y luego tiene los enlaces administrados por synthetic.conf, debería poder evitar deshabilitar SIP y poder acceder a esos directorios desde Finder.

gracias, aprecio que esto aborde mi pregunta de manera diferente a los comentarios anteriores, y más directamente que la otra respuesta formal. Voy a marcar esto como la respuesta aceptada.

Utilizo un servidor Linux remoto donde se usa el directorio raíz (es decir, hay carpetas donde los usuarios pueden leer/reproducir, como /data y /analyses)... Con el interés de continuar usando el sistema de organización de archivos en nuestro servidor remoto, He deshabilitado SIP y estoy montando/con lectura/escritura en cada arranque

Esta no es una buena estrategia y debe evitarse.

Lo primero y más importante a tener en cuenta es que macOS ≠ Linux . Lo que Linux le permite "salir con la suya" no siempre es una buena práctica para la administración del sistema. Cuando reducimos todo, lo que básicamente está preguntando es sobre la ubicación de dos carpetas y el directorio raíz en realidad no es el mejor lugar para ellas, por lo tanto, los problemas con los que se encuentra.

Al deshabilitar SIP, elimina una de las protecciones clave que hacen de macOS uno de los sistemas operativos más seguros del mercado actual. Hacerlo para eludir la arquitectura de seguridad y poder crear carpetas/volúmenes de montaje que residen en el directorio raíz es contraproducente. En lugar de luchar contra el sistema operativo, es mejor trabajar con él.

A menos que esté seguro de que ayudará directamente a resolver este problema con Finder...

No es un problema con Finder. SIP existe desde hace mucho tiempo; desde que se estrenó El Capitán (10.11) en 2015. Esto no es nada nuevo. Sin embargo, la nueva estructura de contenedor APFS de tener dos volúmenes, uno grabable y otro no (agregado - Dataal nombre del volumen) es nueva. Si bien algunos de los cambios de seguridad que Apple ha implementado causan más dolores de cabeza de los necesarios, este no es uno de ellos.

En realidad, esto es algo que los administradores del sistema deberían estar haciendo: fortalecer el sistema y limitar qué y dónde puede escribir el usuario al "contenerizar" (sandboxing) los directorios/volúmenes con los permisos adecuados de lectura/escritura/ejecución.

Monte directorios accesibles para el usuario en la ubicación adecuada

Nuevamente, el directorio raíz no es realmente un lugar apropiado para datos compartidos , ya sea macOS o Linux. Ya sea que estos directorios sean locales para la Mac (la Mac es el recurso compartido de red), o si los está montando desde un servidor de archivos remoto, deben colocarse en un volumen protegido como en /Users/Sharedo montarse en /Volumes. El razonamiento detrás de esto es que puede establecer los derechos "principales" y aplicarlos a todas las carpetas secundarias, mientras que si tuviera que modificar los derechos de algo en el directorio raíz, podría aplicar los permisos incorrectos en todo el sistema.

Incluso mi Synology NAS (basado en Linux) no me permite crear recursos compartidos en la carpeta raíz. Me obliga a montarlos en un subvolumen con permisos que yo (con acceso de root) no puedo modificar.

TL;RD

Vas contra la corriente aquí; trabajar con el sistema operativo y no contra él. Si descubre que necesita deshabilitar todas las protecciones con las que vino el sistema, es probable que no esté siguiendo una de las mejores prácticas de la industria. No intente forzar a macOS y Finder a comportarse de cierta manera porque puede "hacerlo en Linux"; siga su ejemplo y tendrá un sistema seguro, disponible y, lo que es más importante, confiable en el que sus usuarios pueden confiar.

aunque aprecio el detalle, está leyendo cosas en mi publicación que no están allí, así que lo dejaré más claro: no hay "compartir" o NAS involucrados aquí. estos son directorios que creé, no puntos de montaje. se sincronizan manualmente cuando es necesario. la mac en cuestión no es accesible a través de la red, la máquina remota de linux sí lo es. No me preocupa lo que Apple o la "industria" consideren las mejores prácticas, así que por favor no desperdicien su aliento tratando de convencerme de los beneficios de seguirlos mientras me arrebatan el control de la computadora.
Si estos directorios : la palabra operativa es "si", lo que significa que no importa para qué los esté usando. Las mejores prácticas son las mejores prácticas por una razón (al menos una importante); mitigan el riesgo. Si quieres seguir tu propio camino, está bien; solo significa que macOS no es la herramienta para ti, sino Linux.
RE: ¿Cómo reparar los permisos de macOS después de ejecutar “sudo chown -R www /”? (Una advertencia) -- Esto realmente no pertenece a su lista porque el comando que realmente ejecutó, sudo chown -R _WWW:_WWW /tal como ha sido editado desde entonces, es totalmente capaz de estropear partes del sistema sin deshabilitar SIP . En una VM macOS Catalina 10.15.4 de construcción limpia , ese comando simplemente cambió la _propiedad y el grupo en más de 54,700 archivos/directorios y arruinó totalmente el sistema mientras SIP estaba habilitado.
Aquí hay un enlace a un archivo zip de los archivos que tocó el comando : gofile.io/?c=rzjW7P
He deshabilitado SIP, tengo permisos de lectura/escritura con terminal, pero no con Finder. ¿Qué causa esto?
RespuestasAquíPolítica de privacidad1y, 0v