Not sure what's going on or how I messed things up, but tailscale wasn't working for me last night, and now my media stack is saying "unhealthy" on all of the statuses. Along with that, SABnzb is giving me errors about disk IO... Cant paste them because it wont start out of spark box though. Also just noticed that the tooltip on my sparkbox dashboard is saying my boxes ssd storage is completely full. any help would be appreciated. Thanks!
41 replies
tomspark wrote:
Perfect — that's the whole lot sorted. Enjoy the box, and happy self-hosting! 🎉
hairychinchilla69 wrote:
Would a fresh install of Sparkbox be my best option?
tomspark wrote:
Hold off on reinstalling — that won't fix this and you'd lose your setup for nothing. You actually already spotted the real cause: your box's drive is full. That's why everything's failing to write and looping, and why SABnzbd is throwing disk errors — it's all one root cause, not something you broke. (Notice your light apps like Pi-hole and Tailscale are fine — only the heavy media apps die, because they can't write to a full disk.) Good news: freeing space fixes the whole cascade at once. First let's see what's eating it — run: sudo df -h / && sudo du -h -d1 /opt/sparkbox/data 2/dev/null | sort -h | tail Paste that back and I'll point you at exactly what's safe to delete (usually old or failed downloads). We'll have it healthy again, no reinstall.
hairychinchilla69 wrote:
4.0K /opt/sparkbox/data/audiobooks 4.0K /opt/sparkbox/data/books 4.0K /opt/sparkbox/data/manga 4.0K /opt/sparkbox/data/music 4.0K /opt/sparkbox/data/photos 4.0K /opt/sparkbox/data/podcasts 42G /opt/sparkbox/data 42G /opt/sparkbox/data/media
tomspark wrote:
Found it — and good news, nothing's broken: that 42 GB is your real media library, and it's filled the drive right up, so the apps have no room left to even save their own settings. That's exactly why you see the disk errors and the "unhealthy" statuses. Quickest way to get them breathing again — clear out the old app versions Docker piles up after updates (this does NOT touch your media or settings): sudo docker system prune -af Give it a few seconds, then watch your dashboard tiles start going healthy again. If they don't, your library has simply outgrown this drive — run sudo df -h / and paste the line it shows me so I can see the drive size, and I'll walk you through moving your media somewhere roomier.
hairychinchilla69 wrote:
Filesystem Size Used Avail Use% Mounted on /dev/nvme0n1p2 116G 109G 1004M 100% /
hairychinchilla69 wrote:
I do have a RAID array that you helped me configure, and it was working for the last week or so. Not sure what caused Sparkbox to stop writing to it, but last night I downloaded a couple of movies and didn't notice until this morning that they had been downloaded to the SSD and not the RAID array.
tomspark wrote:
Ah, that's the key detail — thank you. Your media on the RAID array is safe, and nothing's broken. What happened: your array stopped being connected (this usually happens after a reboot), so when you grabbed those movies last night they landed on the little SSD instead of the array — and the SSD is much smaller, so it filled right to the top. We won't delete any of your media. To give you the exact, safe steps without risking anything, I need to see your drives. This command only LOOKS — it changes nothing: df -h && echo --- && lsblk && echo --- && grep MEDIAROOT /opt/sparkbox/.env Paste all of it and I'll tell you exactly how to reconnect the array, move those misplaced movies onto it so the SSD frees up, and make it stick so this stops happening on the next reboot.
hairychinchilla69 wrote:
df -h && echo --- Filesystem Size Used Avail Use% Mounted on tmpfs 1.5G 140M 1.3G 10% /run /dev/nvme0n1p2 116G 109G 1000M 100% / tmpfs 3.6G 0 3.6G 0% /dev/shm efivarfs 150K 83K 63K 58% /sys/firmware/efi/efivars none 1.0M 0 1.0M 0% /run/credentials/systemd-journald.service tmpfs 3.6G 0 3.6G 0% /tmp /dev/nvme0n1p1 1.1G 6.4M 1.1G 1% /boot/efi none 1.0M 0 1.0M 0% /run/credentials/systemd-networkd.service /dev/md0 5.5T 390G 4.8T 8% /mnt/raid1 none 1.0M 0 1.0M 0% /run/credentials/getty@tty1.service tmpfs 727M 8.0K 727M 1% /run/user/1000 none 1.0M 0 1.0M 0% /run/credentials/systemd-resolved.service lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 5.5T 0 disk └─md0 9:0 0 5.5T 0 raid1 /mnt/raid1 sdb 8:16 0 5.5T 0 disk └─md0 9:0 0 5.5T 0 raid1 /mnt/raid1 nvme0n1 259:0 0 119.2G 0 disk ├─nvme0n1p1 259:1 0 1G 0 part /boot/efi └─nvme0n1p2 259:2 0 118.2G 0 part / echo --- --- grep MEDIAROOT /opt/sparkbox/.env MEDIAROOT=/mnt/raid1 (MEDIAROOT was red here)
hairychinchilla69 wrote:
Filesystem Size Used Avail Use% Mounted on tmpfs 1.5G 140M 1.3G 10% /run /dev/nvme0n1p2 116G 109G 1000M 100% / tmpfs 3.6G 0 3.6G 0% /dev/shm efivarfs 150K 83K 63K 58% /sys/firmware/efi/efivars none 1.0M 0 1.0M 0% /run/credentials/systemd-journald.service tmpfs 3.6G 0 3.6G 0% /tmp /dev/nvme0n1p1 1.1G 6.4M 1.1G 1% /boot/efi none 1.0M 0 1.0M 0% /run/credentials/systemd-networkd.service /dev/md0 5.5T 390G 4.8T 8% /mnt/raid1 none 1.0M 0 1.0M 0% /run/credentials/getty@tty1.service tmpfs 727M 8.0K 727M 1% /run/user/1000 none 1.0M 0 1.0M 0% /run/credentials/systemd-resolved.service --- NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 5.5T 0 disk └─md0 9:0 0 5.5T 0 raid1 /mnt/raid1 sdb 8:16 0 5.5T 0 disk └─md0 9:0 0 5.5T 0 raid1 /mnt/raid1 nvme0n1 259:0 0 119.2G 0 disk ├─nvme0n1p1 259:1 0 1G 0 part /boot/efi └─nvme0n1p2 259:2 0 118.2G 0 part / --- MEDIAROOT=/mnt/raid1 Didnt realize I could run those all at once. Here is the output from the command. The MEDIAROOT at the end is in red text.
tomspark wrote:
Perfect, that tells me everything. Great news: your RAID array is healthy with 4.8 TB free, and SparkBox is pointed at it correctly (MEDIAROOT=/mnt/raid1 — the red is just your terminal highlighting the word you searched for, not an error). Your real library is safe on the array. What happened: your apps started up at a moment when the array wasn't connected yet, so they latched onto the SSD instead and kept writing there. Now that the array's back, we just restart them so they grab it: sudo sparkbox up Give it 2-3 minutes — your apps should go healthy and new downloads will land on the array, not the SSD. Once it's up, reply and we'll safely clear the leftover ~42 GB off your SSD and make sure this can't happen again on the next reboot.
hairychinchilla69 wrote:
I'm still showing unhealthy in sparkbox.
tomspark wrote:
Right — they're still unhealthy because the SSD is still full, so the apps can't even write their small settings files to come back up. Let's free real space, safely. The quick win first — this clears the old leftover app versions Docker piles up over time, and touches none of your media: sudo docker system prune -af Wait about a minute, then check your dashboard — the apps should start going healthy (and from now on, downloads land on your array, which has tons of room). That 42 GB on the SSD is just an old copy from before you set up the array — harmless, and we can tidy it onto the array later. Does prune get your apps green? If not, paste me df -h / and we'll clear more.
hairychinchilla69 wrote:
$ df -h / Filesystem Size Used Avail Use% Mounted on /dev/nvme0n1p2 116G 109G 995M 100% /
tomspark wrote:
Thanks — prune freed nothing, so there's no junk to clear; it really is that old 42 GB copy filling the SSD. Let's move it onto your array (which has 4.8 TB free). This is safe — it doesn't touch your current library and deletes nothing, it just relocates the old copy off the SSD: sudo mv /opt/sparkbox/data/media /mnt/raid1/recovered-from-ssd That copies 42 GB across, so give it several minutes and don't interrupt it — it's finished when your prompt comes back. Then check with df -h / (you should see lots of free space now), and your apps should go healthy within a minute or two — run sudo sparkbox up once more if any are still red. Your real library on the array is untouched; the old copy now lives safely at /mnt/raid1/recovered-from-ssd, so nothing's lost.
hairychinchilla69 wrote:
Okay - looks like that worked for the most part. However, qBittorrent is still doing it, and I am still having issues with Tailscale starting and crashing.
tomspark wrote:
Nice — freeing the disk was the big one. Two leftovers, both fixable: qBittorrent: while the disk was jammed full, qBit couldn't save properly and its settings file likely got scrambled — that's the loop. Give it a clean one (safe, reversible, doesn't touch your downloads): sudo docker stop sb-qbittorrent && sudo mv /opt/sparkbox/modules/media/config/qbittorrent /opt/sparkbox/modules/media/config/qbittorrent.bak && sudo sparkbox up 2-3 minutes and it should come up healthy. (If it then asks for a login you don't have, just reply — that's a known separate thing, quick fix.) Tailscale: the usual cause of that crash-loop is two switches in the Tailscale admin console. Open https://login.tailscale.com/admin/settings/features and turn ON both "HTTPS Certificates" and "Tailscale Serve". Did you get those on? If they're on and it's still crashing, paste docker logs sb-tailscale --tail 20 and I'll pinpoint it.
hairychinchilla69 wrote:
I couldn't find the Tailscale Serve feature. I did find HTTPS Certificates, though, and turned that on.
tomspark wrote:
You're good — HTTPS Certificates is the one that actually matters. "Serve" isn't a separate switch in the current Tailscale console; it just works once HTTPS Certificates are on, so you're not missing anything. Now restart Tailscale so it picks up the change: sudo sparkbox restart tailscale Give it a minute — it should settle instead of looping. If it's STILL crashing after that, paste the last few lines of: docker logs sb-tailscale --tail 20 and I'll tell you exactly what it's stuck on (usually the login key just needs refreshing). And did qBittorrent come back healthy after that reset, or is it still looping?
hairychinchilla69 wrote:
qBittorrent is fixed!! docker logs sb-tailscale --tail 20 permission denied while trying to connect to the docker API at unix:///var/run/docker.sock
tomspark wrote:
qBittorrent fixed — love it. 🎉 Nearly there. That Tailscale message isn't actually a Tailscale problem — the command just needs admin rights to read the logs. Same line with sudo in front: sudo docker logs sb-tailscale --tail 20 Paste the last few lines and I'll tell you exactly what Tailscale is stuck on. (And if it actually came back up after the restart and isn't crashing anymore, even better — just say so.)
hairychinchilla69 wrote:
2026/05/25 03:41:02 control: LoginInteractive - regen=true 2026/05/25 03:41:02 control: doLogin(regen=true, hasUrl=false) 2026/05/25 03:41:03 control: control server key from https://controlplane.tailscale.com: ts2021=[fSeS+], legacy=[nlFWp] 2026/05/25 03:41:03 control: Generating a new nodekey. 2026/05/25 03:41:03 control: RegisterReq: onode= node=[MXQGi] fup=false nks=false
tomspark wrote:
That log is the answer: Tailscale's login key has run out, so when the container restarted it couldn't log back in — that's the loop. The key you first set up with was a one-time key; we'll swap in a reusable one so it survives restarts from now on. Two steps: 1. Make a new key: go to https://login.tailscale.com/admin/settings/keys, click "Generate auth key," turn ON "Reusable," create it, and copy it (it starts with tskey-auth-). 2. Give it to SparkBox and restart — paste this, swapping PASTEKEYHERE for the key you just copied: sudo sed -i 's^TSAUTHKEY=.TSAUTHKEY=PASTEKEYHERE' /opt/sparkbox/.env && sudo sparkbox up A minute later Tailscale should go healthy and stay connected. That's the last piece of your puzzle!
hairychinchilla69 wrote:
Looks like that worked. Thank you so much! One last thing - can you help me get rid of this
tomspark wrote:
That's the whole thing sorted — nice work sticking with it! 🎉 That tile is the WireGuard VPN app, which is separate from Tailscale. Since Tailscale is handling your remote access now, you don't need it — switch it off and the tile disappears: sudo sparkbox disable vpn (If you actually did want WireGuard running too, just say so and we'll set it up properly instead of removing it.) One optional thing while I've got you: the disk mix-up from earlier could happen again on a reboot, if your RAID array isn't guaranteed to connect before the apps start. Want me to walk you through a quick change that locks that down so it can't recur? No pressure — everything's working as it is.
hairychinchilla69 wrote:
Yeah, if you wouldn't mind walking me through making sure this doesn't happen again, that would be awesome. Would enabling WireGuard again be redundant?
tomspark wrote:
Glad it's all working! 🎉 On WireGuard: yep, redundant — Tailscale already gives you secure remote access into the box, so WireGuard would just be a second door doing the same job. Leaving it off (where you put it) is the clean choice, no downside. Now the reboot-proofing. The goal is simple: guarantee your RAID array is connected before the apps start, so they can never land on the SSD again. First let me see how your array mounts at boot — this only looks, it changes nothing: grep -i raid /etc/fstab Paste what it shows (or say "nothing" if it comes back blank), and I'll give you the exact little change to lock it in.
hairychinchilla69 wrote:
UUID=3338b03e-dd95-4c43-a797-3cfdd8eb6e77 /mnt/raid1 ext4 defaults,nofail 0 2
tomspark wrote:
Perfect — your array's already set to auto-mount with the safety flag (nofail), so the only missing piece is telling the apps to wait for it. This one-liner does that — it makes Docker hold off until the array is mounted, so a reboot can never start your apps on the empty SSD again: sudo mkdir -p /etc/systemd/system/docker.service.d && printf '[Unit]\nRequiresMountsFor=/mnt/raid1\n' | sudo tee /etc/systemd/system/docker.service.d/wait-for-raid.conf && sudo systemctl daemon-reload That's it — no reboot needed right now, it kicks in automatically on your next one. (Bonus: if the array ever genuinely isn't there, your apps will wait for it rather than silently filling the SSD — and the box still boots fine so you can sort it out.) That wraps the whole thing up — disk, qBittorrent, Tailscale, and now reboot-proofed. Nice work hanging in there! 🎉
hairychinchilla69 wrote:
sudo mkdir -p /etc/systemd/system/docker.service.d && printf '[Unit]\nRequiresMountsFor=/mnt/raid1\n' | sudo tee /etc/systemd/system/docker.service.d/wait-for-raid.conf && sudo systemctl daemon-reload [Unit] RequiresMountsFor=/mnt/raid1 Getting this when inputting that command line.
tomspark wrote:
That's exactly right — no error there. Those two lines are just the command showing you what it saved into the file, and the rest ran silently because it worked. You're all set: Docker will now wait for your array on every boot, so the disk mix-up can't happen again. That's the whole thing wrapped up — disk, qBittorrent, Tailscale, the WireGuard tile, and now reboot-proofed. Enjoy the box! 🎉
hairychinchilla69 wrote:
Thanks!! The WireGuard tile is still showing after running: sudo sparkbox disable vpn Not a big concern, but I don't think that command worked
tomspark wrote:
No worries — purely cosmetic, and easy to check. Run this (it re-runs the disable and then shows whether WireGuard is actually still running): sudo sparkbox disable vpn; echo ---; sudo docker ps --format '{{.Names}}' | grep -i wg || echo '(no wireguard container running)' If it ends with '(no wireguard container running)', then it DID work and the tile is just a stale leftover in your browser — a hard refresh (Ctrl+Shift+R) clears it. If WireGuard is still listed there, paste me the output and I'll knock it out directly.
hairychinchilla69 wrote:
No luck getting it to go away - I'm not super concerned about it, though.
tomspark wrote:
All good — it's genuinely harmless to leave (just a leftover tile; nothing's running or using resources). But if you'd like it gone, this clears the leftover for good: sudo docker rm -f sb-wg-easy (If that says "No such container," even better — it means it's already gone.) Then hard-refresh the dashboard with Ctrl+Shift+R; and if it still clings on, sudo sparkbox restart dashboard clears the cached tile. No worries either way — nothing's broken, and everything else you fixed is solid.
hairychinchilla69 wrote:
Perfection
hairychinchilla69 wrote:
New issue - whenever I open seer, it starts as signed out, and then when I sign in, it stays signed in for about 5 seconds and then kicks me out.
tomspark wrote:
Ha — one last boss. Good news: this is a known one and it's nothing you did. When Seerr signs you back out after a few seconds, it's almost always Seerr losing track of your login after all the restarts we just did. A clean restart of the media apps sorts it, and it doesn't touch any of your settings: sudo sparkbox restart media Give it 2-3 minutes, then open Seerr and sign in again — it should stick this time. If it STILL boots you out after that, tell me how you're opening Seerr (the dashboard tile, or an address you type in) and I'll nail down the last bit.
hairychinchilla69 wrote:
It looks like that worked!
tomspark wrote:
Boom — that's every last piece sorted: the full disk, qBittorrent, Tailscale, the leftover tile, and now Seerr. Genuinely impressive patience working through all of it with me. Enjoy the box and happy self-hosting!
tomspark wrote:
Heads up — 1.6.466 just shipped and should cover what you reported here. Grab it with sudo sparkbox upgrade (that is the one that moves you to a new release — update only refreshes app images), and let me know if it's sorted — or if you're still hitting it.