Tråden innehöll mer än ett problem med appstart
Efter uppgradering från ZimaOS 1.4.1 till 1.4.2 upptäckte den ursprungliga skribenten att vissa appar, däribland Portainer, inte verkade starta automatiskt. Docker-omstartspolicyer som om den inte stoppas och alltid ändrade inte det synliga resultatet, medan ett klick på appen i instrumentpanelen startade den.
Andra användare rapporterade sedan relaterade men skilda symtom. En grupp upptäckte att containrarna redan kunde nås via sina direkta webbadresser medan ZimaOS-instrumentpanelen betedde sig som om de var stoppade. En annan grupp bekräftade senare att vissa valda containrar faktiskt inte fungerade eftersom deras SMB-baserade volymsökvägar inte var monterade när appstarten skedde.
Fall ett: Containern fungerade, men instrumentpanelen kunde inte öppna den
En användare dokumenterade ett förlopp i fyra steg. Instrumentpanelen visade först appen som stoppad och varnade sedan för att den kanske inte var tillgänglig. När den erbjudna länken följdes öppnades ett nytt webbläsarfönster där applikationen fungerade normalt. Det fungerade också att klistra in samma adress och port direkt i webbläsaren.




IceWhale-teamet behandlade detta beteende som en del av utredningen. Tråden fastställer inte att ändring av en Docker-omstartspolicy löser problemet med instrumentpanelens tillstånd.
Fall två: Appuppdateringar och inställningar misslyckades för en användare
En annan deltagare som körde 1.4.3 rapporterade kortvariga fel vid uppdatering av Radarr och Sonarr och sade att inställningsändringarna inte hade tillämpats. Ominstallation av apparna hjälpte inte i den miljön. Deltagaren sade senare att byte av registerspeglingsservrar gjorde att inställningsändringar kunde tillämpas igen och återställde separat ägarskapet för relevanta appmappar så att det överensstämde med det konfigurerade UID:t 1000.





Detta var ändringar som rapporterades av användare, inte en universell lösning för alla omstartsproblem. Att redigera Dockers daemon-konfiguration eller ändra ägarskap rekursivt kan påverka hela värdsystemet, så bevisen i tråden bör inte generaliseras utanför deltagarens miljö.
Fall tre: SMB-lagringen var inte klar när containrarna startade
Ursprungsskribaren identifierade senare en konkret orsak för tre containrar. Deras volymer var mappade till en SMB-resurs. Loggarna visade att containrarna försökte starta innan SMB-filsystemet var tillgängligt, misslyckades och förblev avstängda. Att starta dem manuellt senare fungerade eftersom resursen då hade monterats.
Detta förklarar varför ändring av alltid till om den inte stoppas hjälpte inte dessa containrar: en omstartspolicy kan inte göra en otillgänglig sökväg för bind-montering tillgänglig tidigare. Det relevanta beroendet var lagringens tillgänglighet och startordningen.
Vad version 1.4.3 bekräftade och inte bekräftade
Ett svar från IceWhale bad användarna att testa 1.4.3. En deltagare sade att instrumentpanelens beteende kvarstod, medan ursprungsskribaren först trodde att 1.4.3 hjälpte men senare återskapade SMB-problemet med startordningen. Ett annat svar påpekade att en app först måste startas så att apphanteringstjänsten känner till dess senaste körstatus.
Tråden ger därför inte stöd för ett generellt påstående att 1.4.3 löste alla startproblem i 1.4.2. Den stöder i stället en diagnostisk uppdelning: kontrollera först om containern verkligen är stoppad och granska sedan dess loggar och lagringsberoenden.
Vanliga frågor
Varför öppnas en app via URL men ser ut att vara stoppad i ZimaOS?
Det mönstret visade sig vara ett problem med att starta från instrumentpanelen eller rapportera status. Själva tjänsten kunde redan vara igång och nåbar på den konfigurerade adressen och porten.
Varför misslyckas endast containrar som använder en SMB-resurs efter omstart?
I det bekräftade fallet startade containrarna innan SMB-monteringen var klar. De fungerade när de startades manuellt efter att resursen blivit tillgänglig.
Löste det problemet att ändra Dockers omstartspolicy?
Nej. Ursprungsskribenten testade båda alltid och om den inte stoppas utan att lösa problemen med de berörda containrarna.
