到達可能なホームサーバーでも、SMB自体がブロックされている、停止している、誤ってバインドされている、過負荷になっている、または失敗したセッションに固まっている場合、ファイル共有でタイムアウトすることがあります。
PingはサーバーがICMPに応答することを証明するだけであり、TCP 445がSMBリスナーに到達しているか、クライアントがサポートされているプロトコルを交渉しているか、共有が認証および列挙できるかを証明するものではありません。最速の診断はレイヤーを上に向かって進めます:IP到達性、ホスト名の解決、ポート445、SMBサービスの状態、共有パス、認証情報、そして最後にタイムアウト時のサーバー負荷です。
サーバーのIPと共有名を比較する
同じクライアントからサーバーの現在のIPアドレスと通常のホスト名で共有をテストします。両方がタイムアウトするか、名前だけが失敗するか、名前が異なるIPv4またはIPv6アドレスに解決されるかを記録します。
OSMCのサポートケースでは、ホストにpingは通るがSMBパスが接続タイムアウトを返す例がありました。この区別により、成功したpingがDNS、ポート、サービスの問題を早期にクリアしないようにします。
IPが機能し名前が失敗する場合は、DNS、マルチキャスト検出、サフィックス、またはキャッシュされたアドレスを修正します。両方が同じように失敗する場合は、名前キャッシュを繰り返しクリアするのではなく、TCP 445とSMBリスナーの調査を続けます。
失敗しているクライアントからTCPポート445をテストする
タイムアウトが発生している同じデバイスからサーバーのポート445へのTCP接続テストを開きます。NASを再起動したりクライアントを再接続した後ではなく、失敗中に実行してください。
Ask Ubuntuの診断では、pingが通るがSambaが失敗するケースをポート445が到達可能かどうかを確認することで分離しました。現代のネットワーク上のSMBは、他のサーバーサービスが利用可能でもこのTCP経路に依存します。
ポート445がタイムアウトする場合は、クライアントVLAN、ホストファイアウォール、NASファイアウォール、インターフェースバインディング、中間ACLを調査します。すぐに接続できる場合はネットワーク経路が開いているため、診断はSMBの交渉、セッション、認証情報、共有状態に進みます。
SMBサービスが正しいインターフェースでリッスンしていることを確認する
サーバー上のSMBサービスの状態とアクティブなリスナーを確認します。クライアントが使用するLANまたはVLANアドレスにバインドされていることを確認し、ループバック、別のNIC、コンテナブリッジ、古いアドレスのみにバインドされていないかをチェックします。
NAS全体の再起動は停止または固まったサービスを一時的に隠すことがあります。サービスログ、リスナー出力、最近の設定変更を再起動前に確認し、失敗の証拠を保持することを優先してください。
サービスが停止している場合は、なぜ終了したかを調査し、共有設定を検証してから再起動します。誤ったインターフェースでリッスンしている場合はバインディングを修正し、関連しないファイアウォールルールを変更せずにクライアントから再テストします。
プロトコル交渉と認証を分離する
交渉された方言とエラーコードを報告するSMBクライアントを使用します。サーバールートのブラウズと直接の共有パスを比較してください。発見、列挙、認証、既知の共有のオープンは別々の操作だからです。
Synologyコミュニティの報告では、ホスト名とアドレスは到達可能でもIPv4およびIPv6でSMBポート445が失敗したNASが説明されました。
TCP接続が開くが交渉が失敗する場合は、SMBバージョン、署名、暗号化、クライアント互換性を比較します。交渉が成功し認証がハングまたは失敗する場合は、関連する保存済み認証情報のみをクリアし、アカウント、共有ACL、ロックアウト状態を確認します。
動作中の設定を削除せずに古いセッションをクリアする
失敗しているクライアントから既存のマップドライブとアクティブなSMBセッションを切断し、1つの明示的なサーバーアドレスとアカウントで再接続します。古いセッションは古いアドレス、認証情報、方言、切断されたトランスポートを保持することがあります。
同時にサーバーのセッションテーブルを確認します。クライアントがタイムアウトしている間にセッションが確立されたままの場合、半開TCP接続、スリープ中のクライアント、VPN経路の変更、またはSMB状態を正常にリセットしなかったインターフェースフェイルオーバーを示すことがあります。
すべてのユーザーのSMBサービスを再起動する前に個別のクライアントセッションをクリアします。新しいセッションでタイムアウトが再発する場合は、セッションのクリーンアップを最終的な解決策とせず、サーバー負荷とネットワーク動作の調査を続けます。
サーバー負荷を監視しながらタイムアウトを再現する
共有のオープンとリスト中にCPU、メモリ圧力、ディスク遅延、プールの健全性、ネットワークキュー、コンテナ活動、ウイルススキャン、インデックス作成、スナップショット作業を監視します。サーバーはpingに応答しても、SMBワーカーやストレージパスが十分に長く待機してタイムアウトすることがあります。
ZimaSpaceの過負荷NASサービスパスのガイドは、ポートとプロトコルのテスト成功後に隣接するパフォーマンスチェックを提供します。
問題は、同じクライアントが接続、認証、フォルダのリスト、読み書き、切断、再接続を失敗ウィンドウ中に行えるようになって初めて解決されます。ポート445が開いたままでサーバーが飽和しているのにSMBがタイムアウトする場合は、クライアントのタイムアウトを長くするのではなく、リソースまたはストレージのボトルネックを修正してください。
サポートとヒント
もっと読む

How to Reduce Plex Database Contention on a Busy Docker Host
A Plex configuration guide for busy hosts that treats the database as local application state and reduces I/O contention without inventing a shared DB...

How to Prevent Duplicate Plex Scans and Imports
A prevention guide for duplicate Plex scans and imports that removes overlapping triggers instead of disabling library updates entirely.

How to Recover Plex After Its App-Data Volume Fills Up
A recovery ladder for full Plex app-data volumes that protects the database first and avoids deleting unknown files just to make the service start.

