Kort svar: om CasaOS plötsligt visar ”Failed to load apps” efter en Docker-uppdatering bör du kontrollera Docker Engines API-version innan du installerar om CasaOS. Docker 29.0 höjde daemonens lägsta API-version till v1.44, vilket gjorde att äldre CasaOS App Management-klienter som fortfarande begärde en äldre API-version slutade fungera. I Docker 29.3 sänktes minimiversionen senare till v1.40 igen, så rätt lösning beror på vilken Docker-version du faktiskt kör.
Kontrollera Docker-versionen först
Kör:
docker version
Titta på serverversionen samt fälten för API-version. Dockers API-förhandling gör att klienter och daemons kan enas om en gemensam API-version, men bara inom de versioner som daemonen fortfarande accepterar.
Den gränsen ändrades i Docker 29. Docker 29.0 höjde den lägsta daemon-API-versionen till v1.44. I Docker 29.3.0 sänktes den lägsta versionen till v1.40. API-gränsen för Docker 29 beror därför på version.
| Docker-version | Lägsta Engine API-version | Vad det innebär för CasaOS |
|---|---|---|
| 29.0.x–29.2.x | v1.44 | En äldre CasaOS App Management-klient kan avvisas eftersom den är för gammal. |
| 29.3.0+ | v1.40 | Det ursprungliga kravet på v1.44 är inte längre samma blockerande faktor, så kontrollera loggarna innan du tillämpar en gammal lösning. |
Bekräfta att API-mismatchen är det verkliga felet
Anta inte att ett tomt App Store alltid beror på ett kompatibilitetsproblem med Docker 29. Kontrollera tjänsteloggen:
journalctl -u casaos-app-management --no-pager -n 100
Det viktigaste felet ser ut så här:
Klientversion 1.43 är för gammal.
Lägsta API-version som stöds är 1.44
Det meddelandet är ett starkt tecken på att UI-felet beror på Docker API-kompatibilitet och inte på ett problem med App Store-katalogen. Flera CasaOS-rapporter har återskapat samma symptom efter Docker-uppgraderingar, inklusive det ursprungliga felet vid Docker-uppdatering.
Varför CasaOS kan sluta fungera trots att Docker fortfarande fungerar
CasaOS does not replace Docker Engine. Its App Management service talks to Docker through the Engine API. Docker containers can still be running normally while the CasaOS UI loses the ability to query, create, or manage them.
Det är därför kommandon som:
docker ps
docker images
kan fortfarande fungera även när CasaOS säger att apparna inte kan läsas in. Docker CLI och CasaOS Apphantering är separata API-klienter och begär inte nödvändigtvis samma API-version.
Det bredare sambandet mellan CasaOS och Docker förklaras i CasaOS Docker-hantering, där CasaOS används som det visuella lagret ovanpå Docker-baserade applikationer.
Åtgärda äldre Docker 29-installationer med en API-överskrivning
För Docker 29-versioner som fortfarande kräver API v1.44 är en testad lösning att sänka demonens accepterade miniminivå via systemd. Den rapporterade CasaOS-kompatibilitetslösningen använder:
sudo systemctl edit docker.service
Lägg till:
[Service]
Environment=DOCKER_MIN_API_VERSION=1.24
Starta sedan om Docker:
sudo systemctl daemon-reload
sudo systemctl restart docker
Verifiera åsidosättningen:
systemctl show docker | grep DOCKER_MIN_API_VERSION
Detta är en kompatibilitetsåtgärd, inte ett skäl att låta servern använda en gammal programvarustack på obestämd tid. Den tillåter medvetet att äldre API-klienter kommunicerar med demonen.
Kontrollera om det aktuella installationsprogrammet redan löser problemet
CasaOS-underhållarna rapporterade senare att installationsskriptet hade uppdaterats för att installera en aktuell Docker Engine och tillämpa en Docker API-kompatibilitetsåtgärd för nyare versioner. Den uppdateringen från underhållarna finns i kompatibilitetsuppdateringen för installationsprogrammet.
Om din CasaOS-installation är äldre än den ändringen kan det vara renare att köra om det aktuella officiella installationsprogrammet än att för alltid underhålla en manuell åsidosättning. Säkerhetskopiera viktiga appdata och anpassad konfiguration innan du ändrar en befintlig server.
När du inte bör använda den gamla lösningen
Om docker version visar Docker 29.3 eller senare och minimiversionen för API:et redan är v1.40, ska du inte blint tvinga fram DOCKER_MIN_API_VERSION=1.24. Börja med att granska loggen för CasaOS App Management. Ett annat fel kräver en annan lösning.
Till exempel kan DNS-fel, problem med åtkomst till register, skadad appmetadata eller en stoppad CasaOS-tjänst alla leda till att App Store ser tom ut utan att det handlar om ett API-versionsproblem.
Verifiera CasaOS efter åtgärden
När Docker har startats om kontrollerar du alla tre lager:
-
Docker:
docker psreturnerar normalt. -
CasaOS-tjänst:
systemctl status casaos-app-managementär aktiv och loggar inte längre någon API-avvikelse. - Webbgränssnitt: installerade appar och App Store läses in igen.
Om Docker fungerar men CasaOS App Management fortfarande inte fungerar startar du om tjänsten efter Docker:
sudo systemctl restart casaos-app-management
För användare som jämför applikationsstackar visar ZimaOS plattform för självhostade applikationer den aktuella modellen för appar med installation med ett klick. Om du vill ha en kompakt x86-maskin för testning av Docker och CasaOS listar ZimaBoard 2 officiellt CasaOS bland sina kompatibla operativsystem.
Vanliga frågor
Går Docker 29 alltid sönder med CasaOS?
Nej. Docker 29.0 höjde det lägsta Engine API till v1.44, men Docker 29.3.0 sänkte det till v1.40. Kontrollera den exakta Docker-versionen och CasaOS-loggen innan du väljer en lösning.
Varför körs mina containrar fortfarande?
Containrarna hanteras av Docker Engine. CasaOS App Management är en separat klient. Dess API-anslutning kan misslyckas medan daemonen och befintliga containrar fortsätter att köras.
Bör jag nedgradera Docker?
Inte automatiskt. API-överskridningen var en fungerande lösning för berörda Docker 29-installationer, och senare Docker-versioner ändrade minimikravet för API:et igen. Nedgradering är bara ett alternativ när kompatibiliteten inte kan återställas på ett smidigt sätt.
Vilken logg bevisar att det här är samma problem?
Leta efter ett felmeddelande som säger att Docker-klientens API är för gammalt och att daemonen kräver API v1.44 eller senare. Utan sådana bevis ska du fortsätta felsöka i stället för att anta att det handlar om Docker 29-problemet.
