クライアントが切断した後にsambaがファイルロックを保持するのを防ぐ方法は？

ここでは、Windows XPプロファイルをホストするように構成されたSambaサーバー（Debian 5.0）を使用しています。

クライアントはこのサーバーに接続し、samba共有上のプロファイルで直接作業します（プロファイルはローカルにコピーされません）。

時々、クライアントが適切にシャットダウンせず、Windowsがファイルロックを解放しない場合があります。sambaロッキングテーブルを見ると、クライアントが接続されていなくても、多くのファイルがまだロックされていることがわかります。私たちの場合、これはMozilla ThunderbirdとFirefoxによって作成されたロックファイルで発生するようです。以下は、sambaロッキングテーブルの例です。

# smbstatus -L | grep DENY_ALL | head -n5
Pid          Uid        DenyMode   Access      R/W        Oplock           SharePath   Name   Time
--------------------------------------------------------------------------------------------------
15494        10345      DENY_ALL   0x3019f     RDWR       EXCLUSIVE+BATCH  /home/CORP/user1   app.profile/user1.thunderbird/parent.lock   Mon Nov 22 07:12:45 2010
18040        10454      DENY_ALL   0x3019f     RDWR       EXCLUSIVE+BATCH  /home/CORP/user2   app.profile/user2.thunderbird/parent.lock   Mon Nov 22 11:20:45 2010
26466        10056      DENY_ALL   0x3019f     RDWR       EXCLUSIVE+BATCH  /home/CORP/user3   app.profile/user3.firefox/parent.lock   Mon Nov 22 08:48:23 2010

ファイルがWindowsによって開かれ、DENY_ALLロックを課したことがわかります。

クライアントがこの共有に再接続してそれらのファイルを開こうとすると、Sambaはそれらがロックされていてアクセスを拒否すると言っています。

この状況を回避する方法はありますか、それとも何か不足していますか？

編集：そこので、私たちは、Sambaサーバー上のファイルのロックを無効にすることを避けたいですそれらが有効になっているのは良い理由は。

以下の手順は、多くの場合にこの正確な問題を解決するのに役立ちました。

1. sambaサーバーにログインします。
2. 「smbstatus」を実行します。
3. 出力の3番目のセクションで、ファイルをロックしているプロセスのpidを見つけます。
4. smbstatusの出力の最初と2番目のセクションで、予想されるユーザーとホスト名が一致することを確認します。
5. 「ps -ef」を実行して、そのpidを持つsmbdが実行されている時間を確認します。
6. コンピュータが最後に再起動される前から実行されている場合は、残りのsmbdです。ただ1つのsmbdを殺す。（そして、あなたが正しいものを取得することを確認してください-それは1と等しくない親pidを持つものであるべきです。）

見て：

reset on zero vc = yes / no

それで問題が解決するかどうかを確認します。

smb.confmanページから：

このブールオプションは、着信セッションのセットアップで同じIPからの他の接続を強制終了するかどうかを制御します。これは、Windows 2003のデフォルトの動作と一致します。不安定なネットワークがあり、古い接続で共有モードが開いたファイルが残っている間にWindowsが再接続することを決定した場合、このパラメーターをyesに設定する必要があります。これらのファイルは、新しい接続を介してアクセスできなくなります。クライアントは新しい接続でゼロVCを送信し、Windows 2003は同じIPからの他のすべての接続を強制終了します。このようにして、ロックされたファイルに再びアクセスできます。このオプションを有効にすると、マスカレードルーターの背後にある接続が強制終了されることに注意してください。

編集：
別の可能な解決策を考えました。問題の共有でこのようなことを行うことができます。

veto oplock files = /*.lock/

これは、.lockファイルのoplockを防ぐだけです。

Sambaの非常に賢い人の中には、このオプションを削除することを決めた人もいますが、それに代わるものはありません。

SMB互換性については、これが実際にデフォルトの勝利動作であるため、これまでのところ。

ユーザーがLinuxコマンドラインと、開いているファイル/プロセスを強制終了する方法に精通している場合を除き、SMBDまたはサーバー自体を再起動してこれをクリアする必要があります。

素晴らしく完了しました、Samba.org。

私は同様の問題に遭遇していました。大きなファイルをコピーしているときにクライアントがクラッシュし、再起動後にファイルがロックされました。幸いにも、これはそれほど頻繁には起こりませんが、それでもsambaプロセスを強制終了しなければならないのは非常に面倒です。 reset on zero vcFedora（27）のバージョン4.7.6にはまだ（おそらくRHによってパッチが適用されています）が、Samba4から削除されたと思われます。とにかく、manページに記載されているように、SMB1（これ以上使用しないでください）でのみ機能し、SMB2およびSMB3接続では何も実行しないことはあまり役に立ちません。これを処理するために残された唯一の方法は、 Michealによってリンクされたスレッド。削除の理由と、何が悪いのかわかりませんreset on zero vc、私はこの目的のためにハックのようにtcpタイムアウトを使用することを検討します。とにかく、合理的なものは例えば

socket options = TCP_NODELAY SO_KEEPALIVE TCP_KEEPIDLE=30 TCP_KEEPCNT=3 TCP_KEEPINTVL=3

これは、最後の通信から約40秒（30 + 3 * 3）後に接続を強制終了します。これは通常、クラッシュを認識して再起動するのに十分です（サーバーのTCPスタックがクライアントの接続を閉じるのに十分スマートである場合）再起動後にキープアライブパケットを拒否します）。

これによりネットワークの負荷が増加することに注意してください。ただし、多くのクライアントを使用している場合でも、それが目立つことはありません。

次のようにして、共有ごとにoplockを無効にすることができます。

[acctdata]
oplocks = False
level2 oplocks = False

デフォルトのoplockタイプはLevel1です。Level2 oplocksは、smb.confファイルで共有ごとに有効化されます。または、共有内のファイルごとにoplockを無効にすることもできます。

veto oplock files = /*.mdb/*.MDB/*.dbf/*.DBF/

Sambaのログエントリから明らかなように、oplockで問題が発生している場合は、安全に実行して、oplockとLevel2 oplockを無効にすることができます。

カーネルoplockの無効化カーネルoplockは、UNIXプロセスがキャッシュされたファイルを開こうとするときにSambaに通知するsmb.confパラメータです（UNIXカーネルにWindowsクライアントにoplockブレークを送信する機能がある場合）。このパラメーターは、Sambaサーバーでoplocksが有効になっているUNIXとWindowsの間のファイルの共有に対応します。UNIXプロセスは、WindowsクライアントによってOplocked（キャッシュ）されたファイルを開くことができ、smbdプロセスはoplockブレークを送信しないため、ファイルが公開されます。データ破損のリスク。UNIXカーネルにoplockブレークを送信する機能がある場合、カーネルのoplocksパラメータにより、Sambaはoplockブレークを送信できます。カーネルoplockは、smb.confファイルでサーバーごとに有効化されます。

kernel oplocks = yes

デフォルトはnoです。

ソース