Gemenskapslösning

Portainer lokal miljö saknas i CasaOS efter Docker 29: disktryck, API-kompatibilitet och återställning

A November 2025 ZimaBlade post where a nearly full Debian/CasaOS system was also upgraded from Docker 28.5.2 to Docker 29.0.0. Portainer could no longer open its Local environment, an older Docker 24 CLI was rejected because API 1.43 was below the server minimum 1.44, and after reboot CasaOS appeared to lose its apps. The thread contains no confirmed final root cause.

Den här källan innehåller flera fel som inträffade tätt efter varandra, så den bör inte skrivas om till ett enkelt ”Portainer-fel”. Systemdisken hade nästan inget ledigt utrymme, Docker och containerd uppgraderades till nya huvudversioner via Debian, ett äldre Docker CLI-test avvisades av Docker 29-daemonen, Portainer förlorade sin lokala miljö, CasaOS fortsatte att visa ”läser in appar” och ett senare startproblem fick instrumentpanelen att se nästan ut som en nyinstallation.

Inget svar i källan bekräftar en slutgiltig grundorsak. Den säkraste tolkningen är ett problem med återställning i flera lager: bevara först befintliga data och fastställ sedan vilken start-/rotfilsystemsenhet som är aktiv, om Dockers datarot fortfarande finns kvar, om daemonen fungerar och om Portainer/CasaOS är kompatibla med det uppgraderade Docker-API:t.

Systemdisken hade redan allvarlig platsbrist

Användaren hade bara cirka 1 GB ledigt på ett rotfilsystem på 27 GB före rensningen. Stora utrymmesförbrukare var bland annat Dockers overlay-data, Jellyfin-metadata, systemloggar och utvecklingspaket.

Lite ledigt utrymme kan få Docker-åtgärder för avbildningar och containrar, databaser, loggar och CasaOS-tjänster att bete sig oförutsägbart. Det var nödvändigt att frigöra utrymme oavsett det senare Docker API-problemet.

Värduppgraderingen ändrade Docker från 28.x till 29.0.0

Debians pakethistorik visade uppgraderingar av:

  • docker-ce;
  • docker-ce-cli;
  • containerd.io;
  • Extra komponenter för Docker rootless.

En större uppgradering av Docker Engine kan avslöja kompatibilitetsproblem i hanteringsverktyg som inkluderar eller förhandlar med äldre API-klienter.

Källan fångade en verklig skillnad i Docker API-version

En Docker 24.0.5 CLI-container returnerade:

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

Det meddelandet är ett direkt bevis på att minst en gammal klient inte längre kunde kommunicera med den uppgraderade Docker-daemonen. Det bevisar inte i sig att Portainer använde exakt den klientversionen, men det gör API-kompatibilitet till en kontroll med hög prioritet.

Att Portainer först visar att Local är aktiv och sedan saknas är ett symptom på hanteringslagret

Källan försökte återskapa en lokal Docker-miljö mot /var/run/docker.sock utan framgång. Kontrollera följande innan du raderar Portainer-data:

docker info
docker ps
ls -l /var/run/docker.sock

Om Docker CLI fungerar men Portainer inte gör det bör fokus ligga på Portainer-versionen, API-kompatibilitet och åtkomst till socketen. Om Docker själv inte fungerar måste daemonen åtgärdas först.

CasaOS ”Läser in appar” tyder på att felet var bredare än Portainer

CasaOS hade också problem med att räkna upp applikationer. Det kan inträffa om Docker inte är tillgängligt, om Docker API:t har ändrats på ett inkompatibelt sätt, om daemonens datarot saknas eller om den startade värden inte längre är i det förväntade systemtillståndet.

Den senare händelsen ”Välj korrekt startenhet” ändrar prioriteringen vid återställningen

Efter en omstart slutade maskinen att starta normalt tills användaren ändrade startvalet. När systemet kom tillbaka hade CasaOS inga appar, trots att den stora hårddisken fortfarande var ansluten.

Det öppnar möjligheten att en annan startdisk eller ett annat rotfilsystem valdes, eller att systempartitionen eller systemtillståndet hade ändrats. Källan bevisar inte vilket.

Bevara AppData innan du installerar om CasaOS

Användaren brydde sig mest om:

  • /home/casaos-projektfiler;
  • Jellyfin-metadata under AppData;
  • mediefiler på hårddisken;
  • Docker-/CasaOS-konfiguration, i den mån den går att återställa.

Kopiera dessa beständiga mappar till en annan disk eller ett annat system innan du installerar om eller återställer Docker. Det är vanligtvis enklare att återskapa containrar än att återskapa programdatabaser och metadata.

Rensa inte Docker aggressivt innan du vet vad som fortfarande används

Rensning av avbildningar kan frigöra utrymme, men om du tar bort volymer eller kataloger i dataroten kan du radera det programtillstånd du försöker rädda. Identifiera först containrar, volymer, bind mounts och AppData-sökvägar.

Betrakta Debian- och Docker-uppdateringar som en del av CasaOS-plattformen

CasaOS kör ovanpå det underliggande Linux-värdsystemet. En bred apt upgrade kan uppdatera Docker, kärnan, systemd, nätverk samt lagringspaket som CasaOS är beroende av. Testa större värduppgraderingar medvetet och ha en säkerhetskopia av systemet och applikationerna innan du tillämpar dem på en fungerande NAS.

Vanliga frågor om återställning av Portainer/CasaOS

Bevisade källan att Docker 29 ensamt orsakade alla fel?

Nej. Systemet var också nästan fullt och fick senare ett problem med startenhet eller systemtillstånd.

Fanns det en bekräftad skillnad i Docker API-version?

Ja. En Docker 24 CLI som använde API 1.43 avvisades eftersom Docker 29-daemonen krävde minst 1.44.

Bör användaren installera om CasaOS innan AppData kopieras?

Nej. Bevara viktig AppData, filer i hemkatalogen och mediefiler först, så länge diskarna fortfarande är åtkomliga.