我们正在考虑为我们的Mac客户端在Debian(5.0.3)上部署SMB家庭,而不是购买四个新的Xserves。 我们有我们的testing服务器build立和运作正常。 Windows客户端performance完美,但是我们遇到了OS X(10.6.x和10.5.x)的问题。 我们正在走这条路线而不是Windows文件服务器,因为这样做会产生大量的其他问题。
具体来说,如果挂载unix扩展和远程服务器绑定到AD上的SMB共享,find者不能保存共享上的文件,而是触摸文件,然后轰炸出一个-36 IO错误,文件夹创build是好的。 复制terminal中的文件performance良好,问题似乎仅限于取景器。
这个问题出现了(我认为),因为在使用unix扩展时远程UID / GID被传递。 OS X使用自己的winbind idmap(odsam)来计算AD用户和组的有效UID / GID,同时我们在服务器上使用了一个rid映射。 因此,发现者所select的所有权不一致。
OS X如何处理这个问题是在文件权限级别使用远程uid和gid(见下文),然后设置OS X acl来授予本地uid / gid在文件上具有适当的权限。 我认为finder触及文件(内核允许,因为ACL),然后检查文件系统的权限,并与IO错误退出。
在客户端上
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
我们已经尝试了以下,没有任何运气:
目前我们正在运行一个解决方法,就是closuresunix扩展,强制mac只以u = rwx perms作为本地用户挂载共享。 这适用于大多数情况,但导致一些应用程序,期望某些烫发以微妙的方式打破。 最糟糕的情况是,我们将继续以这种方式运行,但我们希望有unix扩展。
问候。
相关的SMBconfiguration如下:
[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
这个问题可能是由于Findererror handling资源分叉的扩展属性。
我会尝试:
ea支持=否
这可能会导致._文件,但直到Apple足够关心使其文件pipe理器可以互操作,这是你必须处理的。
编辑:我只是注意到你确实尝试禁用它们。 那就是我遇到的所有Finder问题。 经过一些简短的search,看起来像closuresunix扩展是唯一的报告的修复程序。
您可能想要查看指定的stream设置。 苹果有一个文章 。 “Mac OS X v10.5,v10.6:关于SMB安装的NAS,Mac OS X和Windows服务器上的命名stream;”-36“或”-50“警报可能出现”
不同的苹果文章TS1564引用10.3 / 10.4中的早期版本,在SMB共享中产生错误-36。
显然这是相关的明文与encryption身份validation…别的要考虑?
干杯,米
你可以试试:unix extensions = no
只是为了澄清:你的解决方法是在CLIENT上的/etc/smb.conf中设置unix extensions = no,对吧?
因为我尝试过,但仍然得到了36错误。
我自己也遇到过这个问题,并在http://osxdaily.com/2015/02/21/fix-error-code-36-finder-mac-os-x/上find了一个更简单的解决scheme。
在您的Mac上,打开terminal并对您的下载文件的目标文件夹运行dot_clean 。
例如我下载我的所有文件到~/Downloads文件夹,所以我运行:
dot_clean ~/Downloads
之后重新尝试下载成功。