This source contains several failures that happened close together, so it should not be rewritten as one simple “Portainer bug.” The system drive had almost no free space, Docker and containerd were upgraded to major new versions through Debian, an older Docker CLI test was rejected by the Docker 29 daemon, Portainer lost its Local environment, CasaOS kept showing “loading apps,” and a later boot problem made the dashboard look almost like a fresh install.
No reply in the source confirms one final root cause. The safest interpretation is a layered recovery problem: preserve the existing data first, then identify which boot/root filesystem is active, whether the Docker data root still exists, whether the daemon is healthy, and whether Portainer/CasaOS are compatible with the upgraded Docker API.
The System Disk Was Already Under Severe Space Pressure
The user had only about 1 GB free on a 27 GB root filesystem before cleanup. Large consumers included Docker overlay data, Jellyfin metadata, system logs, and development packages.
Low free space can cause Docker image/container operations, databases, logs, and CasaOS services to behave unpredictably. Freeing space was necessary regardless of the later Docker API issue.
The Host Upgrade Changed Docker from 28.x to 29.0.0
The Debian package history showed upgrades of:
-
docker-ce; -
docker-ce-cli; -
containerd.io; - Docker rootless extras.
A major Docker Engine upgrade can expose compatibility problems in management tools that bundle or negotiate older API clients.
The Source Captured a Real Docker API Version Mismatch
A Docker 24.0.5 CLI container returned:
client version 1.43 is too old.
Minimum supported API version is 1.44That message is direct evidence that at least one old client could no longer talk to the upgraded Docker daemon. It does not by itself prove Portainer used that exact client version, but it makes API compatibility a high-priority check.
Portainer Saying Local Is Up Then Missing Is a Management-Layer Symptom
The source tried recreating a local Docker environment against /var/run/docker.sock without success. Before deleting Portainer state, verify:
docker info
docker ps
ls -l /var/run/docker.sockIf the Docker CLI itself works but Portainer does not, focus on Portainer version/API/socket access. If Docker itself fails, fix the daemon first.
CasaOS “Loading Apps” Suggests the Failure Was Broader Than Portainer
CasaOS also struggled to enumerate applications. That can happen if Docker is unavailable, if the Docker API changed incompatibly, if the daemon data root is missing, or if the booted host is no longer the expected system state.
The Later “Select Proper Boot Device” Event Changes the Recovery Priority
After a restart, the machine stopped booting normally until the user changed the boot selection. Once it came back, CasaOS had no apps even though the large HDD remained linked.
That raises the possibility that a different boot disk/root filesystem was selected or that the system partition/state changed. The source does not prove which.
Preserve AppData Before Reinstalling CasaOS
The user cared most about:
-
/home/casaosproject files; - Jellyfin metadata under AppData;
- media files on the HDD;
- Docker/CasaOS configuration where recoverable.
Copy those durable folders to another disk/system before reinstalling or resetting Docker. Recreating containers is usually easier than recreating application databases and metadata.
Do Not Aggressively Prune Docker Until You Know What Is Still Referenced
Image pruning can recover space, but deleting volumes or data-root directories can remove the application state you are trying to save. Identify containers, volumes, bind mounts, and AppData paths first.
Treat Debian and Docker Updates as Part of the CasaOS Platform
CasaOS sits on top of the underlying Linux host. A broad apt upgrade can update Docker, kernel, systemd, networking, and storage packages that CasaOS depends on. Test major host upgrades deliberately and keep a system/application backup before applying them to a working NAS.
Portainer/CasaOS Recovery FAQ
Did the source prove Docker 29 alone caused every failure?
No. The system was also nearly full and later had a boot-device/state problem.
Was there a confirmed Docker API mismatch?
Yes. A Docker 24 CLI using API 1.43 was rejected because the Docker 29 daemon required at least 1.44.
Should the user reinstall CasaOS before copying AppData?
No. Preserve important AppData, home-directory files, and media first whenever the disks remain accessible.
