☰

Акции и доступ к OS X AFP

tag-icon • tag-icon mac-osx afp shares
Акции и доступ к OS X AFP

Я использую 10.5.6 Client как мини-сервер и у меня проблемы с общими ресурсами AFP. Все клиенты — OS X 10.5.7

Я создал трех пользователей для «Общего доступа к файлам» только на «сервере». Я создал группы и поместил этих пользователей в определенные группы. Я создал ACL, чтобы предоставить каждой группе доступ к определенным общим ресурсам.

Двое из этих пользователей могут читать и писать в любой общий ресурс, один пользователь не может писать в общие ресурсы, с разными результатами:

  • при копировании каталога создается только каталог, файлы внутри не копируются, ОС не выдает никаких ошибок
  • При копировании одного файла я получаю три диалоговых окна: «Возможно, вам потребуется ввести имя и пароль администратора на этом компьютере, чтобы изменить элемент с именем 'xxxx'», «Элемент 'xxxxx' содержит один или несколько элементов, на чтение которых у вас нет разрешения. Вы хотите скопировать элементы, на чтение которых у вас есть разрешение?» и «Операция не может быть завершена, так как у вас недостаточно прав для некоторых элементов».

При использовании одного файла файл создается на сервере, но он пустой.

Мой ACL для группы, к которой принадлежит этот пользователь:

 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

Пользователи 1 и 2 принадлежат к информационным технологиям, руководителям и членам проекта, они могут свободно читать и писать на общем ресурсе. Пользователь 3 принадлежит к членам проекта и не может свободно читать и писать.

Я читал, что это проблема с UID, однако у пользователей 1 и 2 не совпадают UID на клиентах и ​​сервере, и они работают, поэтому я не думаю, что это так.

Есть идеи?

решение1

Заменил свой первоначальный ответ после проведения собственного тестирования с использованием сервера OS X 10.5.6 и клиента 10.5.7:

После небольшого эксперимента я обнаружил, что OS X немного сумасшедшая, когда дело касается наследования ACL для точек общего доступа. ACL, которые унаследованы, всегда будут иметь приоритет над ACL, которые установлены в точке общего доступа (или ниже в дереве), но только дляписатьразрешения. Вы можете с легкостью дать пользователю разрешение на чтение папки, расположенной немного ниже по дереву, и это будет работать, но если вы дадите ему разрешение на запись, это безнадежно потерпит неудачу.

Чтоделаетработает. Отключите наследование для правила запрета над проблемным ресурсом (вы можете сделать это там, просто не позволяйте ему наследовать каким-либо образом). Затем явно установите запрет в точке ресурса (включение наследования в этой точке, кажется, работает просто отлично). В моем тестировании это работало без проблем, но было бы мучительно, если бы вам пришлось управлять сотнями похожих ресурсов.

Одним из вариантов может быть верхний уровень общего запрета на Everyone having read, а затем блокировка no-inherit на write, как предлагалось выше. Пожалуйста, дайте мне знать, как у вас идут дела, так как я заинтересован в собственном управлении акциями.

Связанный контент