smbdWindowsがSamba共有にアクセスするとき、Windowsが共有を使用しているかどうかにかかわらず、デーモンは常にCPUの約10〜20％を使用していることがわかりました。共有/ウィンドウを閉じても、smbdCPUは引き続き使用され、Windowsを再起動/終了しなければ、CPU使用率は通常のレベルに低下します。
Windowsを再起動/起動したときに発生した状況です。共有はマップされていますが、まだアクセスされていません。アクセスするまで、Windowsは「赤」で表示されます。
他の作業を行う前に、Linuxでsmbstatus合計を確認してくださいtop。
これまでは問題ありません。 CPU使用量はまったく目立たないので、topすべてが正常です。
しかし... Windowsで共有にアクセスすると、Linux CPUはすぐに10-20％に上がります。
そして、smbstatus常に私のWindowsではアクセスできない（？）いくつかのロックされた（？）ファイルが表示されます。
testparm自分の設定を表示しますsmb.conf。
「この問題を解決する」唯一の方法は、Windowsを再起動するか、ドライブ/共有マッピングを無効にすることです。
もう1つの奇妙なことは、もちろん、共有/ドライブのマッピングを解除しても、もちろんUNCを介して共有にアクセスできるということです。 ？奇妙な！
私のハードウェアは最新です。
サーバー: Core i5 1.5-2.9GHz デュアルコア/HT 16GB RAM Samsung 850 Pro(512GB)
クライアント：Windows 8.1
問題なくCentOS 6インストールで同じ設定を使用しました。また、Windowsコンピュータのネットワーク共有と通信できると思われるすべてのソフトウェア（ウイルス対策およびバックアップソフトウェア）を無効にしてみました。
この問題を解決するのに役立つ人はいますか？
ベストアンサー1
少し遅れているかもしれませんが、同様の問題に直面してこれを発見しました。
私はSambaをドライブストレージとして設定し、イーサネット経由でラップトップに直接接続したRaspberry Pi B +を持っています。
私の設定は次のとおりです。
- 複数の外付けハードドライブがRaspberry Piに接続されています。
- Raspberry piはダイレクトイーサネットを使用してラップトップに接続します。
私が見つけた：
- smbdは外部から読み取るとCPU使用率（45％）が高くなります。
- Mount.ntfsは、外部への書き込み時にCPU使用率（46％）が高くなります。
B + 仕様を考慮すると、これは単純な適切なアップデートに1分かかりますので、ややそうです。したがって、リストを更新するだけで...
これ良い読書効果をもたらすことができます。