The Thread Contained More Than One App-Startup Problem
After upgrading from ZimaOS 1.4.1 to 1.4.2, the original poster found that some apps, including Portainer, did not appear to start automatically. Docker restart policies such as unless-stopped and always did not change the visible result, while clicking the app in the dashboard started it.
Other users then reported related but distinct symptoms. One group found that containers were already reachable by their direct web address while the ZimaOS dashboard behaved as if they were stopped. Another later confirmed that selected containers genuinely failed because their SMB-backed volume paths were not mounted when app startup occurred.
Case One: The Container Worked but the Dashboard Could Not Open It
One user documented a four-step sequence. The dashboard first presented the app as stopped, then warned that it might be unavailable. Following the offered link opened a new browser window where the application worked normally. Pasting the same address and port directly into the browser also worked.
The IceWhale team treated this behavior as part of the investigation. The thread does not establish that changing a Docker restart policy fixes this dashboard-state problem.
Case Two: App Updates and Settings Failed for One User
Another participant running 1.4.3 reported brief errors while updating Radarr and Sonarr and said settings changes were not applied. Reinstalling the apps did not help in that environment. The participant later said changing registry mirrors allowed settings changes again, and separately restored ownership on relevant app folders to match the configured UID 1000.
These were user-reported changes, not a universal fix for every reboot failure. Editing Docker daemon configuration or recursively changing ownership can affect the entire host, so the thread evidence should not be generalized beyond the participant's environment.
Case Three: SMB Storage Was Not Ready When Containers Started
The original poster later identified a concrete cause for three containers. Their volumes were mapped to an SMB share. Logs showed the containers attempted to start before the SMB filesystem was available, failed, and remained down. Manually starting them later worked because the share had mounted by then.
This explains why changing always to unless-stopped did not help those containers: a restart policy cannot make an unavailable bind-mount path ready earlier. The relevant dependency was storage readiness and startup order.
What Version 1.4.3 Confirmed and Did Not Confirm
An IceWhale reply asked users to test 1.4.3. One participant said the dashboard behavior remained, while the original poster initially thought 1.4.3 helped but later reproduced the SMB startup-order failure. Another reply noted that an app must first be started so the app-management service knows its last running state.
The thread therefore does not support a blanket statement that 1.4.3 fixed every 1.4.2 startup problem. It supports a diagnostic split: first check whether the container is truly stopped, then inspect its logs and storage dependencies.
FAQ
Why does an app open by URL but look stopped in ZimaOS?
That pattern appeared as a dashboard launch or state-reporting issue. The service itself could already be running and reachable at its configured address and port.
Why do only containers using an SMB share fail after reboot?
In the confirmed case, those containers started before the SMB mount was ready. They worked when started manually after the share appeared.
Did changing the Docker restart policy solve the issue?
No. The original poster tested both always and unless-stopped without resolving the affected containers.
