この情報源では、一見似ているImmichの障害がいくつか扱われていますが、すべてに当てはまる解決策が1つあるわけではありません。元の投稿者では、グレー表示になったImmichアプリがsudo systemctl restart dockerを実行するとすぐに復旧しました。一方、別のユーザーは同じコマンドを試してもImmichを起動できませんでした。その後に表示されたエラーでは、ホストポート2283はすでに割り当て済みであることが示されており、これはDockerデーモンが停止している場合とは異なる問題です。
重要な教訓はこの違いです。OSのアップデート後は、まずDocker自体に問題があるのか、1つのComposeプロジェクトだけに問題があるのか、それとも古いコンテナや重複したコンテナがImmichに必要なポートをすでに使用しているのかを確認してください。
まずDockerサービスの状態を確認する
777-Spiderは、Dockerが正常に動作しているか確認するよう最初に勧めました。その後、元の投稿者はDockerを再起動し、すべて再び動作したと報告しました。
Dockerを再起動するとホスト上のすべてのコンテナに影響するため、意図的に実行し、他のアプリケーションも再起動されることを想定してください。
Dockerの再起動は、すべてのImmich障害に効くわけではない
Chrisは、同じDockerの再起動で他のアプリは改善したものの、Immichは復旧しなかったと報告しました。これは、systemctl restart dockerを確実な解決策として扱うべきではないことを直接示しています。
ある情報源のエラーでは、ポート2283がすでに割り当て済みと明示されていた
現在の環境で同様の問題が起きた場合は、何かを削除したり再作成したりする前に、2283を使用しているコンテナまたはプロセスを特定してください。古いImmichコンテナが重複していたり、Composeプロジェクトが途中まで再作成されていたりすると、ポートが使用中のままになることがあります。
Composeアプリの起動失敗は、アプリケーションスタックのエラー
Docker上でPaperlessなどの他のアプリが正常に動作しているのにImmichだけがComposeエラーで失敗する場合は、OS全体を再インストールするのではなく、Immichのサービス状態やログ、現在のCompose定義を確認してください。
再インストールで解決したユーザーもいたが、時間とデータの再コピーが必要だった
Chrisは最終的にImmichを再インストールし、写真を再度コピーしました。また、バックアップの重要性を明確に警告しています。これは最後の手段としてのユーザー判断であり、全員に確認された解決策ではありません。
再インストール前にImmichのAppDataとデータベースを保護する
Immichの状態は写真フォルダーだけで構成されているわけではありません。コンテナやボリュームを削除する前に、データベース、アプリケーション設定、ライブラリのパスを保護してください。現在のZimaOSでは、重要なアプリデータは使い捨てのコンテナの外部に保持されています。
現在のZimaOSの永続アプリデータモデルを使用してください。
これを現在の1.7.1版Immichの回帰障害として扱わない
この情報源は、ZimaOS 1.5.4と旧世代のImmichに関するものです。現在のZimaOSとImmich v3は大幅に新しくなっているため、2026年向けの回避策を適用する前に、現在発生している正確なエラーを再現してください。
データベースの移行後にImmichを以前のバージョンへ戻すのは危険な場合がある
情報源に登場するユーザーの1人は、Immichを以前のバージョンに戻したと述べています。現在のメジャーバージョンアップグレードでは、データベースやアプリケーションの状態が移行される可能性があります。そのため、単にイメージタグを以前のものに変更するのではなく、該当するImmichリリースのガイダンスに従ってダウングレードをサポートする必要があります。
ポート競合では、既存のリスナーを特定する必要がある
情報源のエラーには、ポートがすでに割り当てられているため、Dockerがホストポート2283をバインドできなかったと明記されています。古いImmichコンテナがまだ実行中である、別のスタックが同じポートを使用している、または別のサービスがそのポートに割り当てられている場合に起こります。
何かを削除する前に、現在そのポートを使用しているコンテナまたはリスナーを特定し、どのスタックがそのポートを所有すべきかを決めてください。
グレー表示されたアプリタイルは、Immichのデータ損失ではなくDockerの状態を示す症状の場合がある
元の投稿者の場合、Dockerを再起動するとすべてのアプリが復旧しました。つまり、Immichがグレー表示になった原因はコンテナランタイム側にあり、写真データベースやライブラリが消去された証拠ではありません。
別の参加者は同じ再起動を行ってもImmichを復旧できませんでした。これは、UI上の症状だけでは根本原因を診断できないことを示しています。
再インストール前にComposeの失敗内容を確認する
「Composeアプリの起動に失敗しました」はラッパーエラーです。役立つ情報は、基盤となるサービスやコンテナのメッセージにあります。たとえば、ポートの競合、ボリュームの欠落、データベースのヘルスチェック失敗、イメージの取得失敗、無効なYAML、権限の問題などです。
スタックを再作成する前に、失敗時のログを保存してください。再インストールすると証拠が消える可能性があります。
現在のImmich v3では、無計画なロールバックはより危険
Immichはその後、スキーマやデプロイ方法に大きな変更を伴うメジャーアップデートを重ねています。2026年にあるユーザーがv1.xリリースをロールバックしたからといって、現代のv3データベースを任意の古いイメージで安全に実行できるとは限りません。
現在のImmichの移行・ロールバックガイダンスに従い、メジャーバージョンを変更する前に、検証済みのデータベースとライブラリのバックアップを保持してください。
再インストールが必要な場合は、まず永続パスを保護する
写真ライブラリ、PostgreSQLデータ、設定、機械学習・キャッシュのパス、現在のボリュームマッピングを記録してください。使い捨てのコンテナを削除することと、ホスト上の永続フォルダーを削除することはまったく別です。
正常なクリーンインストールでは、意図した永続データを再接続するか、サポートされたバックアップ経路から復元します。唯一の写真ライブラリを最初から再コピーする必要が生じる状態にしてはいけません。
Immich 1.5.4の障害に関するFAQ
Dockerの再起動で、元の投稿者のImmichは復旧しましたか？
はい。
スレッド内のすべてのユーザーで復旧しましたか？
いいえ。別のユーザーではImmichが引き続き失敗し、後にポート2283の競合が表示されました。
現在のユーザーはすぐにImmichを再インストールすべきですか？
いいえ。まずDockerサービスの状態、Composeの状態、ポートの使用者、永続データを確認してください。
