次の方法で共有

サーバー メッセージ ブロック (SMB) の高度なトラブルシューティング

  • [アーティクル]

仮想オペレーターを試す - SMB に関する一般的な問題をすばやく特定、解決するのに役立ちます。

サーバー メッセージ ブロック (SMB) は、ファイル システム操作用のネットワーク トランスポート プロトコルであり、クライアントからサーバー上のリソースにアクセスできるようになります。 SMB プロトコルの主な目的は、TCP/IP 経由で 2 つのシステム間のリモート ファイル システム アクセスを有効にすることです。

SMB のトラブルシューティングは、非常に複雑である場合があります。 この記事は、完全なトラブルシューティング ガイドではなく、SMB の効果的なトラブルシューティング方法の基本を理解するための簡単な入門資料です。

ツールとデータ収集

品質の良い SMB のトラブルシューティングの重要な特性の 1 つは、正しい用語を使用することです。 そのため、この記事では、データの収集と分析の精度を確保するための基本的な SMB の用語について説明します。

Note

"SMB サーバー (SRV)" は、ファイル システムをホストしているシステム (ファイル サーバーとも呼ばれます) を指します。 "SMB クライアント (CLI)" は、OS のバージョンまたはエディションに関係なく、ファイル システムにアクセスしようとしているシステムを指します。

たとえば、Windows Server 2016 を使用して Windows 10 でホストされている SMB 共有に接続する場合は、Windows Server 2016 が SMB クライアントであり、Windows 10 が SMB サーバーです。

データを収集する

SMB の問題のトラブルシューティングを行う前に、まずクライアント側とサーバー側の両方でネットワーク トレースを収集することをお勧めします。 次のガイドラインが適用されます。

  • Windows システムでは、netshell (netsh)、ネットワーク モニター、Message Analyzer、または Wireshark を使用してネットワーク トレースを収集できます。

  • 一般に、サードパーティ製のデバイスには、tcpdump (Linux/FreeBSD/Unix) や pktt (NetApp) などの付属するパケット キャプチャ ツールがあります。 たとえば、SMB クライアントまたは SMB サーバーが Unix ホストである場合は、次のコマンドを実行してデータを収集できます。

    # tcpdump -s0 -n -i any -w /tmp/$(hostname)-smbtrace.pcap

    データの収集を停止するには、キーボードの Ctrl + C キーを使用します。

問題の原因を見つけるには、CLI、SRV、またはその間のどこかで、両側のトレースを確認します。

Netshell を使用してデータを収集する

このセクションでは、netshell を使用してネットワーク トレースを収集する手順について説明します。

重要

Microsoft Message Analyzer ツールは廃止されました。ETL ファイルの分析には Wireshark をお勧めします。 以前にツールをダウンロードし、詳細を探している場合、「Message Analyzer のインストールとアップグレード」を参照してください。

Note

Netsh トレースでは ETL ファイルが作成されます。 ETL ファイルは、Message Analyzer (MA) とネットワーク モニター 3.4 (パーサーを [ネットワーク モニター パーサー] > [Windows] に設定)、Wireshark で開くことができます。

  1. SMB サーバーと SMB クライアントの両方で、C ドライブに Temp フォルダーを作成します。その後、次のコマンドを実行します。

    netsh trace start capture=yes report=yes scenario=NetConnection level=5 maxsize=1024 tracefile=c:\Temp\netTrace.etl

    PowerShell を使用している場合は、次のコマンドを実行します。

    New-NetEventSession -Name trace -LocalFilePath "C:\Temp\netTrace.etl" -MaxFileSize 1024

Add-NetEventPacketCaptureProvider -SessionName trace -TruncationLength 1500

Start-NetEventSession trace

  2. 問題を再現します。

  3. 次のコマンドを実行して、トレースを停止します。

    netsh trace stop

    PowerShell を使用している場合は、次のコマンドを実行します。

    Stop-NetEventSession trace  
Remove-NetEventSession trace

Note

転送されるデータは最小限の量だけトレースするようにしてください。 パフォーマンスの問題の場合は、状況が許すならば、常に良い場合のトレースと悪い場合のトレースの両方を取得します。

トラフィックを分析する

SMB は、TCP/IP をネットワーク トランスポート プロトコルとして使用するアプリケーションレベルのプロトコルです。 そのため、SMB の問題は TCP/IP の問題によって発生することもあります。

TCP/IP で次の問題が発生しているかどうかを確認します。

  1. TCP 3 ウェイ ハンドシェイクが終了しない。 通常、これはファイアウォールでブロックされているか、サーバー サービスが実行されていないことを示します。

  2. 再転送が発生している。 これによりファイル転送が遅くなることがあります。原因は複合 TCP 輻輳制御です。

  3. 5 回の再転送後に TCP リセットが行われた場合は、システム間の接続が失われたか、いずれかの SMB サービスがクラッシュしたか、応答を停止したことを意味します。

  4. TCP 受信ウィンドウが減少している。 これは、ストレージの処理が遅いか、WinSock 用補助機能ドライバー (AFD) のバッファーからのデータの取得を妨げる他の問題が原因で発生する場合があります。

