Move SABnzdb incomplete downloads and unpack to my SSD Volume2 on Ugreen NAS
Posted by danmacx2
Hi Team, My download speeds are severely impacted by my spinning disk speeds when unpacking and or repairing my linux isos 😀. I have 2tb of SSD running where I would like the heavy work being done before the files are transferred to my spinning disks /volume1/sparkbox-data. I originally modified the docker-compose.yml but as your AI correctly reported this would break after every update. Is there a way we can do this without having to redo after a reboot / update? My question: sudo docker exec sb-gluetun sh -c 'df -h /data/downloads/incomplete && ls -ld /data/downloads/incomplete' Filesystem Size Used Available Use% Mounted on df: /data/downloads/incomplete: can't find mount point. sudo docker inspect -f '{{json .Mounts}}' sb-sabnzbd [{"Type":"bind","Source":"/opt/sparkbox/modules/media/config/sabnzbd","Destination":"/config","Mode":"rw","RW":true,"Propagation":"rprivate"},{"Type":"bind","Source":"/volume1/sparkbox-data/media","Destination":"/data","Mode":"rw","RW":true,"Propagation":"rprivate"},{"Type":"bind","Source":"/opt/sparkbox/scripts/sab-preinit-port.sh","Destination":"/custom-cont-init.d/01-set-port.sh","Mode":"ro","RW":false,"Propagation":"rprivate"}] SparkBox AI replied: That confirms the problem. The SSD mount is fine on the host, but Docker mounted /volume1/sparkbox-data/media into SAB with rprivate propagation: text /volume1/sparkbox-data/media → /data Propagation: rprivate So the nested /volume2 bind mount is invisible inside the container. sb-gluetun also isn’t the right filesystem test here — SAB’s own mount confirms it. The current approach won’t work with SparkBox’s stock media mount. Don’t configure SAB to use that path yet Inside SAB, /data/downloads/incomplete currently exists only as part of the /volume1 mount, not as the SSD filesystem. Downloads would still hit the spinning disk. What’s needed SAB needs a direct Docker bind mount like: te …(reply truncated — full chat sent to Tom)
3 replies
Chris wrote:
Yes — there's a way that survives every reboot and update, and it doesn't touch docker-compose.yml at all. SparkBox keeps a per-app override folder under state/, which upgrades never overwrite, and merges it on top of the Media Center on every start. 1. Make a folder for it on the SSD and give it to the SparkBox user (the PUID/PGID in /opt/sparkbox/.env, usually 1000): sudo mkdir -p /volume2/sab-incomplete && sudo chown 1000:1000 /volume2/sab-incomplete 2. Create the file /opt/sparkbox/state/overrides/media.yml with exactly these four lines (indent 2 / 4 / 6 spaces): - line 1: services: - line 2: sabnzbd: - line 3: volumes: - line 4: - /volume2/sab-incomplete:/incomplete 3. Run sudo sparkbox up — SABnzbd is recreated with the SSD showing up inside it as /incomplete, next to the usual /data. 4. In SABnzbd: Config → Folders → set Temporary Download Folder to /incomplete and save. Leave the Completed Download Folder where it is (/data/downloads) so Sonarr and Radarr keep finding finished downloads exactly as before. From then on the downloading, par2 repair and unpacking all happen on the SSD, and SAB itself moves each finished job across to the spinning pool as the last step. Nothing in Sonarr/Radarr needs changing, and that media.yml stays through sparkbox update / upgrade. Why your first attempt didn't work: a bind you add on the host inside the media folder isn't visible to the containers (they see the media folder as it was when they started), so the extra mount has to be given to the container directly — which is what the override does. One honest note: I found one thing on our side that could have undone step 4 — the media wiring's re-run used to push any SAB Temporary folder that wasn't under /data back onto the pool. That's fixed as of today and is in the next update, which your box (Legend) picks up as soon as it's out. It only ever fired on a re-wire, not on a normal reboot or update, so you can set this up now. — Chris
danmacx2 wrote:
Confirmed this is now working. I look forward to the update so we no longer get [WARN] Your apps can't save files into these media folder(s): [WARN] /volume1/sparkbox-data/media/downloads/incomplete [WARN] SparkBox tried to fix this automatically and couldn't (something deeper than [WARN] folder ownership — possibly files inside owned by another user). This one [WARN] command fixes the whole tree (can take a few minutes on a large library): [WARN] sudo chown -R 1000:10 '/volume1/sparkbox-data/media' [WARN] Until this is fixed, downloads will fail with "not writable" errors in [WARN] Sonarr/Radarr and imports will silently go nowhere. When we run sparkbox up -Dan
Chris wrote:
Glad it's working. One thing to set straight so you're not waiting on something that won't come: the update I mentioned only fixes the media re-wire putting SAB's Temporary folder back on the pool. It does not touch that [WARN] — that one is sparkbox up finding that user 1000 cannot write into /volume1/sparkbox-data/media/downloads/incomplete on your NAS, and it keeps appearing until that folder is writable. Most likely it's the SSD you originally mounted at that path by hand: a mount sitting on top of the folder shows the SSD's own top level (root-owned) instead of the folder, which is the "something deeper than folder ownership" the automatic fix gave up on. Now that the override hands SAB the SSD as /incomplete, that old nested mount isn't needed: - line 1: unmount it, and remove its line from /etc/fstab (or the UGOS mount entry) if you added one - line 2: sudo chown 1000:10 /volume1/sparkbox-data/media/downloads/incomplete - line 3: sudo sparkbox up — the warning should be gone If it still shows, paste the output of ls -ld /volume1/sparkbox-data/media/downloads/incomplete and findmnt /volume1/sparkbox-data/media/downloads/incomplete and I'll take it from there. — Chris