Bottom Line: Sonarr Cannot Use a ZimaOS Host Path Unless That Path Is Mounted Into the Container
Emby seeing SSD/media/TV shows does not prove Sonarr can see the same directory. Each Docker app has its own filesystem. Sonarr only sees the host folders that ZimaOS maps into that Sonarr container.
Check the Volume Mapping Before Changing Permissions
Open Sonarr’s app settings in ZimaOS and look at its volume mappings. You need a host path and a container path, for example:
Host: /your-storage/media
Container: /mediaInside Sonarr, choose /media/TV shows as the root folder—not the original host path. The current ZimaOS app path guide explains this host-path/container-path split directly. Docker defines the same model in its bind mount documentation.
Use One Shared Media Mapping Across the Arr Stack
For Sonarr, Radarr and the download client, consistency matters more than clever paths. Map the same host media root into the same container location whenever possible. That avoids one app seeing /media/tv while another sees the same files as /downloads/completed/tv.
The Sonarr hardware and ZimaOS guide also separates Sonarr’s lightweight workload from the storage and media-server workload around it.
If the Folder Appears but Is Still Rejected
Then move to permissions. Confirm the container can read/write the mounted path and that the root folder is not a read-only mount. Do not start with chmod-wide fixes; first prove the correct folder is actually mounted. The Servarr project documents Docker path design in its Docker guide.
Fast Diagnostic Rule
If the folder does not appear inside Sonarr at all, think mount path. If it appears but Sonarr says it cannot write, think permissions. That distinction saves a lot of random troubleshooting.
For broader app deployment context, see the ZimaOS App Store hardware guide.