TCP/IP に目立った問題がない場合は、SMB エラーを探します。 これを行うには、次の手順に従います。

  1. SMB エラーは、常に MS-SMB2 プロトコル仕様に対して確認してください。 SMB エラーの多くは良性です (害はありません)。 エラーが次のいずれかの問題に関連していると判断する前に、次の情報を参照して、SMB からエラーが返された理由を判別します。

    • MS-SMB2 メッセージ構文の記事では、各 SMB コマンドとそのオプションについて説明しています。

    • MS-SMB2 クライアント処理の記事では、SMB クライアントで要求を作成し、サーバー メッセージに応答する方法について説明しています。

    • MS-SMB2 サーバー処理の記事では、SMB サーバーで要求を作成し、クライアントの要求に応答する方法について説明しています。

  2. FSCTL_VALIDATE_NEGOTIATE_INFO (ネゴシエートの検証) コマンドの直後に、TCP リセット コマンドが送信されるかどうかを確認します。 送信される場合は、次の情報を参照してください。

    • クライアントまたはサーバーでネゴシエートの検証プロセスが失敗した場合は、SMB セッションを終了 (TCP リセット) する必要があります。

    • WAN オプティマイザーによって SMB ネゴシエート パケットが変更されているために、このプロセスが失敗する場合があります。

    • 接続が途中で終了した場合は、クライアントとサーバーの間の最後のやり取りの通信を特定します。

プロトコルを分析する

使用されたコマンドとオプションを正確に把握するには、ネットワーク トレースで実際の SMB プロトコルの詳細を確認します。

  • SMB では、実行するように指示されたことのみが実行されることに注意してください。

  • アプリケーションで実行しようとしている操作の詳細については、SMB コマンドで確認できます。

コマンドと動作をプロトコルの仕様と比較して、すべてが正しく動作していることを確認します。 正しくない場合は、その付近のデータまたは下位レベルのデータを収集して、根本原因に関する詳細情報を探します。 これを行うには、次の手順に従います。

  1. 標準のパケット キャプチャを収集します。

  2. netsh コマンドを実行して、ネットワーク スタックに問題があるかどうか、またはファイアウォールやウイルス対策プログラムなどの Windows フィルタリング プラットフォーム (WFP) アプリケーションで破棄があったかどうかに関する詳細情報を収集します。

  3. 他のすべてのオプションが失敗し、SMB 自体で問題が発生していると思われる場合、または他のどのデータも根本原因を特定するのに十分ではない場合は、t.cmd を収集します。

次に例を示します。

  • 1 つのファイル サーバーへのファイル転送の速度が低下しています。

  • 両側のトレースでは、READ 要求に対して SRV の応答が遅いことが示されています。

  • ウイルス対策プログラムを削除すると、低速なファイル転送が解決されます。

  • この問題を解決するには、ウイルス対策プログラムの製造元にお問い合わせください。

Note

必要に応じて、トラブルシューティング中にウイルス対策プログラムを一時的にアンインストールすることもできます。

イベント ログ

次のスクリーンショットに示すように、SMB クライアントと SMB サーバーの両方に詳細なイベント ログの構造があります。 問題の根本原因を見つけるには、イベント ログを収集します。

Event logs

ここでは、SMB 関連のシステム ファイルの一覧を示します。 システム ファイルを更新された状態に維持するには、最新の更新プログラムのロールアップがインストールされていることを確認します。

%windir%\system32\Drivers の下に示される SMB クライアントのバイナリ:

  • RDBSS.sys

  • MRXSMB.sys

  • MRXSMB10.sys

  • MRXSMB20.sys

  • MUP.sys

  • SMBdirect.sys

%windir%\system32\Drivers の下に示される SMB サーバーのバイナリ:

  • SRVNET.sys

  • SRV.sys

  • SRV2.sys

  • SMBdirect.sys

  • %windir%\system32 の下

  • srvsvc.dll

SMB components

更新の提案

SMB の問題をトラブルシューティングする前に、次のコンポーネントを更新することをお勧めします。

  • ファイル サーバーにはファイル ストレージが必要です。 ストレージに iSCSI コンポーネントがある場合は、それらのコンポーネントを更新します。

  • ネットワーク コンポーネントを更新します。

  • パフォーマンスと安定性を向上させるには、Windows Core を更新します。

関連項目

Microsoft SMB プロトコルのパケット交換シナリオ