He desactivado la SIP, tengo permisos de lectura/escritura con el terminal, pero no con el Finder. Lo que provoca esto?

Yo uso remoto del servidor Linux donde el directorio root se utiliza (es decir, hay carpetas donde los usuarios pueden r/w tales como /data y /análisis )... En el interés de continuar con el uso de la organización de archivos de sistema en nuestro servidor remoto, he desactivado la SIP y estoy de montaje / de lectura/de escritura en cada arranque

Esta no es una buena estrategia y debe ser evitado.

La primera cosa y la más importante es darse cuenta de que macOS ≠ Linux. Lo de Linux que te permite "salirse con la suya" no es siempre una de las mejores prácticas para la administración del sistema. Cuando reducimos todo hacia abajo, lo que básicamente estás preguntando es sobre la colocación de dos carpetas y el directorio root no es realmente el mejor lugar para ellos, por tanto, las cuestiones que usted está corriendo en.

La desactivación de la SIP, quite una de las principales protecciones que hacen de éste uno de los más seguros sistemas operativos en el mercado hoy en día. Para conseguir alrededor de la arquitectura de seguridad de modo que usted puede crear carpetas y volúmenes de monte que residen en el directorio root es contraproducente. En lugar de luchar contra el sistema operativo, es mejor trabajar con él.

• Es /dev protegido por la SIP?
• Otro de los errores de usuario, ¿qué tipos de ataques sería SIP prevenir?
• Cómo reparar macOS permisos después de ejecutar "sudo chown -R _www /"? (Un cuento con moraleja)

A menos que esté seguro de que va directamente a ayudar a resolver este problema con el Buscador de...

Es no un problema con el Buscador. SIP ha sido alrededor de un largo tiempo; ya que El Capitan (10.11) fue lanzado en 2015. Esto no es nada nuevo. Sin embargo, el nuevo APF de la estructura de contenedor de tener dos volúmenes, uno de escritura y uno no (con - Data anexa el nombre de volumen) es nueva. Mientras que algunos de los cambios de seguridad que Apple ha implementado causa más dolores de cabeza de lo necesario, esto no es uno de ellos.

Esta realidad es algo que los administradores de sistemas deben estar haciendo de endurecimiento del sistema y la limitación de qué y donde el usuario puede escribir por "containerizing" (sandboxing) los directorios/con volúmenes adecuados de lectura/escritura/permisos de ejecución.

Monte el usuario puede acceder a los directorios en el lugar adecuado

De nuevo, en el directorio root no es realmente un lugar apropiado para compartido de datos ya sea macOS o Linux. Si estos directorios locales en el Mac (Mac es el recurso compartido de red), o si está montaje de un servidor de archivos remoto, que deben ser colocados en un protegidas volumen como en /Users/Shared o montados en /Volumes. El razonamiento detrás de esto es que se puede establecer el "padre" de los derechos y aplicarlo a todas las carpetas secundarias, mientras que si se va a modificar los derechos de algo en el directorio root, que podría aplicarse el mal permisos a través de todo el sistema.

Incluso mi servidor NAS de Synology (basado en Linux) no me permite crear acciones en la carpeta root. Me obliga a montar en un sub volumen con permisos de I (con acceso de root) no se puede modificar.

TL;DR

Usted va en contra de la corriente; el trabajo con el sistema operativo y no en contra de ella. Si usted está encontrando que usted necesita para deshabilitar todas las protecciones que el sistema entró con usted, es probable que no siguen un mejores prácticas de la industria. No trate de forzar macOS y el Buscador de comportarse de cierta manera porque se puede "hacerlo en Linux;" siga de plomo y tendrás un seguro, disponible y lo más importante de un sistema fiable que sus usuarios pueden depender.