The source problem was more dangerous than a disappearing path. After reboot, SABnzbd could start before the Synology SMB share was actually mounted. The container still saw a directory at the expected host path, so a download could complete and appear to move successfullyโwhile actually landing on local ZimaOS storage instead of the remote NAS.
The community eventually built a working manual CIFS/fstab solution, and the original poster confirmed that the mount persisted across reboot. But they also demonstrated the risk: an invalid fstab entry could prevent normal boot, and a mountpoint containing an unescaped space broke the configuration. Treat the commands as source-confirmed community administration, not a current official ZimaOS Network Storage procedure.
The Core Failure Was Mount Timing
The source path looked like:
/media/192.168.2.125/MoviesAfter reboot, the SMB mount was not ready when SABnzbd started. Re-adding the same volume after the system had settled made it work again, strongly supporting a timing/order problem rather than a changing mount ID.
A Missing Remote Mount Can Become a Local Directory Trap
If Docker receives a host directory path that exists locally while the remote filesystem is absent, the application may write into that local directory. The log can still say the file moved to /movies, while nothing appears on Synology.
Before large downloads, verify that the expected remote filesystem is genuinely mounted rather than merely that the mountpoint directory exists.
The Community Moved the Mount to a Stable /DATA Path
The proposed design was to mount the SMB share to a stable local path such as:
/DATA/Media/Moviesand then map that stable host path into SABnzbd. This keeps the container path predictable while the remote filesystem is managed at the host layer.
The Source User Confirmed /etc/fstab Persisted Across Reboot
The community example used CIFS options including _netdev, a specific SMB dialect and UID/GID/mode values. The user said the fstab entry persisted and worked after reboot.
Do not copy credentials directly into world-readable configuration without considering a protected credentials file.
nofail Became Critical After a Bad Entry Blocked Boot
The source user discovered that an invalid or unavailable mount could interfere with boot. The reply recommended nofail so ZimaOS could continue booting if the remote NAS was unavailable.
_netdev also tells the mount system that this is network-dependent.
Spaces in Mountpoints Must Be Handled Correctly
A second fstab entry failed because the mountpoint included TV Shows. In fstab, whitespace separates fields, so a space must be escaped appropriately or avoided with a simpler directory such as TV_Shows.
The OP later used a separate no-space folder successfully.
Always Test with mount -a Before Rebooting
The safest step from the source was:
sudo mount -aIf it returns an error, fix the fstab syntax/path before reboot. Also confirm the mounted filesystem contains the expected remote files.
Prefer Current ZimaOS Network Storage When It Meets the Use Case
Current ZimaOS can connect SMB/LAN storage through its Files/Network Storage workflows. Use the managed interface first when it provides the persistence/order behavior your app requires.
See the current Synology SMB connection workflow.
A Truly Robust Container Should Not Write Until the Remote Mount Is Verified
Even with fstab, a network NAS can be offline later. For important download/import pipelines, add a health/startup check or operational procedure that confirms the remote target is mounted before SABnzbd processes jobs.
SABnzbd SMB Mount FAQ
Did the source prove the SMB mount ID changed after reboot?
No. The evidence supported a mount-timing problem.
Did fstab persist for the source user?
Yes, but malformed/unavailable entries also caused boot problems until corrected.
Why can a download appear successful while the Synology has no file?
The application can write to the local mountpoint directory when the remote SMB filesystem is not actually mounted.
