このスレッドは、消去法による診断の好例です。最初は、最後の数パーセントで失敗するWindowsのコピーが、SMBまたはRAIDへの書き込みの問題に見えました。コミュニティはRAIDの健全性、SMART、カーネルログ、Robocopy、MTUを確認しました。ユーザーは異なるディスクを使ってNASを新しいRAID5アレイとして再構築までしましたが、それでも同じWindows PCから同じファイルのコピーに失敗しました。
決定的なテストは後に行われました。同じファイルを、別のWindowsマシンから同じZimaOS共有へ正常にコピーできたのです。これにより、問題の発生源はZimaOSのストレージアレイではなく、元のRyzen搭載Windows 11クライアントまたはそのネットワークスタック／ドライバ経路にあると切り分けられます。クライアント側での正確な修復方法は、結局確立されませんでした。
ExplorerとRobocopyは99.9%近くで失敗しました
影響を受けたファイルはテレビ録画でした .ts ファイルはテレビ録画でした。Windows Explorerは終盤近くで失敗し、Robocopyでも同じ挙動が次のように再現されました。
ERROR 665 / 0x00000299したがって、別のコピー ツールを使っても、元の問題は解決しませんでした。
SMARTとRAIDのチェックではディスク故障は確認されませんでした
投稿されたSMARTのスクリーンショットでは、確認したドライブの保留セクター、再割り当てセクター、訂正不能セクターはいずれもゼロでした。また、RAIDは [UUUU].
別のディスクで完全に新しいRAIDを構築しても、同じPCからのコピーは失敗しました
Didierは、3 TBドライブ4台を使ってRAID5としてシステムを再構築しました。それでも同じ転送問題が残りました。これは、元の1 TBディスクまたは特定のアレイが原因である可能性を強く否定する証拠です。
同じファイルは別のWindows PCから正常に動作しました
元の投稿者は後に、同じ内容を別のマシンからテストし、正常にコピーできたと報告しました。3月には、別のWindows 11 Pro PCから同じ実験を繰り返し、再び成功しました。
これはスレッド全体で最も有力な切り分けテストです。
すべての環境でMTUはすでに1500でした
コミュニティは、ジャンボフレームの不一致を除外するよう提案しました。ユーザーはすべてのデバイスがMTU 1500であることを確認したため、片方のリンクだけがジャンボフレームを使用し、もう片方が使用していないことが原因ではありませんでした。
SMB1はすでに無効でした
別のテストでは、古いSMBプロトコルが関係している可能性を確認しました。ユーザーは、SMB1がすでに無効になっていると報告しました。これは、最新のWindows/ZimaOSネットワークでは適切な設定です。
サーバーログは確認する価値がありましたが、PC間テストのほうが決定的でした
コミュニティは、障害発生直後に読み取り専用のZimaOSログを求めました。
dmesg -T | tail -200
journalctl -n 200 --no-pagerこれらによって、リセットやタイムアウトが明らかになる可能性があります。しかし、他のPCでは同じファイルを同じNASへ正常にコピーできたため、元のWindowsクライアントが最も優先してトラブルシューティングすべき箇所となりました。
問題のあるWindows PCで確認すべき項目
- NICドライバーとファームウェア。
- NICの高度なオフロード／省電力設定。
- VPN／フィルター／セキュリティソフトウェア。
- Windowsネットワークスタックの破損。
- 特定のEthernet／Wi-Fiアダプターとケーブル／経路。
- 制御されたテストとして、クリーンブートまたは別のNICを試す。
コミュニティでは、完全なWindows再インストールが最も確実なリセット方法として提案されましたが、ソースのユーザーは実行したことも、正確な原因ドライバーを特定したことも確認していません。
.tsファイル拡張子が根本原因ではない
元のPCからは一部のトランスポートストリーム録画だけが失敗したため、当初はファイル形式が怪しいように見えました。しかし、まったく同じファイルを別のWindowsマシンからは正常にコピーできました。これにより、ZimaOSが単に .ts ファイル。
Windowsを再インストールする前に別のネットワークアダプターを試す
最終的な証拠が1台のPCを指しているため、リスクの低い次のテストとして、同じWindowsインストール環境とファイルを維持したまま、別のEthernetアダプター、Wi-Fiインターフェース、USB NIC、ケーブル、またはスイッチポートを使ってみる方法があります。転送に成功すれば、ワークステーション全体を再構築せずに、問題を元のNIC／ドライバ経路に絞り込めます。
サードパーティ製ネットワークフィルターを一時的に切り分ける
VPNクライアント、エンドポイントセキュリティ、トラフィックシェーパー、仮想スイッチ、パケットキャプチャードライバー、マザーボードのネットワークユーティリティは、Windowsのネットワークスタックにフィルタードライバーを挿入することがあります。クリーンブート、または制御された無効化／アンインストールテストによって、この層を特定できます。
SMBを動作させるためだけにエンドポイントセキュリティを恒久的に無効化しないでください。目的は診断です。
ソース側の「ディスク上のサイズ」の差異は、不完全な転送と一致していた
その後、ユーザーはネットワーク経由でコピーしたファイルの容量が元のファイルより小さいことに気付きました。問題のPCではコピーが最終段階で何度も停止していたため、転送先のファイルが小さい、または不完全になるのは当然であり、それだけでZimaOSがファイルを圧縮または破損させたことを示すものではありません。
Windowsの完全な再インストールは提案されたが、実証はされていない
コミュニティでは、原因不明のクライアント側ネットワーク問題をリセットする最も確実な方法として、OSのクリーン再インストールが挙げられました。元の投稿者は完全なクリーンインストールを実行したとは報告していないため、これはソースで確認された解決策ではなく、最後の手段として扱うべきです。
SMBコピーエラーに関するFAQ
ソースによって、ZimaOSのRAIDが破損していることが証明されましたか？
いいえ。RAID／SMARTは正常で、異なるディスクを使った新しいアレイでも同じ症状が発生し、他のPCでは同じファイルを正常にコピーできました。
Robocopyで問題は解決しましたか？
いいえ。Robocopyでも約99.9%の時点で ERROR 665 が再現しました。
最終的な証拠から何が原因として切り分けられましたか？
元の Windows 11 Ryzen PC、またはそのネットワーク／クライアントスタック。ただし、クライアント側の正確な解決策は未解決のままでした。
