クライアントが切断した後にsambaがファイルロックを保持するのを防ぐ方法は？
ここでは、Windowsをホストするように構成されたSambaサーバー（Debian 5.0）を使用していますXPプロファイル。
クライアントはこのサーバーに接続し、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サーバーでファイルロックを無効にしたくないare有効にする理由があるためです。
以下の手順は、この正確な問題を多くの場合に解決するのに役立ちました。
- Sambaサーバーにログインします。
- 「smbstatus」を実行します。
- 出力の3番目のセクションで、ファイルをロックしているプロセスのpidを見つけます。
- Smbstatusの出力の最初と2番目のセクションで、予想されるユーザーとホスト名が一致することを確認します。
- "ps -ef"を実行して、そのpidを持つsmbdが実行されている時間を確認します。
- コンピュータが最後に再起動される前から実行されている場合は、残りのsmbdです。ただ1つのsmbdを殺す。 （そして、あなたが正しいものを取得することを確認してください-それは1と等しくない親pidを持つものであるべきです。）
見て：
reset on zero vc = yes / no
それで問題が解決するかどうかを確認します。
から smb.conf manページ：
このブールオプションは、着信セッションのセットアップで同じIPからの他の接続を強制終了するかどうかを制御します。これは、Windows 2003のデフォルトの動作と一致します。不安定なネットワークがあり、古い接続で共有モードが開いたファイルが残っている間にWindowsが再接続することを決定した場合、このパラメーターをyesに設定する必要があります。これらのファイルは、新しい接続を介してアクセスできなくなります。クライアントは新しい接続でゼロVC=を送信し、Windows 2003は同じIPからの他のすべての接続を強制終了します。これにより、ロックされたファイルに再びアクセスできます。このオプションを有効にすると、マスカレードルーターの背後にある接続を強制終了します。
編集：
別の可能な解決策を考えました。問題の共有でこのようなことを行うことができます。
veto oplock files = /*.lock/
これは、.lockファイルのoplockを防ぐだけです。
私は同様の問題に遭遇していました。大きなファイルをコピーしているときにクライアントがクラッシュし、再起動後にファイルがロックされました。幸い、これはそれほど頻繁には起こりませんが、それでもsambaプロセスを強制終了しなければならないのはかなり面倒です。 reset on zero vcは単なる解決策のようですが、Samba4から削除されたと思われますが、Fedora（27）のバージョン4.7.6にはまだ（おそらくRHによってパッチが適用されています）。とにかく、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スタックがクライアントの接続を閉じるのに十分スマートである場合）リブート後にキープアライブパケットを拒否します）。
これによりネットワークの負荷が増加することに注意してください。ただし、多くのクライアントを使用した場合でも、それが目立つことはないと思います。
Sambaの非常に賢い人の中には、このオプションを削除することを決めた人もいますが、それに代わるものはありません。
これまでのところSMB互換性については、これは実際にデフォルトの勝利動作であるためです。
ユーザーがLinuxコマンドラインと、開いているファイル/プロセスを強制終了する方法に精通している場合を除き、SMBDまたはサーバー自体を再起動してこれをクリアする必要があります。
素晴らしく完了しました、Samba.org。
次のようにして、共有ごとに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です。