OS X: ошибка Finder -36 при использовании общих ресурсов SMB на сервере Samba, связанном с AD

Мы смотрим на развертывание домов SMB в Debian (5.0.3) для наших клиентов Mac, а не на покупку четырех новых Xserve. Наши тестовые серверы построены и работают должным образом. Клиенты Windows ведут себя отлично, но мы столкнулись с проблемой с OS X (10.6.x и 10.5.x). Мы идем этим путем вместо файловых серверов Windows из-за целого ряда других проблем, которые возникают при этом.

В частности, при монтировании общего ресурса SMB с включенными расширениями Unix и удаленным сервером, связанным с AD, искатель не может сохранить файлы на общем ресурсе, вместо этого прикоснувшись к файлу, а затем сбросив его с ошибкой -36 IO, создание папки в порядке. Копирование файлов в терминале ведет себя хорошо, и проблема, похоже, ограничена искателем.

Проблема возникает (я думаю), поскольку удаленный UID/GID передается при использовании расширений Unix. OS X использует свою собственную winbind idmap (odsam) для определения эффективного UID/GID от пользователей и групп AD, в то время как мы используем карту избавления на сервере. Следовательно, существует несоответствие в праве собственности, которое искатель выбирает для соблюдения.

То, как OS X, кажется, справляется с этим, состоит в том, чтобы использовать удаленный uid и gid на уровне разрешений файла (см. Ниже), а затем установить acl OS X, предоставляющий локальному uid/gid соответствующие права доступа к файлу. Я думаю, что искатель касается файла (который ядро ​​разрешает из-за ACL), а затем проверяет перми файловой системы и выпадает с ошибкой ввода-вывода.

На клиенте

fc-003353-d:homes2 root# ls -led test/
drwx------+ 2 135978  100513  16384 Feb  3 15:14 test/
 0: user:jfrench allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit
 1: group:ARTS\domain users allow 
 2: group:everyone allow 
 3: group:owner allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit,only_inherit
 4: group:group allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit,only_inherit
 5: group:everyone allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit,only_inherit

Мы безуспешно попробовали следующее:

  • Установка владельца файла на стороне Linux в соответствии с GID / UID OS X
  • Добавление списков ACL в файловой системе Linux, которые предоставляют права доступа OS X GID/UID
  • Отключение расширенных атрибутов
  • Установка пары = нет в /etc/nsmb.conf на клиенте

В настоящее время мы используем обходной путь, который заключается в том, чтобы просто отключить расширения Unix, которые заставляют macs просто монтировать общий ресурс как локальный пользователь с разрешением u=rwx. Это работает для большинства вещей, но приводит к тому, что некоторые приложения, которые ожидают, что некоторые привилегии ломаются тонкими способами. В худшем случае мы продолжим работать таким образом, но нам бы хотелось, чтобы расширения Unix были включены.

С уважением.


Соответствующая конфигурация SMB ниже:

[global]
        workgroup = ARTS
        realm = *snip*
        security = ADS
        password server = *snip*
        unix extensions = yes
        panic action = /usr/share/panic-action %d
        idmap backend = rid:ARTS=100000-10000000
        idmap uid = 100000-10000000
        idmap gid = 100000-10000000
        winbind enum users = Yes
        winbind enum groups = Yes
        veto files = /lost+found/aquota.*/
        hide files = /desktop.ini/$RECYCLE.BIN/.*/AppData/Library/
        ea support = yes
        store dos attributes = yes
        map system = no
        map archive = no
        map readonly = no

6 ответов

Решение

Вероятно, проблема связана с ошибками Finder в способе обработки ресурсов ресурсов как расширенных атрибутов.

Я бы попробовал:

поддержка = нет

Это может привести к._ файлам, но пока Apple не позаботится о том, чтобы сделать их файловый менеджер совместимым, это то, с чем вам придется иметь дело.

Изменить: я только что заметил, что вы на самом деле пытались отключить их. Вот где я столкнулся со всеми проблемами Finder. После небольшого поиска кажется, что отключение расширений Unix - единственное исправление, о котором сообщают.

Вы можете попробовать: расширения Unix = нет

Вы можете посмотреть в настройках именованных потоков. У Apple есть статья об этом. "Mac OS X v10.5, v10.6: об именованных потоках на серверах NAS, Mac OS X и Windows, смонтированных на SMB; могут появляться предупреждения"-36"или"-50"

В другой статье Apple TS1564 упоминается более ранняя проблема в 10.3/10.4, приводящая к ошибке -36 с акциями SMB.

Очевидно это связано с открытым текстом против зашифрованной аутентификации... что-то еще, чтобы рассмотреть?

Ура, М.

Просто чтобы уточнить: ваш обходной путь - установить unix extensions = no в /etc/smb.conf на КЛИЕНТА, верно?

Потому что я пробовал это, но я все еще получаю ошибку 36.

Я сам столкнулся с этой проблемой, и нашел на http://osxdaily.com/2015/02/21/fix-error-code-36-finder-mac-os-x/ гораздо более простое решение.

На вашем Mac откройте терминал и запустите dot_clean по отношению к папке назначения вашего загружаемого файла.

Например, я загружаю все свои файлы в ~/Downloads папку, чтобы я запускаю:

dot_clean ~/Downloads

После этого повторная попытка загрузки прошла успешно.

Другие вопросы по тегам