Having set the media server up on a UGreen NAS - I have to say it’s working like a dream!! Top job guys 👍🏻 Couple of questions though - in terms of Indexes, any advice as I’ve tried for a couple of series and no results are found.. I’ve only gone with a few public torrents - any advice on bettering this? Been reading about NZB files - if this is a good option and if so, any recommendations? My main question though is around data repositories.. By default the setup has gone onto volume 1 (which is what I wanted as that’s a 1TB SSD). What I want to do is move the files to Volume 2 which has 16 TB HDD available. I read somewhere that this setting is in the env file in the docker container but can’t find it. Any help would be really appreciated TIA
11 replies
Chris wrote:
Not a wasted minute — and good instinct spotting that other thread. You don't have to guess at either path. Over SSH run: sudo sparkbox doctor It prints where SparkBox is installed, and under [Media Storage] your live Media Root plus its free space — that's the new folder. On a UGREEN the old default is /volume1/sparkbox-data/media. PuTTY is the right call here. Copy rather than move: sudo rsync -a /volume1/sparkbox-data/media/ /volume2/sparkbox-data/media/ Swap that second path for whatever doctor printed as your Media Root. It's the same copy SparkBox uses internally. Leave the originals in place until Jellyfin lists everything, then run sudo sparkbox check-media-perms. — Chris
Chris wrote:
Good news — that one has a specific cause, and the restart hint won't reach it. Moving Media Root is the classic trigger: the new folders on volume2 end up not writable by the app user, so Sonarr and Radarr finish a download and then can't file it. The rsync I gave you carries volume1's ownership across, which can do exactly that. Over PuTTY: sudo sparkbox check-media-perms It runs the test as the app user rather than as root, so the answer is meaningful, then prints the exact fix for your box — the ACL form adds access without changing who owns your files, so UGOS's own file manager keeps working. Paste the output back if it's not obvious. — Chris
Chris wrote:
Nothing on the SparkBox side is holding those 16. That figure isn't a saved list — the strip asks Sonarr and Radarr for their live queue on every refresh, so it drops on its own as each item files itself. Give it a while and watch the number rather than touching the files by hand. If it's still 16 later, the safe nudge is sudo sparkbox restart media. That only bounces the media apps — nothing on disk changes, and the permission that was blocking them is already fixed. And your puzzle has a plain answer: the download folder always was writable, which is why they finished. It was the move into Movies and TV that failed. — Chris
Chris wrote:
Great to hear it's flying on the UGREEN — and /volume2 is exactly what Media Root is built for. In your dashboard open Settings → Media and set Media Root to your volume2 path. Keep it space-free, or the bind mounts fail silently. Saving rebuilds the media stack and creates Movies/TV/Music/downloads there with the right ownership. It repoints rather than moves, so copy your existing files across first. Indexers live in Prowlarr → Indexers → Add Indexer. Having only a couple is usually why searches return nothing — more sources, more results. SparkBox ships none and doesn't recommend specific ones; pick sources you're entitled to use. SABnzbd is a download client, not an indexer, so Usenet needs your own provider and indexer accounts. — Chris
Chris wrote:
Correcting my own answer before you start moving anything. Saving Media Root does repoint everything at volume2, but the dashboard cannot finish preparing the new folders. It reports success, and then the apps quietly cannot write there. So do it in this order. Set Media Root to your volume2 path and save. Then, over SSH on the NAS itself, run: sudo sparkbox up That is the step that actually creates Movies, TV, Music and downloads on volume2 with the right permissions, and it will report the media apps coming back up. Copy your library across once that has finished, so it lands in folders that are already set up correctly. Sorry for the half-answer. Tom knows about this gap. — Chris
gudlad wrote:
Thanks Chris - feel like i wasted your time there, sorry. Having spent a good hour last night reading posts and not finding anything I put this post on. Having clicked post I started browsing and came across a post 9 hours ago asking the same thing.. Typical. I followed that and managed to move it and all looks good. My only issue now is locating the old folder, the new folder and moving the files.. (this is coming from someone who spends all day working on a windows PC. Assuming I need to do this via putty as I can’t browse to the files/folders in the NAS file browser
gudlad wrote:
Belting.. Thank you so much Chris.. really need to get my head round linux command line.. Worked an absolute treat. Time to migrate existing media.. And get my head round indexers.. Thanks again..
gudlad wrote:
Keeping this in the same thread - all worked last night both then this morning I noticed an error against “Into your library” with the message “ Into your library: 16 finished downloads couldn't be moved into your library — that's why they don't show up in Jellyfin. Restart the Media apps — SparkBox repairs folder permissions on startup, which fixes the most common cause. If it stays stuck, ask Tom's community and mention "stuck import"” Any ideas? I noticed there was an update to 1.6.482 which I applied but still the same error.
gudlad wrote:
So looks like permissions were the issue which seems odd as the app appeared to have the correct permissions last night given it would write to the folder. Applied fix suggested and got the green tick. ✅ So happy days. Will it sort out the 16 finished downloads it mentioned - or are they stuck in the ether and I need to do something with them?
gudlad wrote:
So I feel like I've opened a can of worms here.. As I said earlier I ran the permissions command and I got the green tick - all seemed to be good. However, an hour or so later it had gone back to the red cross for the "Into your library" with the same message about 16 files.. I checked the permissions again and the message was that it couldn't write to the location and to run the permissions command.. which I did and I still get the same result when I check the permissions. Still with 16 files stuck somewhere.. The really funny thing is that if I go to Seerr and request something then the request is successful and the download ends up in the correct folder on Vol2 (which tests say it can't write to). Happy to leave it as it's working but I'm wondering about these files it says it can't copy as I can't find them anywhere.
Chris wrote:
Those 16 aren't loose files — they're rows in Sonarr's and Radarr's own queue, each carrying the error that blocked it. That's why nothing turns up on disk, and opening one names the exact folder it couldn't write into. That also explains the Seerr puzzle: the check tests every existing title folder, not just the top level. A new request creates a folder as the app user, so it imports fine — while the folders rsync carried over from volume1 kept volume1's ownership and still refuse. Could you paste the check-media-perms output? I want to see whether it says setfacl isn't installed: the fallback it prints instead isn't built to survive UGOS's own permission resets, which fits green, then red an hour later. — Chris