Estamos procurando implantar os escritórios SMB no Debian (5.0.3) para nossos clientes mac em vez de comprar quatro novos Xserves. Nós temos nossos servidores de teste construídos e funcionando corretamente. Os clientes Windows se comportam perfeitamente, mas encontramos um problema com o OS X (10.6.xe 10.5.x). Estamos seguindo essa rota, em vez de servidores de arquivos do Windows, devido a um monte de outras questões que surgem quando se vai dessa maneira.
Especificamente, ao montar um compartilhamento SMB com extensões unix ativadas e o servidor remoto ligado ao AD, o localizador não pode salvar arquivos no compartilhamento, em vez de tocar no arquivo e, em seguida, bombardear com um erro -36 IO, a criação da pasta é bem. Copiar arquivos no terminal se comporta bem e o problema parece estar limitado ao localizador.
O problema surge (eu acho) como o UID / GID remoto é transmitido ao usar extensões unix. O OS X usa seu próprio idmap winbind (odsam) para trabalhar com o UID / GID efetivo de usuários e grupos do AD enquanto estamos usando um mapa livre no servidor. Consequentemente, há uma incompatibilidade na propriedade que o buscador escolhe honrar.
Como o OS X parece lidar com isso é usar o uid e o gid remotos no nível de permissão do arquivo (veja abaixo) e, em seguida, definir um OS X acl concedendo o uid / gid local para ter as permissões apropriadas no arquivo. Eu acho que o localizador toca o arquivo (que o kernel permite por causa da ACL) e então verifica o sistema de arquivos perms e sai com o erro IO.
Em um cliente
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
Tentamos o seguinte sem sorte:
- Definindo o proprietário do arquivo lateral do Linux para corresponder ao OS X GID / UID
- Adicionando ACLs no sistema de arquivos linux que concedem o OS X GID / UID perms
- Desativando atributos estendidos
- Configurando steams = não em /etc/nsmb.conf no cliente
Atualmente, estamos executando uma solução alternativa que é apenas desativar as extensões unix, o que força os macs a montar o compartilhamento como o usuário local com u = rwx perms. Isso funciona para a maioria das coisas, mas está causando alguns aplicativos que esperam que certos permanentes se quebrem de maneira sutil. Na pior das hipóteses, continuaremos executando dessa maneira, mas gostaríamos de ter as extensões unix ativadas.
Atenciosamente.
Configuração relevante do SMB abaixo:
[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