要点:この解決済みのケースではNTFSが根本原因でしたが、すべての移行失敗を説明できるわけではありません
再現テストでは、ZimaOSは途中までデータをコピーした後、NTFSの移行先で最終的な権限コピーの段階を完了できずに失敗しました。移行先をEXT4で再フォーマットすると、その移行は成功しました。その後の返信では別の構成でも失敗が報告されているため、「すべてをEXT4でフォーマットする」ことはケース固有の対処であり、有用な事前確認ではあるものの、万能な解決策ではありません。

現在の移行は、サポート対象のデータ移行ツールから開始してください



現在のZimaOSデータ移行ガイドでは、Dockerイメージ、Dockerアプリケーションデータ、ユーザーフォルダーをカテゴリー別に移動します。ZimaOS移行パスガイドは、実際に何が移動されるのかを判断するための、現時点で最適な補足資料です。
開始ボタンを押す前に移行先のファイルシステムを確認する
lsblk -f
blkid
移行先のデバイス、ファイルシステムの種類、空き容量、マウント状態を確認してください。移行先がLinuxの所有権や権限の扱いが異なるファイルシステムの場合、アプリデータの移行は単純なドラッグ&ドロップによるコピーよりも影響を受けやすくなります。lsblkのマニュアルとext4のドキュメントは、確認に役立つ参考資料です。
移行中に「Dockerを停止」と表示される理由
これは想定された動作であり、失敗そのものではありません。コンテナがデータに書き込み続けている状態では、アプリデータを安全に移動できません。移行ワークフローではDockerを一時停止し、管理対象のデータをコピーして保存場所を更新した後、サービスを再開します。


EXT4でも移行に失敗する場合
すぐに再フォーマットしないでください。移行元と移行先のファイルシステム、空き容量、移行カテゴリー、ZimaOSのバージョン、移行先が単一ディスクかRAIDかを記録してください。可能であれば、小規模なカテゴリーで再現を試みます。Zimaで作成したストレージでも後から失敗したという事実は、ファイルシステムの種類が判断材料の一つにすぎないことを示しています。
破壊的な再試行を行う前に、ZimaOSバックアップワークフローで重要なデータを保護してください。
