If Plex, Radarr, Sonarr, or another Docker app loses access to a remote SMB NAS after every ZimaOS reboot, check the host mount before changing the application. The container can only see a network share if ZimaOS has mounted it successfully and the Docker bind path still points to that mounted location.
A community case involving a Synology share recovered each time the user re-selected the same folder in the Docker Compose path picker. That strongly suggests a mount/path persistence issue, but the forum explanation that ZimaOS always generated a new internal mount ID was community reasoning rather than an IceWhale-confirmed root cause. A good guide should therefore troubleshoot the mount, path, and startup order separately.
First Confirm Whether the SMB Share Is Mounted After Reboot
Before opening Plex or Radarr, open ZimaOS Files and browse the remote NAS share. If the share itself is unavailable, the Docker app is not the first problem.
If the share is missing
Check the remote NAS is online, its IP/hostname still resolves, SMB is enabled, and the saved credentials remain valid. Reconnect the share through the ZimaOS Network Storage workflow if necessary.
If the share is visible in Files
Then move to the Docker mapping. The host mount exists, but the application may still reference a stale or unavailable path.
Use ZimaOS Network Storage Rather Than a Hand-Written fstab Entry
The source user considered editing /etc/fstab. That is not the best first fix on an appliance-style OS that already manages network storage in its UI.
The current ZimaOS documentation shows SMB-based access to another NAS as part of its migration and network-storage workflows. Use that managed path first so ZimaOS can handle credentials and mount state consistently.
The ZimaOS NAS migration guide provides the current reference.
Check the Docker Host Path, Not Only the Container Path
Docker volume mappings have two sides:
- host path: where ZimaOS sees the mounted Synology folder;
- container path: the stable path Plex, Radarr, or Sonarr sees inside the container.
If the host side is invalid after reboot, the container path may still look correct in the application UI while pointing to nothing useful.
The current ZimaOS Docker path guide explains this distinction.
Re-Select the Folder Once as a Diagnostic Test
If the remote share is visible in Files but the app cannot access it, open the app or Compose configuration and re-select the host folder using the ZimaOS path picker.
If access returns immediately without changing credentials or container paths, you have strong evidence that the failure is between the managed mount and the Docker bind mapping.
Check Startup Order After Every Reboot
Remote SMB storage depends on networking, DNS/IP reachability, authentication, and the NAS being ready. Docker containers may start faster than the remote mount becomes available.
Simple test
- reboot ZimaOS;
- wait until the remote share is browsable in Files;
- restart only the affected Docker app;
- check whether media or downloads return.
If that works reliably, the path may be stable and the real issue may be startup timing rather than changing mount identifiers.
Check Permissions on Both Systems
The Synology account used for the SMB mount must have access to the media folders. Then the ZimaOS mount must be accessible to the Docker process. Finally, the application must use the correct container path.
Permissions problems can look similar to a missing mount, so check for “permission denied” separately from “path not found” or “no such file.”
Why Manual fstab Changes Can Make Recovery Harder
A custom mount can introduce credential files, boot dependencies, timing flags, and failure behavior that ZimaOS does not manage in its UI. If that custom mount fails during boot, apps may still start against an empty directory.
Use fstab only when the managed network-storage workflow cannot satisfy a requirement and you are prepared to maintain the mount across updates.
How to Make Media Apps More Resilient
- Use a stable NAS IP or reliable local DNS name.
- Keep the remote share configured through Network Storage.
- Map one stable host folder into the container.
- Use the same container path consistently across Radarr, Sonarr, download clients, and media servers.
- After updates or storage changes, verify the mount before changing application libraries.
The LAN troubleshooting guide helps isolate whether the failure starts at the network layer, while the Docker path basics provides the Docker context.
FAQ
Why do my Docker apps lose a Synology share after ZimaOS restarts?
The most likely layers are the SMB share not remounting, the app using a stale host path, or the container starting before the remote share is ready. Test those separately.
Should I edit /etc/fstab?
Not as the first fix. Prefer ZimaOS Network Storage so the system manages the share. Manual mounts add maintenance and boot-order complexity.
Why does re-selecting the same folder fix the app?
It refreshes the host-side bind mapping. That is evidence of a mount/path problem even when the visible folder name has not changed.
Can I use a remote SMB share for Plex and Arr apps?
Yes, provided ZimaOS mounts it reliably, permissions are correct, and all containers use consistent host and container paths.
