ZimaOSのDockerが起動しない：移行後に空き容量がない

ZimaOSのデータ移行後にDockerが起動を拒否した場合、ログの最後の行は誤解を招くことがあります。この2026年2月の事例では、Dockerは最終的にoverlay2ストレージドライバーがサポートされていないと報告しました。数行前まで読むと、真の障害が明らかになります。システムディスクにデバイス上の空き容量がありませんだったため、Dockerは一時ファイルを作成したり、overlayストレージをテストしたりできませんでした。

ユーザーは180 GBのZimaOS SSDを使用しており、増え続けるImmichのデータベースを誤ってそこに残していました。移行を試みた時点では、正常に移動するための空き容量が不足していました。何度か試行し、ログを手動で削除した後、AppDataは移行されたように見えましたが、システムディスクはなお100%に達し、再起動後にDockerを初期化できなくなりました。

Immichが小容量のシステムSSDを移行前にいっぱいにした

このユーザーは、データベースをシステムドライブから移動せずにImmichをインストールしました。写真関連のスタックが大きくなるにつれてディスクがいっぱいになり、ZimaOSがエラーを報告し始めました。

これは現在のIceWhaleの案内とも一致します。写真ライブラリ、メディアメタデータ、ドキュメントのインデックス、データベース、キャッシュは急速に増大する可能性があるため、アプリケーションデータは小容量のシステムディスクではなく、メインストレージに配置すべきです。

移行自体にも作業領域が必要だった

ユーザーがZimaOSの移行ワークフローを試したのは、システムディスクがすでに深刻な容量不足に陥った後でした。最初の移行が失敗したのは、処理を一時的に保存するための空き容量が不足していたためだと述べています。

これは重要な運用上の教訓です。Dockerや移行サービスが作業領域不足に陥ってからではなく、システムディスクの空き容量が数GBになる前にAppDataを移動してください。

Dockerソケットのメッセージは単なる症状にすぎなかった

アプリケーションから次の報告がありました。

unix:///var/run/docker.sock のDockerデーモンに接続できません。
Dockerデーモンは実行されていますか？

このメッセージは、Dockerデーモンを利用できないことを意味します。デーモンが失敗した理由までは特定できません。

ジャーナルが真の根本原因を明らかにした

重要な行は次のとおりです。

デバイスに空き容量がありません
デフォルトのAppArmorプロファイルの読み込みに失敗しました
mkdir /var/lib/docker/overlay2/check-overlayfs-support...: no space left on device
failed to start daemon: error initializing graphdriver

Docker が最初に失敗したのは、一時データを書き込めなかったためです。その後、 ドライバーがサポートされていない このメッセージは、ストレージドライバーの初期化に失敗した結果であり、移行後に実行中のカーネルが突然 overlay2 のサポートを失ったことを示すものではありません。

Docker の再起動で解決しなかった理由

ユーザーは再起動を試みました docker.service そして docker.socket 手動で再起動しようとしたところ、「アクセスが拒否されました」と表示されました。コミュニティからの返信では、これを ZimaOS のアプライアンス型サービス制御と関連付けました。

サービスの再起動が許可されていたとしても、空きディスク容量が増えるわけではありません。デーモンは再び同じ書き込みエラーに遭遇するだけです。

Docker の一時ファイルを削除しても、十分な空き容量は回復しなかった

コミュニティは、まずディスク容量を確認してから Docker の一時ファイルを削除するよう提案しました。元のユーザーはそれを試しましたが、システムドライブは依然として 100% 使用中で、Docker も起動しないと返信しました。

この結果は有用です。小規模な一時ファイルのクリーンアップでは、システムディスクが完全に圧迫されたままのストレージ設計を修復できないことが示されています。

ユーザーはバックアップと工場出荷時の復元を選択した

クリーンアップを試みても失敗した後、ユーザーはバックアップを取ることにしました。 /DATA/AppData ZimaOS を再インストール／復元する。コミュニティの回答者は、インストール済みアプリを記録し、工場出荷時のシステム復元を実行してから、アプリ関連のストレージを大容量ディスクへ移行してからアプリを再インストールするよう勧めました。

公開スレッドは、ユーザーがそうすると述べたところで終わっています。復元後の確認に関する投稿はないため、このページでは、このユーザーに対する具体的な最終解決策として再インストールが検証済みであるかのように表示すべきではありません。

現在の ZimaOS データ移行では、移動可能なデータがより明確になっています

現在の ZimaOS では、次の移行カテゴリが個別に用意されています。

Docker イメージ；
Docker アプリケーションデータ；
Gallery、Downloads、Documents、Media、Backup などのユーザーデータベース。

これは、以前のスレッドに対する重要な更新です。以前の議論では、「AppData の移行」がすべての Docker ストレージを自動的に対象とするかのように扱われることがありました。

小容量のシステムディスクが深刻な容量不足になる前に、現在のZimaOSのデータ移行カテゴリを使用してください。

早い段階でアプリデータの保存場所を設定して問題を防ぐ

現在のZimaOSでは、設定 > アプリからアプリデータの保存場所も指定できます。IceWhaleは、永続的に増加するアプリデータをすべてシステムデバイスに置いたままにせず、最初からストレージアレイを指定することを推奨しています。

ZimaOSアプリが永続データを保存する場所についての現在の説明が、最適な予防策の参考資料です。

容量とinodeの両方を確認する

ファイルシステムは、空きブロックがない場合やinodeを使い果たした場合に、新しいファイルを拒否することがあります。元のトラブルシューティングでは、両方を確認するよう提案されていました。今回のログは通常の容量不足を強く示していますが、両方の値を確認することは、読み取り専用の診断として依然として有用です。

再インストールが妥当になる場合

システムディスクの使用率が100%になり、Dockerのストレージメタデータが破損し、デーモンを起動できず、安全なクリーンアップでも十分な作業領域を確保できない場合は、Dockerのoverlayメタデータを手動で編集するよりも、管理されたシステム復元のほうが迅速かつ安全です。

まずAppDataとユーザーデータを保護し、復元によってどのディスクが影響を受けるかを確認して、アプリケーションデータベースの唯一のコピーを削除しないようにしてください。

Docker移行後のよくある質問

元のハードウェアでは、overlay2が実際にサポートされていなかったのでしょうか？

ログにはまず、ディスクがいっぱいだったためDockerがoverlay2のテストファイルを作成できなかったことが示されています。その失敗に続いて、ドライバーのメッセージが表示されました。

Dockerのtmpを削除すると、元のシステムは復旧しましたか？

いいえ。投稿者は、OSドライブの使用率が100%のままだったと述べています。

現在のZimaOSでは、AppDataとは別にDockerイメージを移動できますか？

はい。現在のデータ移行では、DockerイメージとDockerアプリケーションデータが別々の移動可能なカテゴリとして表示されます。

スレッドでは、工場出荷時設定への復元が成功したことを確認できましたか？

いいえ。ユーザーは実行すると述べましたが、公開スレッドは復元後の結果が投稿される前に終わっています。