Estoy ejecutando el Cliente 10.5.6 como mini servidor y tengo problemas con los recursos compartidos de AFP. Todos los clientes son OS X 10.5.7
He creado tres usuarios para "Compartir archivos" solo en el "servidor". Creé grupos y coloqué a estos usuarios en grupos específicos. He creado ACL para darle a cada grupo acceso a ciertos recursos compartidos.
Dos de esos usuarios pueden leer y escribir en cualquier recurso compartido, un usuario no puede escribir en los recursos compartidos, con resultados diferentes:
- al copiar un directorio, solo se crea el directorio, no se copian archivos dentro, el sistema operativo no da ningún error
- al copiar un solo archivo, aparecen tres cuadros de diálogo: "Es posible que deba ingresar el nombre y la contraseña de un administrador en esta computadora para cambiar el elemento llamado 'xxxx', "El elemento 'xxxxx' contiene uno o más elementos que no tiene permiso para leer. ¿Quiere copiar los elementos que puede leer? y La operación no se puede completar porque no tiene privilegios suficientes para algunos de los elementos.
Con el archivo único, se crea un archivo en el servidor, pero está vacío.
Mi ACL para el grupo al que pertenece este usuario es:
0: group:projectmembers allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit
1: group:informationtechnology inherited allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit
2: group:executive inherited allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit
3: group:everyone inherited deny list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit
Los usuarios 1 y 2 pertenecen a miembros ejecutivos y de proyectos de tecnología de la información y pueden leer y escribir libremente en el recurso compartido. El usuario 3 pertenece a los miembros del proyecto y no puede leer ni escribir libremente.
He leído que se trata de un problema de UID, sin embargo, los usuarios 1 y 2 no tienen UID coincidentes entre los clientes y el servidor y funcionan, por lo que no creo que este sea el caso.
¿Algunas ideas?
Respuesta1
Reemplacé mi respuesta original después de hacer algunas pruebas por mi cuenta usando un servidor OS X 10.5.6 y un cliente 10.5.7:
Lo que descubrí después de un poco de experimentación es que OS X está un poco loco cuando se trata de herencia de ACL para puntos compartidos. Las ACL que se heredan siempre tendrán prioridad sobre las ACL que se establecen en el punto compartido (o más abajo en el árbol), pero solo paraescribirpermisos. Puedes darle a un usuario permisos de lectura en una carpeta del árbol y funcionará, pero si le das escritura, fallará irremediablemente.
Quéhacetrabajar. Desactive la herencia para la regla de denegación situada encima del recurso compartido problemático (puede tenerla allí, pero no la herede de ninguna manera). Luego establezca explícitamente la denegación en el punto compartido (activar la herencia en este punto parece funcionar bien). Mis pruebas funcionaron sin problemas, pero sería una molestia si tuvieras que administrar cientos de recursos compartidos similares.
Una opción podría ser una denegación general de nivel superior para que todos hayan leído y luego el bloqueo de no herencia al escribir como se sugirió anteriormente. Por favor, déjeme saber cómo le va, ya que estoy interesado en mi propia gestión de acciones.