partilhas e acesso ao SO X AFP

Question

Estou executando o 10.5.6 Client como um mini-servidor e estou tendo problemas com compartilhamentos AFP. Todos os clientes são OS X 10.5.7

Eu criei três usuários para 'Compartilhamento de Arquivos' somente no 'servidor'. Eu criei grupos e coloquei esses usuários em grupos específicos. Eu criei ACL's para dar a cada grupo acesso a certos compartilhamentos.

Dois desses usuários podem ler e gravar em qualquer compartilhamento, um usuário não pode gravar nos compartilhamentos, com resultados diferentes:

• ao copiar um diretório, apenas o diretório é criado, nenhum arquivo interno é copiado, o sistema operacional não fornece erros
• ao copiar um único arquivo, recebo três caixas de diálogo: "Talvez seja necessário digitar o nome e a senha de um administrador neste computador para alterar o item denominado 'xxxx'," O item 'xxxxx' contém um ou mais itens não tem permissão para ler. Deseja copiar os itens que você pode ler ?, e A operação não pode ser concluída porque você não tem privilégios suficientes para alguns itens.

Com o arquivo único, um arquivo é criado no servidor, mas está vazio.

Minha ACL para o grupo ao qual este usuário pertence é:

 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

Usuário 1 & 2 pertencem à tecnologia da informação e aos membros executivos e do projeto, eles podem ler e escrever livremente sobre a ação. O usuário 3 pertence a membros do projeto e não pode ler e escrever livremente.

Eu li que este é um problema de UID, no entanto, o usuário 1 & 2 não têm UIDs compatíveis entre clientes e servidor e funcionam, por isso não acho que seja esse o caso.

Alguma idéia?

    

Answer 1

Substitui minha resposta original depois de fazer alguns testes usando um servidor OS X 10.5.6 e um cliente 10.5.7:

O que eu encontrei depois de um pouco de experimentação é que o OS X é um pouco louco quando se trata de herança ACL para pontos de compartilhamento. As ACLs herdadas sempre terão precedência sobre as ACLs definidas no ponto de compartilhamento (ou inferior na árvore), mas apenas para as permissões gravação . Você pode muito bem dar a um usuário permissões de leitura em uma pasta pela árvore e isso funcionará, mas se você der a eles uma gravação, ela falhará irremediavelmente.

O que funciona . Desative a herança para a regra de negação acima do compartilhamento de problema (você pode tê-la lá, simplesmente não herdar de qualquer forma). Em seguida, defina explicitamente a negação no ponto de compartilhamento (ativar a herança nesse ponto parece funcionar bem). Meus testes tiveram que funcionar sem problema, mas seria um problema se você tivesse que gerenciar centenas de compartilhamentos similares.

Uma opção pode ser uma negação de cobertura de nível superior em Todas as pessoas que tenham lido e, em seguida, o bloqueio sem herança na gravação, conforme sugerido acima. Por favor, deixe-me saber como você se interessa pelo meu próprio gerenciamento de ações.