Discord-lösning

CasaOS kunde inte läsa in appar efter Docker 29-uppdateringen: Så åtgärdar du det

A CasaOS feedback thread surfaced a GitHub issue where Docker updates on Ubuntu caused installed apps to disappear from the CasaOS Web UI.

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:

  1. Docker: docker ps returnerar normalt.
  2. CasaOS-tjänst: systemctl status casaos-app-management är aktiv och loggar inte längre någon API-avvikelse.
  3. 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.