web-dev-qa-db-ja.com

OS X：ADにバインドされたSambaサーバーでSMB共有を使用する場合のファインダーエラー-36

4つの新しいXserveを購入するのではなく、Macクライアント用にDebian（5.0.3）にSMBホームをデプロイすることを検討しています。テストサーバーが構築され、正しく機能しています。Windowsクライアントは動作します。完全ですが、OS X（10.6.xおよび10.5.x）で問題が発生しました。このルートでは、他にも多くの問題が発生するため、Windowsファイルサーバーではなくこのルートを使用します。

具体的には、UNIX拡張機能をオンにしてリモートサーバーをADにバインドしたSMB共有をマウントすると、Finderは共有にファイルを保存できず、代わりにファイルに触れてから-36で爆撃します。 IOエラー、フォルダの作成は問題ありません。ターミナルでのファイルのコピーは問題なく動作し、問題はFinderに限定されているようです。

この問題は、UNIX拡張機能を使用するときにリモートUID/GIDが渡されるときに発生します（私は思います）。 OS Xは、独自のwinbind idmap（odsam）を使用して、サーバーでridマップを使用しているときに、ADユーザーおよびグループからの有効なUID/GIDを計算します。その結果、ファインダーが尊重することを選択した所有権の不一致があります。

OS Xがこれを処理しているように見えるのは、ファイルのアクセス許可レベルでリモートuidとgidを使用し（以下を参照）、ローカルのuid/gidにファイルに対する適切なアクセス許可を付与するOSXaclを設定することです。 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

運が悪かったので、次のことを試しました。

  • Linux側のファイル所有者をOSX GID/UIDと一致するように設定する
  • OS X GID/UIDパーマを付与するACLをLinuxファイルシステムに追加する
  • 拡張属性の無効化
  • クライアントの/etc/nsmb.confでsteams = noを設定する

現在、UNIX拡張機能をオフにするだけで回避策を実行しています。これにより、Macはu = rwxpermsを使用してローカルユーザーとして共有をマウントするだけになります。これはほとんどの場合に機能しますが、特定のパーマが微妙に壊れることを期待するいくつかのアプリを引き起こしています。最悪のシナリオは、この方法で実行を継続することですが、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
sambamac-osxwinbindfinder
5
Frenchie

この問題は、リソースフォークを拡張属性として処理する方法のFinderのバグが原因である可能性があります。

私は試してみます：

eaサポート=いいえ

これにより._ファイルが生成される可能性がありますが、Appleがファイルマネージャを相互運用可能にするのに十分な注意を払うまでは、これに対処する必要があります。

編集：あなたが実際にそれらを無効にしようとしたことに気づきました。それは私がすべてのFinderの問題に遭遇したところです。簡単に検索したところ、UNIX拡張機能をオフにすることが報告された唯一の修正であるように見えます。

1
Brandon

あなたは試すことができます：unix拡張機能=いいえ

1
der Flo

別のApple記事 TS1564 は、10.3/10.4の以前の問題を参照しており、SMB共有でエラー-36が生成されます。

どうやらそれはクリアテキスト認証と暗号化認証に関連しているようです...他に考慮すべきことはありますか？

乾杯、M。

1
Mark Glossop

名前付きストリームの設定を調べることをお勧めします。 Appleには記事があります 。 「MacOSX v10.5、v10.6：SMBマウントNAS、Mac OS X、およびWindowsサーバー上の名前付きストリームについて。「-36」または「-50」アラートが表示される場合があります」

1
tegbains

明確にするために：回避策は、クライアントの/etc/smb.confでunix拡張機能= noを設定することですよね？

私はそれを試しましたが、それでも36エラーが発生するためです。

0
theduke

私は自分でこの問題を抱えていましたが、 http://osxdaily.com/2015/02/21/fix-error-code-36-Finder-mac-os-x/ ではるかに簡単な解決策を見つけました。 =。

Macで、ターミナルを開き、ダウンロードファイルの宛先フォルダーに対してdot_cleanを実行します。

例えば。すべてのファイルを~/Downloadsフォルダーにダウンロードして、次のコマンドを実行します。

dot_clean ~/Downloads

その後、ダウンロードの再試行は成功しました。

0
tokenizer_fsj