小さなファイルは正常にコピーできるのに、大容量のSMB書き込みが失敗する原因は？
小さなファイルは正常にコピーできるのに、大容量のSMB書き込みが失敗する場合があります。これは、短時間のコピーでは到達しない経路、MTU、ストレージ割り当て、エンドポイントセキュリティの制限が、継続的な転送によって表面化するためです。
ZimaSpace NASでは、同じクライアントから同じ共有先へ、既知の大容量ファイル1つと小さなファイルをまとめたフォルダー1つを使用します。重要なのは、長時間の書き込み中だけ何が変化するかを特定することです。パケットサイズ、転送時間、事前割り当て、ウイルス対策スキャン、NASの空き容量処理、またはトランスポートのリセットなどを確認します。
失敗が継続的なSMBコピーに特有か確認する
同じNAS共有とネットワーク経路を維持したまま、別のSMBクライアントまたはコピー方法で大容量ファイルのコピーをもう一度実行します。
大容量SMBコピーが予想どおりに動作しなかった事例を扱う、エンジニアリングに焦点を当てたケーススタディブログは、基盤プロトコルの定義だけでなく同じ小さな問題を扱っているため、この切り分けに役立ちます。
1台のクライアントまたは1つのコピー方法だけが失敗する場合は、そのバッファリングとセキュリティスタックを調べます。すべての大容量書き込みがほぼ同じ時点で失敗する場合は、共有経路の確認に進みます。
長時間の通信でネットワークの不安定性が現れるか確認する
小さなファイルは、再送やトンネルの不安定性が明らかになる前に完了することがあります。一方、1つの継続的なSMBセッションは数分間その影響を受け続けます。
SMBが不安定なネットワーク環境の影響を受けやすいことを説明する、ファイル転送に焦点を当てた記事は、基盤プロトコルの定義だけでなく同じ小さな問題を扱っているため、この切り分けに役立ちます。
パケットロスのテストを並行して実行し、失敗時刻を比較します。安定したLANコピーは成功する一方で、ルーティング経由またはVPN経由のコピーが不安定になる場合は、NASストレージが原因ではない可能性があります。
ジャンボフレームまたはMTUの不一致をテストする
通常のpingが大きなフレームに対応していることを証明すると決めつけず、同じクライアントからNASへの経路上で、制御されたパケットサイズのテストを実行します。
ジャンボフレームにはエンドツーエンドの一貫性が必要であることを扱う、実践的なネットワークブログは、基盤プロトコルの定義だけでなく同じ小さな問題を扱っているため、この切り分けに役立ちます。
比較のため、すべてのエンドポイントを共通の1500 MTUに戻します。失敗がなくなった場合は、大きなフレームを再度有効にする前に、不一致のあるジャンボフレーム経路を修正します。
ファイルサイズとクライアントの動作を意図的に比較する
同じ共有先で異なるファイルサイズを使い、さらに2台目のクライアントでもテストして、症状をNAS全体の遅さと混同しないようにします。
異なるクライアントとファイルサイズをテストする方法を扱う、NASのトラブルシューティングに焦点を当てたブログは、基盤プロトコルの定義だけでなく同じ小さな問題を扱っているため、この切り分けに役立ちます。
失敗し始める最小ファイルサイズまたは経過時間を記録します。再現性のあるしきい値があれば、経路の通信時間、ファイル割り当て、ポリシー制限を切り分けやすくなります。
長時間のコピーをリセットするエンドポイントセキュリティを除外する
転送が中断した時点で、Windows Defender、サードパーティ製ウイルス対策ソフト、ファイアウォール、ランサムウェア対策、セキュリティログを確認します。
ウイルス対策ソフトとファイアウォールによる干渉を扱う、一般ユーザー向けのトラブルシューティング記事は、基盤プロトコルの定義だけでなく同じ小さな問題を扱っているため、この切り分けに役立ちます。
テスト用のファイルと共有先に限り、一時的な制御付き除外を使用します。コピー速度を向上させるためだけに、エンドポイント保護を恒久的に無効化しないでください。
SMBを原因と判断する前に経路MTUを証明する
経路上の低MTU区間が送信元に正しく通知できない場合、ルートは小さな通信を通過させながら、大きなパケットをひそかに破棄することがあります。
MTUの不一致が部分的な接続障害を引き起こす可能性を扱う、ネットワークトラブルシューティングガイドは、基盤プロトコルの定義だけでなく同じ小さな問題を扱っているため、この切り分けに役立ちます。
DFビットを設定したサイズテストを実行し、両方向から経路を比較します。SMB署名、クレジット、サーバーキャッシュの設定を調整する前に、ボトルネックとなるMTUを統一します。
実際のホームサーバー経路で再テストする
1つの変数を変更した後は、別の経路を使用する可能性がある別のテストに切り替えず、同じクライアントから同じNASまたはセルフホスト環境のワークフローを繰り返します。
関連するホームサーバーのネットワーク経路を扱うZimaSpaceのガイドは、最終確認を同じセルフホスト環境に結び付けるのに役立ちます。
再接続、サービスの再起動、そして2回目の制御された転送またはリクエストの後も、元の症状が解消された状態を維持できて初めて、修正は完了です。
よくある質問
大容量ファイルで失敗する場合、4GBのファイルサイズ制限があると証明できますか？
いいえ。再現性のあるサイズしきい値は、MTU、ストレージ割り当て、クライアントのセキュリティソフト、クォータ、長時間通信のリセットによっても発生します。
なぜ小さなファイルは問題なく動作するのですか？
経路上でパケットロスが蓄積する前、バッファーがいっぱいになる前、クォータの境界に達する前、または長時間のセキュリティスキャンが開始される前に完了する可能性があるためです。
テストのためにSMB署名を無効にすべきですか？
最初の手順としては推奨しません。まずネットワークとストレージの動作を切り分け、署名がボトルネックである証拠がない限り、SMBのセキュリティを弱めないでください。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
