Community Solution

Fix CasaOS Failed to Load Apps After a Docker Update

A CasaOS user on Ubuntu with Docker 29.0.1 could load the dashboard but not the Apps section. Logs showed CasaOS App Management using Docker API 1.43 while the Docker daemon required at least 1.44, alongside secondary permission errors.

If CasaOS itself loads but the Apps section only shows “Failed to load apps, please refresh later” after a Docker update, check the CasaOS App Management logs before changing filesystem permissions. In the November 2025 IceWhale Community case, the decisive error was not the dashboard itself: CasaOS App Management was trying to use Docker API 1.43, while Docker Engine 29.0.1 required at least API 1.44.

The same log also contained permission errors under /var/run/casaos, /var/log/casaos, and /var/lib/casaos, but the Docker API rejection was a separate compatibility failure that prevented CasaOS from listing container/app information. CasaOS maintainers later updated the installation script to work with newer Docker versions and apply API compatibility handling, so current users should start with the updated CasaOS installer rather than permanently downgrading Docker.

The Error That Identified the Real Compatibility Problem

The original author reported:

Error response from daemon:
client version 1.43 is too old.
Minimum supported API version is 1.44,
please upgrade your client to a newer version

The environment was:

  • Ubuntu Server;
  • Docker Engine 29.0.1;
  • Docker API 1.52;
  • CasaOS App Management built in October 2024.

This explains why the CasaOS dashboard could still open while the Apps section failed: the web interface and the Docker-backed app-management service are different layers.

Why a Docker Update Could Break CasaOS App Listing

Docker Engine exposes a versioned API. Older management clients can usually negotiate with newer daemons, but Docker has progressively raised the minimum API version it accepts.

Current Docker documentation explains API-version negotiation and notes that older API versions are gradually deprecated or removed. See the Docker Engine API documentation.

In this source case, CasaOS App Management spoke API 1.43 while the Docker 29 daemon refused anything below 1.44. That made app enumeration fail before the UI could render the app list.

The Permission Errors Were Real but Not the Same Failure

The logs also contained messages such as:

open /var/run/casaos/app-management.url: permission denied
mkdir /var/lib/casaos/appstore/...tmp: permission denied
can't rename log file ... permission denied

The author had already created and adjusted permissions on the relevant CasaOS directories, yet the App Store still failed. That result is important: broad permission changes could not fix a Docker API incompatibility.

Do not recursively chmod 777 or change ownership across CasaOS system directories just because the UI says Apps failed to load. Read the exact logs first.

MjTech replied that this was a known Docker-related issue and pointed the author to a BigBear community fix for CasaOS Docker API errors.

At the time, common temporary workarounds included:

  • lowering the minimum Docker API version accepted by the daemon through a systemd override;
  • or temporarily using an older Docker release that still accepted the CasaOS client API.

Those workarounds were valuable in November 2025, but they should not automatically become the permanent 2026 procedure because the CasaOS installer was subsequently updated.

CasaOS Later Updated the Installer

In December 2025, a CasaOS maintainer reported on GitHub that the installation script had been fixed so it would:

  • install the latest available Docker Engine instead of the old Docker 24.0.7 target;
  • apply Docker API compatibility handling for newer Docker versions;
  • allow CasaOS services and built-in applications to work with modern Docker.

The maintainer specifically said a clean install or the current installation script could be used to repair the previous Docker app-not-loading issue.

For the current source, see the CasaOS installer script.

Current First Fix: Use the Updated CasaOS Installer

CasaOS currently documents:

curl -fsSL https://get.casaos.io | sudo bash

or:

wget -qO- https://get.casaos.io | sudo bash

Before running an installer over an existing server, back up important application databases and configuration. The repair is intended to preserve CasaOS state, but a home server should never depend on a repair script as its only recovery plan.

Current install instructions are available in the CasaOS GitHub repository.

Verify the API Error Before Applying Any Compatibility Override

Check Docker:

docker version

Then inspect CasaOS App Management:

sudo systemctl status casaos-app-management
sudo journalctl -u casaos-app-management --no-pager -n 100

If the log explicitly contains:

client version 1.43 is too old
Minimum supported API version is 1.44

then you are dealing with the same Docker API class of failure as the source thread.

If the log instead shows disk-full errors, DNS failures, a dead Docker daemon, a corrupt app-store catalog, or missing files, do not apply an API workaround just because the UI message is identical.

About the Historical Docker API Compatibility Override

Community and GitHub workarounds during the 2025 incident added a Docker systemd environment setting that allowed older client API versions again. That could restore app listing while CasaOS still used API 1.43.

This changes the Docker daemon's compatibility boundary. Treat it as a temporary compatibility mechanism for a verified old-client/new-daemon mismatch, not as a generic CasaOS tuning setting.

Current Docker documentation explains that legacy API support changes over time and recommends keeping clients current rather than permanently depending on old API versions.

Do Not Blindly Set DOCKER_API_VERSION on CasaOS

Docker's DOCKER_API_VERSION variable forces a client to use a specific API version and disables normal API negotiation. Docker documents it primarily for cases where an exact API version is required or for debugging.

That is different from making a newer Docker daemon accept an older CasaOS client's API. Setting an arbitrary client-side API value can make the mismatch worse.

Also Confirm Docker Is Healthy

sudo systemctl status docker
docker ps

If Docker itself is stopped, CasaOS cannot list running containers regardless of API version.

Check Disk Space Before Reinstalling Anything

The same “Failed to load apps” UI message has appeared in unrelated CasaOS cases where the system disk was nearly full. Check:

df -h

A full root filesystem can break logs, temporary files, App Store updates, and Docker state. Do not assume every identical UI banner has the same cause.

Safe Troubleshooting Order

  1. Confirm the CasaOS dashboard itself opens.
  2. Check systemctl status docker and docker ps.
  3. Check df -h.
  4. Read casaos-app-management logs.
  5. If the log shows the 1.43/1.44 API mismatch, use the current CasaOS installer/repair path first.
  6. Only use an API-compatibility override when the mismatch is verified and the current repair path is not available.
  7. Do not broadly relax permissions on CasaOS directories without evidence.
  8. Back up app data before reinstalling or making system-level Docker changes.

CasaOS Failed to Load Apps FAQ

Why does the CasaOS dashboard work while Apps do not?

The UI, CasaOS services, Docker daemon, and CasaOS App Management are separate components. The source case failed specifically when App Management tried to query Docker.

Was Docker 29 the cause in the source thread?

The source logs showed Docker 29.0.1 requiring API 1.44 while the installed CasaOS App Management client used API 1.43. That mismatch directly prevented app listing.

Should I chmod CasaOS folders to fix the page?

Not without evidence. The original author already modified permissions and still had the Docker API failure. Read the exact service logs first.

Should I downgrade Docker?

That was one historical workaround. CasaOS later updated its installer to support modern Docker compatibility, so use the current repair/install path before forcing an older Docker release.

Does “Failed to load apps” always mean a Docker API mismatch?

No. The same UI message can result from a stopped Docker daemon, full disk, permissions, app-management failures, or other service problems. The log determines the diagnosis.