This thread began as an application autostart complaint, but one later reply identified a deeper failure mode: Docker itself could fail to start because a systemd override forced nvidia-container-runtime on a host where that runtime path was incompatible.
First Decide Whether Docker Is Starting
If several unrelated apps all fail after reboot, inspect the Docker service before editing each application. Docker's Docker daemon troubleshooting documents daemon startup failures caused by conflicting configuration and systemd overrides.
The ZimaOS App Store requirements helps frame which applications are Docker-based, while the first Docker app provides the normal ZimaOS container workflow. A problem affecting many containers simultaneously is more likely to be a daemon/runtime layer than nine independent application bugs.
Restart Policy Is Not the Only Layer
Docker's Docker restart policies explains that restart policies control what the daemon does with stopped containers. They do not help if the Docker daemon itself cannot start correctly.
The NVIDIA Runtime Fix Was System-Specific
One contributor disabled a Docker systemd override that explicitly added nvidia-container-runtime. After reboot, Docker returned, but NVIDIA GPU support was no longer configured through that override.
NVIDIA's NVIDIA Container Toolkit currently recommends configuring Docker with nvidia-ctk runtime configure --runtime=docker and then restarting Docker. That is important context: renaming an override file from an old community thread should not be treated as the universal modern way to configure or remove the NVIDIA runtime.
Check Free Space Before Modifying System Files
A later user tried to rename the override and received No space left on device. That is a different root cause and must be solved first. The ZimaOS 1.5 changes provides version context for ZimaOS changes, while the ZimaOS troubleshooting workflow is useful when a broader host-level failure follows an update.
A Safer Diagnostic Order
- Check whether Docker is active and inspect its recent logs.
- Confirm the system disk is not full.
- Check container restart policies only after the daemon is healthy.
- If the logs mention NVIDIA runtime loading, inspect the current runtime configuration before changing it.
- Back up any custom systemd override before modifying it.
Bottom Line
The source thread does not prove that every ZimaOS 1.4.3 autostart problem had the same cause. On one system, an NVIDIA Docker runtime override prevented the daemon from starting normally; on another, the attempted fix exposed a full system disk. Diagnose the Docker daemon and storage state before applying the historical override workaround.
