A Samba share created in the ZimaOS Files app should not have to be recreated after every reboot. In the January 2026 thread, a community reply initially suggested waiting for the storage pool to mount, but after the user clarified that the share definition itself disappeared, the behavior was treated as abnormal.
The thread did not reach a confirmed repair. That means “restart SMB” or “toggle the share” should not be promoted as a permanent fix for a share record that actually vanishes.
First Distinguish a Missing Share From a Slow Mount
After reboot, open Storage and confirm the underlying disk/pool is online. Then check the Files/Shared via Samba interface. If the share still exists but clients cannot connect, troubleshoot SMB service and authentication. If the share definition is gone, that is a different persistence problem.
Current ZimaOS Supports Persistent Samba Share Management
The current Samba multi-user guide documents creating shares from Files and managing them later under the shared-items interface.
The current SMB troubleshooting guide is useful when the share exists but access fails.
Do Not Recreate the Share Before Capturing Evidence
If the definition disappears after every reboot, record the ZimaOS version, share path, storage pool, permission type and screenshots before recreating it. Repeatedly rebuilding the share erases the state that support needs to investigate.
The authenticated SMB guide helps separate permission/authentication failures from share-persistence failures.
Check Whether the Shared Path Is Persistent
A share backed by a normal mounted ZimaOS storage space should survive reboot. A path inside a transient mount, removable device, container layer or temporarily unavailable external filesystem can fail differently.
Wait until storage is online before deciding the share is missing, but if the Files app truly shows no saved share afterward, treat it as a configuration-persistence bug rather than ordinary client reconnection delay.
Bottom Line
The original thread did not produce a verified fix. It established an important boundary: a temporarily unreachable SMB share after reboot can be a mount/client timing issue, but a Files-created share that disappears entirely is not normal. Capture the disappearing configuration and reproduce it on the current ZimaOS release before applying service-restart workarounds.
