このソースには、短い間隔で発生した複数の障害が含まれているため、単純な「Portainerのバグ」として書き換えるべきではありません。システムドライブの空き容量がほとんどなく、Debian経由でDockerとcontainerdがメジャーな新バージョンへアップグレードされ、古いDocker CLIによるテストはDocker 29デーモンに拒否され、PortainerではLocal環境が失われ、CasaOSでは「アプリを読み込み中」が表示され続け、さらに後の起動問題によってダッシュボードがほぼ新規インストール時のように見える状態になりました。
ソース内のどの返信も、最終的な根本原因を1つに確定していません。最も安全な解釈は、複数の層にまたがる復旧問題だということです。まず既存データを保護し、その後、どのブート/rootファイルシステムがアクティブなのか、Dockerのデータルートがまだ存在するのか、デーモンが正常か、そしてPortainer/CasaOSがアップグレード後のDocker APIと互換性があるかを確認する必要があります。
システムディスクはすでに深刻な容量不足だった
クリーンアップ前、27 GBのrootファイルシステムの空き容量は約1 GBしかありませんでした。大きな容量を使用していたものには、Dockerのoverlayデータ、Jellyfinのメタデータ、システムログ、開発用パッケージなどが含まれていました。
空き容量が少ないと、Dockerのイメージやコンテナ操作、データベース、ログ、CasaOSのサービスが予測不能な動作をすることがあります。そのため、後に発生したDocker APIの問題とは無関係に、空き容量の確保は必要でした。
ホストのアップグレードにより、Dockerは28.xから29.0.0へ変更された
Debianのパッケージ履歴には、以下のアップグレードが示されていました。
-
docker-ce; -
docker-ce-cli; -
containerd.io; - Dockerのrootless用追加パッケージ。
Docker Engineのメジャーアップグレードによって、古いAPIクライアントを組み込んでいる、またはそれを使って通信をネゴシエートする管理ツールとの互換性問題が表面化することがあります。
ソースには、実際のDocker APIバージョン不一致が記録されている
Docker 24.0.5のCLIコンテナは、次のエラーを返しました。
client version 1.43 is too old.
Minimum supported API version is 1.44このメッセージは、少なくとも1つの古いクライアントが、アップグレードされたDockerデーモンと通信できなくなったことを直接示しています。これだけでPortainerがまったく同じクライアントバージョンを使用していたと証明できるわけではありませんが、API互換性を最優先で確認すべき根拠になります。
Localが起動中と表示された後に消えたのは、管理層の症状である
ソースでは、/var/run/docker.sockを使用するローカルDocker環境を再作成しようとしましたが、成功しませんでした。Portainerの状態を削除する前に、次を確認してください。
docker info
docker ps
ls -l /var/run/docker.sockDocker CLI自体が動作するのにPortainerが動作しない場合は、Portainerのバージョン、API、ソケットへのアクセスに注目してください。Docker自体が失敗している場合は、まずデーモンを修復します。
CasaOSで「アプリを読み込み中」と表示されるのは、問題がPortainerだけにとどまらないことを示している
CasaOSでもアプリの一覧取得に問題が発生していました。これは、Dockerが利用できない場合、Docker APIが互換性のない形で変更された場合、Dockerのデータルートが存在しない場合、または起動したホストが本来想定されていたシステム状態ではない場合に起こりえます。
後から発生した「適切なブートデバイスを選択してください」という事象により、復旧の優先順位が変わる
再起動後、ユーザーがブート選択を変更するまで、マシンは正常に起動しませんでした。復旧後、容量の大きいHDDは接続されたままだったにもかかわらず、CasaOSにはアプリが表示されませんでした。
これは、別のブートディスク/rootファイルシステムが選択された可能性、またはシステムパーティションや状態が変わった可能性を示しています。ただし、ソースだけではどちらなのかは証明できません。
CasaOSを再インストールする前にAppDataを保護する
ユーザーが特に重視していたのは次のデータです。
-
/home/casaosのプロジェクトファイル; - AppData内のJellyfinメタデータ;
- HDD上のメディアファイル;
- 復旧可能なDocker/CasaOSの設定。
Dockerを再インストールまたはリセットする前に、これらの永続データ用フォルダーを別のディスクやシステムへコピーしてください。通常、コンテナの再作成は、アプリケーションのデータベースやメタデータを再作成するより簡単です。
まだ参照されているものを把握するまで、Dockerを無差別にpruneしない
イメージのpruneによって空き容量を確保できますが、ボリュームやデータルートのディレクトリを削除すると、保存しようとしているアプリケーションの状態が失われる可能性があります。まず、コンテナ、ボリューム、バインドマウント、AppDataのパスを特定してください。
DebianとDockerのアップデートをCasaOSプラットフォームの一部として扱う
CasaOSは、基盤となるLinuxホストの上で動作します。広範なapt upgradeによって、CasaOSが依存するDocker、カーネル、systemd、ネットワーク、ストレージ関連のパッケージが更新されることがあります。動作中のNASに適用する前に、ホストのメジャーアップグレードは慎重にテストし、システムとアプリケーションのバックアップを保持してください。
Portainer/CasaOS復旧に関するFAQ
ソースは、すべての障害の原因がDocker 29だけだと証明していますか?
いいえ。システムはほぼ満杯で、後からブートデバイスまたはシステム状態に関する問題も発生しています。
Docker APIの不一致は確認されていますか?
はい。API 1.43を使用するDocker 24 CLIは、Docker 29デーモンが1.44以上を要求したため拒否されました。
AppDataをコピーする前にCasaOSを再インストールすべきですか?
いいえ。ディスクにアクセスできる場合は、まず重要なAppData、ホームディレクトリのファイル、メディアを保護してください。
