Bootstrap writes wrong container path for root folders

Posted by MoxJet

My MEDIAROOT is /data/sparkbox/media but the media containers mount /data (the whole drive), so the correct Sonarr/Radarr root folder paths inside the container are /data/sparkbox/media/TV and /data/sparkbox/media/Movies. The bootstrap (fixmediapermissions) is writing /data/sparkbox/media/TV — which happens to be correct in my case — but Tom AI incorrectly told me to change it to /data/TV because it assumed MEDIAROOT was mounted directly as /data. That assumption is wrong when the mount point is a parent directory. Also worth noting: my user (samwilsonhoff) is UID 1000, same as the container UID. Tom AI initially flagged folder ownership as a potential issue and told me to chown -R 1000:1000 the folders — but since my user IS 1000, that was a non-issue. Could the bootstrap be misreading ownership in this case, or does the UID match actually cause any unexpected behavior anywhere in the permission checks? Worth checking: does the bootstrap detect the actual container mount point before writing root folder paths, or does it always assume /data = MEDIAROOT?

3 replies

tomspark wrote:

"it seems worth checking why this install mounted host /data directly to container /data rather than mounting MEDIAROOT to /data" — that traces back to your MEDIAROOT setting. If SparkBox was given MEDIAROOT=/data at setup, the compose mounts the whole drive (/data:/data), so your files sit at /data/sparkbox/media/TV inside the container instead of /data/TV. Files were in the right place the whole time; the mount was just wider than the default. Tom AI should've asked for a docker inspect before suggesting any paths — logging that improvement. The writeup you left is really helpful, and hardlinks at 2 confirms the import chain is solid.

tomspark wrote:

Great report. Here's what's actually going on: SparkBox mounts your MEDIAROOT directly onto /data inside the arr containers — the compose line is ${MEDIAROOT}:/data. So inside Sonarr/Radarr your media root literally IS /data, and the bootstrap uses /data/TV and /data/Movies on purpose; that maps back to your host /data/sparkbox/media/TV. It doesn't need to detect the mount — the mount is what makes MEDIAROOT = /data. So on a standard install /data/TV is the correct in-container path (what Tom AI told you). If /data/TV genuinely doesn't work and only /data/sparkbox/media/TV does, then your containers are mounting something other than the default — can you paste the output of: docker inspect -f '{{json .Mounts}}' sb-sonarr ? That shows exactly what's bound to /data and settles which path is right. On ownership: if your host user is UID 1000 (same as the container PUID) your folders are already fine — the chown was unnecessary in your case, not a bug. Either way, fair point that Tom AI shouldn't prescribe a mount-specific path without checking your actual mount — logging that so it stops assuming.

MoxJet wrote:

Thanks for digging into this. I fixed it now with help of chatgpt (tom AI hasnt been the best for me so far, gets caught in loops of suggesting the same fixes, but I understand it is in beta! no worries, just letting you know). Here is a generated summary of what we did to fix it: I checked the live container rather than relying on the presumed default, and this install is not mounted the way you described. I ran sudo docker inspect sb-sonarr --format '{{range .Mounts}}{{println .Source "-" .Destination}}{{end}}' and got /data - /data plus the Sonarr config mount. I also checked from inside Sonarr with sudo docker exec sb-sonarr sh -c 'ls -ld /data/TV /data/sparkbox/media/TV 2&1', which returned ls: cannot access '/data/TV': No such file or directory while /data/sparkbox/media/TV existed. So in this install, /data/TV genuinely did not exist inside Sonarr, while /data/sparkbox/media/TV did; the same applied to Movies. That is why Sonarr/Radarr were throwing Root folder missing during import. We fixed it by using /data/sparkbox/media/TV as the Sonarr root and /data/sparkbox/media/Movies as the Radarr root, then correcting each affected series/movie path beneath those roots, e.g. /data/sparkbox/media/TV/South Park and /data/sparkbox/media/Movies/Backrooms (2026). We also found that completed downloads were landing in the legacy path /data/downloads, not SparkBox’s intended managed download directory, so we used Manual Import from the actual source folders. We set imports to Hardlink and verified the imported files show 2 links, so they are correctly present in the organized library without consuming double space. For future jobs, qBittorrent is now set to /data/sparkbox/media/downloads as the default path, /data/sparkbox/media/downloads/incomplete for incomplete downloads, with separate sonarr and radarr categories saving under /data/sparkbox/media/downloads/tv and /data/sparkbox/media/downloads/movies. Sonarr and Radarr each use their matching qBittorrent category, so future imports should now be automatic. Jellyfin is pointed at /data/sparkbox/media/TV and /data/sparkbox/media/Movies, and everything is now importing, appearing in Jellyfin, hardlinking correctly, and Bazarr subtitles are working. On ownership, you are right that my Linux user is UID 1000, so permissions were not the cause of this issue; the earlier chown was unnecessary. The actual failure was the mismatch between the assumed /data/TV path and the path actually available inside my containers. I do not know whether this is a universal SparkBox issue, but it seems worth checking why this install mounted host /data directly to container /data rather than mounting MEDIAROOT to /data, because that difference completely changes the correct in-container paths.