サービス移行後の不思議なSamba権限の失敗

maildirネットワーク共有（CIFS）を新しいストレージサーバーに移行した後、ファイル権限の問題が発生し始めました（ユーザーは既存のメールを削除できませんでした）。私のIMAPサービスはDovecotですが、そのサービスより低いレベルで問題を識別できます。

rootこの問題は、ファイルをホストしているサーバーとファイルがインストールされているサーバー（以下「クライアント」といいます）のメールディレクトリに移動して、次の動作を経験/観察できるために発生します。

• ls両方のコンピュータに同じファイルのリストと権限を表示します。
• 移行後の権限はまったく一致しませんが、権限の変更は動作に影響しません。 （すべての後続の操作は特権ファイルで行われます-rw-rw---- 1 mail mail。）
• mailnotの代わりにas操作を実行してもroot効果はありません。

• 次のように権限を変更してみてくださいchmod g-rw *。

  • サーバーではうまく機能します
  • 移行後に生成されたファイルに対してクライアントで正常に動作します。

  • クライアントの事前移行ファイルで次のエラーが発生します。

    chmod: "1479603582.M874812P11259.Pantheon,S=84750,W=85933:2,Sa" の権限変更: 無効な引数

• ファイルをお読みください：
  • サーバーではうまく機能します
  • クライアントファイル名オートコンプリートとvimレポートPermission Denied

以前のファイルに影響を与える可能性があるACLが見つかると、サーバーに次の出力が表示されます。

root@<storage-server>:/<path-to-share>/<site>/<user>/folders/cur# getfacl <filename>
# file: <filename>
# owner: mail
# group: mail
user::rw-
group::rw-
other::---

getfattr何も出力されません。

ストレージサーバーは、以前はZFSストレージプールでCIFSサービスを使用していたSolaris + debianベースの古いソフトウェアオペレーティングシステム（Nexenta）でした。 Ubuntu 16.04では、ZFSストレージプールのCIFSサービスを再利用します。すべての場合で ACL はサポートされますが、どこでも使用されません。

私のSamba共有の設定：

[Maildir]
    path = /<path-to-share>
    browseable = no
    guest ok = no
    valid users = mail
    writable = yes
    create mode = 0660
    directory mode = 0770

//<host>/Maildir /var/mail cifs auto,credentials=/root/.smb_mail,user,rw,exec 0 0ファイルシステムとその親システムのすべてのzfsプロパティはデフォルト値を持ちます。

作成モード/ディレクトリモードを削除し、有効なユーザーに@mailを追加しようとしましたが、どちらも機能しませんでした。

自分の権限がどのように間違っている可能性がありますか？

修正する:

NFS共有に切り替えようとしましたが、問題はまだ存在します。私はmaildirの内容を使って新しい場所（別の新しいファイルシステム）にコピーしましたが、まったくcp -r別chown -r mail:mailのパスで提供されている間はまだ存在します。

最終的に私はそれを試しましたが、mv somefile backup && rm somefile && cat backup > somefile && chown mail:mail somefile権限が拒否され、ファイルを読み取ろうとする試みはまだ失敗しました。

共有メカニズム、論理的な場所、Unix権限/所有権、またはあらゆる種類のファイルメタデータとは独立した方法で特定のファイルに対する操作を防ぐ方法がわかりません。

アップデート2：

NFS共有に再度切り替えようとしましたが、今回は権限の問題がなくなりました。ただし、NFSに切り替えると、他の問題、特にブート問題が発生する可能性があるため、切り替えたくありません。問題は間違いなくSambaにありますが、すべての操作データ（さまざまな.tdbや.datファイルなど）を消去しても役に立ちません。

アップデート3：

問題は、コロンを含むファイル名に絞り込まれました。コロンを削除するためにファイル名を変更するとクライアントから読み取ることができ、コロンを含む元の名前に名前を変更すると読み取れなくなります。時間が経つにつれて、Dovecotは特定の情報を追跡するためにファイル名を変更し、コロンを追加して最終的にすべてのメッセージを読み書きできないように見えますが、以前もこれが起こりました。

いくつかの追加の観察：コロンを使用してファイルを作成および読み込むことはクライアントで機能します（コロンはサーバー上の二重引用符で表示されます）。ところで、これが最初にコロンのあるファイル名を取得する方法です...最新のファイルにはコロンが2つあるように見えますが、サーバーには二重引用符とコロンがあるように表示されます。

ある種のコーディング問題のように見え始めました。特に、2つのシステムが初めて同種であるため、奇妙です。