結論：この失敗パターンは、ファイルの欠落ではなく同一サーバー内のSMBコピーオフロードに一致します
コピーは開始され、ほぼ100%まで進んだ後、エクスプローラーが再試行し、項目が見つからなくなったと報告します。一方、ZimaOSの「ファイル」内では同じデータを移動できます。この組み合わせは、コピー元のファイルが消えたのではなく、同一サーバー上の2つの共有間におけるSMB転送経路に問題があることを示しています。
Windowsが同一サーバー内のSMBコピーを別の方法で処理する理由
コピー元とコピー先が同じSMBサーバー上にある場合、Windowsはサーバー側コピーを要求できます。Microsoftはこの仕組みをFSCTL_SRV_COPYCHUNKとして説明しています。この経路が正しく処理されない場合、各共有への通常の読み取り・書き込みが機能していても、エクスプローラーでコピーに失敗することがあります。
エクスプローラーの同一サーバー最適化に依存しない転送経路を使う
実用的な方法は次の3つです。
- ZimaOSの「ファイル」アプリでファイルを移動またはコピーする。
- 共有AからPCへコピーし、その後PCから共有Bへコピーする。
robocopyを使用し、コピー先を確認する。
Microsoftは、robocopyのリファレンスで再試行とコピーの動作を説明しています。
すぐに権限の問題だと決めつけない
両方の共有で個別にファイルを作成、編集、削除できる場合、基本的な認証情報が最初の障害箇所である可能性は低いでしょう。一方の共有が読み取り専用である場合や、認証情報が正しくない場合は、最新のZimaOS SMBヘルプドキュメントを参照してください。
主張できることと、できないこと
このコミュニティ事例は、サーバー側コピーの互換性問題と強く一致します。ただし、現在公開されているZimaOSマニュアルでは、共有間のCOPYCHUNK動作がサポート対象として保証されていることは説明されていません。このパターンは、恒久的なプラットフォーム上の問題というより、診断を簡略化する手がかりとして扱ってください。
通常の共有設定については、NAS 101ファイル共有ガイドと、認証済みZimaOS SMBの例を参照してください。
