This source contains several superficially similar Immich failures but not one universal fix. The original poster's greyed Immich app recovered immediately after sudo systemctl restart docker. Another user tried the same command and still could not start Immich. Their later error showed host port 2283 was already allocated, which is a different problem from a dead Docker daemon.
That distinction is the key lesson: after an OS update, first determine whether Docker itself is unhealthy, only one Compose project is unhealthy, or a stale/duplicate container already owns the port Immich needs.
Check Docker Service Health First
777-Spider's first recommendation was to check whether Docker was running properly. The original poster then restarted Docker and reported that everything worked again.
Restarting Docker affects every container on the host, so use it deliberately and expect other applications to restart.
Docker Restart Was Not a Universal Immich Fix
Chris reported that the same Docker restart helped other apps but did not restore Immich. This is direct evidence against turning systemctl restart docker into a guaranteed fix.
One Source Error Explicitly Showed Port 2283 Already Allocated
For a current equivalent, identify which container/process owns 2283 before deleting or recreating anything. Duplicate old Immich containers or a partially recreated Compose project can leave a port occupied.
Failed to Start Compose App Is an Application-Stack Error
If Docker runs Paperless or other apps normally but Immich fails with a Compose error, inspect the Immich service statuses/logs and its current Compose definition rather than reinstalling the whole OS.
Reinstall Helped One User but Cost Time and Data Re-Copy
Chris eventually reinstalled Immich and copied photos back. They explicitly warned about backups. That was a last-resort user decision, not the confirmed fix for everyone.
Preserve Immich AppData and Database Before Reinstalling
Immich state is not just the photo folder. Preserve the database, application configuration and library paths before deleting containers/volumes. Current ZimaOS keeps important app data outside disposable containers.
Use the current ZimaOS persistent app-data model.
Do Not Treat This as a Current 1.7.1 Immich Regression
The source is specifically from ZimaOS 1.5.4 and an older Immich generation. Current ZimaOS and Immich v3 are substantially newer, so reproduce the exact current error before applying a 2026 workaround.
Rolling Immich Back Can Be Unsafe After Database Migrations
One source user said they reverted to a previous Immich version. Current major-version upgrades can migrate database/application state, so downgrade support must come from the matching Immich release guidance rather than simply changing an image tag backward.
A Port Conflict Needs the Existing Listener Identified
The source error explicitly says Docker could not bind host port 2283 because it was already allocated. That can happen when an old Immich container is still running, a second stack uses the same port, or another service was mapped there.
Before deleting anything, identify the current container/listener using the port and decide which stack should own it.
A Grey App Tile Can Be a Symptom of Docker State, Not Immich Data Loss
For the original poster, restarting Docker restored all apps. That means their grey Immich state was downstream of the container runtime rather than proof the photo database or library had been erased.
Another participant did not recover Immich with the same restart, demonstrating why the UI symptom alone is insufficient for root-cause diagnosis.
Read the Compose Failure Before Reinstalling
“Failed to start compose app” is a wrapper error. The useful evidence is the underlying service/container message: port collision, missing volume, database health failure, image pull problem, invalid YAML, or permission issue.
Preserve the failing logs before recreating the stack; a reinstall can erase the evidence.
Current Immich v3 Makes Blind Rollback More Dangerous
Immich has since advanced through major schema and deployment changes. A modern v3 database may not be safe to run against an arbitrary older image simply because a 2026 user once rolled back a v1.x release.
Follow current Immich migration/rollback guidance and keep verified database plus library backups before major version changes.
If Reinstall Is Necessary, Preserve the Persistent Paths First
Record the photo library, PostgreSQL data, configuration, machine-learning/cache paths, and current volume mappings. Removing disposable containers is very different from deleting those persistent host folders.
A successful clean reinstall should reattach the intended persistent data or restore it through a supported backup path—not require re-copying the only photo library from scratch.
Immich 1.5.4 Failure FAQ
Did restarting Docker fix the original poster's Immich?
Yes.
Did it fix every user in the thread?
No. Another user's Immich still failed and later showed a port-2283 conflict.
Should current users immediately reinstall Immich?
No. Identify Docker service health, Compose status, port ownership and persistent data first.
