Into your library: 1 finished download couldn't be moved into your library — that's why it doesn't show up in Jellyfin.Restart the Media apps from the Apps page — SparkBox repairs folder permissions on startup, which fixes the most common cause. If it stays stuck, ask Tom's community and mention "stuck import".
50 replies
tomspark wrote:
Did the restart get the file to show up in Jellyfin? If it's still stuck, it's a permissions issue. Run these two commands: sudo chown -R $(id -u):$(id -g) /data && sudo chmod -R 775 /data Then restart the media apps again. That fixes it 99% of the time. Let me know if it's still stuck after that.
hotdogtown wrote:
chmod: cannot access '/data': No such file or directory It was working earlier before a restart to try to fix the AI.
tomspark wrote:
Ah, /data isn't mounted anymore — likely unmounted during restart. Your files are safe; we just need to remount them. Can you run two quick checks and share output? (1) df -h to see mounted drives, (2) ls -la /opt/sparkbox/data to check SparkBox's folder. That'll show us where your media went and how to reconnect it.
hotdogtown wrote:
Filesystem Size Used Avail Use% Mounted on udev 3.6G 0 3.6G 0% /dev tmpfs 740M 5.1M 735M 1% /run /dev/mmcblk0p6 3.9G 2.2G 1.6G 59% /ugreen /dev/mmcblk0p1 256M 136M 121M 53% /boot /dev/mmcblk0p2 2.0G 1.1G 706M 62% /rootfs /dev/loop0 756M 756M 0 100% /rootfs/base /dev/loop1 83M 83M 0 100% /rootfs/kernel /dev/loop2 136M 136M 0 100% /rootfs/apt /dev/loop3 149M 149M 0 100% /rootfs/fw /dev/loop4 1.0M 1.0M 0 100% /rootfs/oem overlay 47G 903M 44G 2% / tmpfs 3.7G 1.1M 3.7G 1% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock efivarfs 128K 40K 84K 33% /sys/firmware/efi/efivars tmpfs 3.7G 7.5M 3.7G 1% /tmp /dev/mmcblk0p7 47G 903M 44G 2% /overlay /dev/mmcblk0p3 8.6M 39K 7.8M 1% /mnt/factory tmpfs 1.0G 0 1.0G 0% /var/lib/nginx /dev/mapper/ugAC09271780912211pool1-volume1 39T 557G 38T 2% /volume1 /dev/mapper/ugAC09271780912211pool1-volume1 39T 557G 38T 2% /home /dev/mapper/ugAC09271780917879pool2-volume1 917G 16G 900G 2% /volume2 tmpfs 740M 0 740M 0% /run/user/1000 ls -la /opt/sparkbox/data total 32 drwxr-xr-x 8 hotdogtown 1000 4096 Jul 15 10:37 . drwxr-xr-x 12 hotdogtown 1000 4096 Jul 15 14:53 .. drwxr-xr-x 2 hotdogtown 1000 4096 Jul 15 10:37 audiobooks drwxr-xr-x 2 hotdogtown 1000 4096 Jul 15 10:37 books drwxr-xr-x 2 hotdogtown 1000 4096 Jul 15 10:37 manga drwxr-xr-x 6 hotdogtown 1000 4096 Jul 15 10:37 media drwxr-xr-x 2 hotdogtown 1000 4096 Jul 15 10:37 photos drwxr-xr-x 2 hotdogtown 1000 4096 Jul 15 10:37 podcasts
tomspark wrote:
Good news from that paste — your data folder is totally fine. Everything's there (movies, tv, etc) and owned correctly. That /data path from before doesn't actually exist on your box directly, it's just the name used inside the apps, so that command wasn't pointed at the right spot. Nothing broken there. For the one stuck download itself: open Sonarr or Radarr (whichever grabbed it) and check the Activity Queue tab. If it's stuck there's usually a small warning icon next to it explaining why the import failed. Can you paste what that says?
hotdogtown wrote:
I would but now Sonarr, Radarr and Qbit are down in the pipeline even after multi restarts.
tomspark wrote:
Hey, no data lost, don't worry - this can happen after a bunch of restarts back to back. Can you run this and paste exactly what it prints: sudo docker ps -a | grep -Ei 'sonarr|radarr|qbit' That'll show if they're actually crashed (says Exited or Restarting) or just being slow to come back up. Once I see that I'll know the next step.
hotdogtown wrote:
bash: radarr: command not found bash: qbit: command not found
tomspark wrote:
Ah, I see what happened - "radarr" and "qbit" were just short names inside that command, not something to type on their own. Copy the whole line together and paste it in as one piece: sudo docker ps -a | grep -Ei 'sonarr|radarr|qbit' Hit enter after pasting that whole thing, then send back everything it prints. That'll tell us if those three are actually crashed or just slow to come back up after the restarts.
hotdogtown wrote:
ec115b00dbde lscr.io/linuxserver/sonarr:4.0.19 "/init" 15 minutes ago Up 14 minutes (healthy) sb-sonarr 9479e5dd7eba lscr.io/linuxserver/qbittorrent:5.2.3 "/init" 15 minutes ago Up 14 minutes (healthy) sb-qbittorrent ab8ca2d896b0 lscr.io/linuxserver/radarr:6.3.0 "/init" 15 minutes ago Up 14 minutes (healthy)
tomspark wrote:
Good news — all three are actually up and healthy in that output, nothing's crashed. They were probably just slow catching back up after those restarts. Now let's get back to the actual stuck download: open Sonarr or Radarr (whichever grabbed that file), go to Activity Queue, and look for a small warning icon next to the stuck item. Click it and paste what it says — that'll tell us exactly why it won't move into your library.
hotdogtown wrote:
Sonarr won't open even though it says it's healthy. I don't have the files anymore, as I did a reset yesterday. So these are two issues to solve.
tomspark wrote:
Ah, if you ran the reset command (not just a restart/update), that explains the missing files — a full reset is designed to wipe everything, so that part isn't a bug, sorry it caught you off guard. For Sonarr: what do you actually see when you try to open it — a blank white page, a spinner that never finishes, or an error message? And since the reset, have you gone through setup again to reconnect your library? That'll tell us which of the two things we're actually dealing with.
hotdogtown wrote:
One movie says this: Downloaded - Unable to import automatically.
tomspark wrote:
That message just means Sonarr grabbed the file but couldn't match it up to move it into your library - nothing lost. Click right on that line in the queue (or the little warning icon next to it) and there's usually a longer explanation underneath - can you paste that part? And separately, when you try to open Sonarr itself, what do you actually see: a blank page, a spinner that never finishes, or an error message?
hotdogtown wrote:
I didnt reset exactly; I just deleted the files I had before I reinstalled Media Centre. For Sonarr: the broswer cannot connect to the server.
hotdogtown wrote:
For this file is the only one that downloaded it just says Movie title mismatch, automatic import not possible, manual required. Fro Sonarr its just a blank "problem loading page" screen on firefox.
tomspark wrote:
That message just means Sonarr couldn't automatically match the file name to the right movie - nothing's broken, it just needs a quick manual nudge. Click that line in the queue, look for a "Manual Import" option, and pick the correct movie from the list, then hit import. For Sonarr not loading: instead of typing the address yourself, open your SparkBox dashboard and click Sonarr from the Apps page there - after a reinstall the address/port can shift. If it still shows "problem loading page" from the dashboard link too, let me know exactly what that page says.
hotdogtown wrote:
Unable to connect Firefox can’t connect to the server at 192.168.1.41:8989 What can you do about it? The site could be temporarily unavailable or too busy. Try again in a few moments. If you are unable to load any pages, check your computer’s network connection. If your computer or network is protected by a firewall or proxy, make sure that Firefox is permitted to access the web.
tomspark wrote:
That's a straight connection-refused, not a loading problem, so Sonarr likely isn't actually running after the reinstall. Can you run this and paste exactly what it prints: sudo docker ps -a | grep -i sonarr. That'll show whether it's crashed, stuck restarting, or never came back up, and we can go from there.
hotdogtown wrote:
ec115b00dbde lscr.io/linuxserver/sonarr:4.0.19 "/init" 2 hours ago Up 2 hours (healthy) sb-sonarr
tomspark wrote:
Good news, Sonarr's actually running fine - that healthy status confirms it's up. The problem is just how you're getting to it: that direct address (192.168.1.41:8989) can go stale after a reinstall since the port or IP can shift. Instead, open the SparkBox dashboard and click into Sonarr from the Apps page there - that always points at wherever it's actually running. Try that and let me know if it opens.
hotdogtown wrote:
This information is comming from when I click it on the launcher.
hotdogtown wrote:
The app page only takes you to "media Centre"
tomspark wrote:
Ah, that's my bad steer — sorry. There are two different pages: the "Apps" page is just for installing/removing things, it doesn't have working launch links yet. The actual click-to-open buttons for each app live on your dashboard's Home page instead. Go to Home, look for the Sonarr tile there, and click that one. Let me know what you see when it opens.
hotdogtown wrote:
Seer says: Unable to connect to Sonarr. Some information may be unavailable.
tomspark wrote:
That message means the app that showed it to you (Seerr) has lost its connection to Sonarr - common after a reinstall, since Sonarr can get a fresh connection code. Open Seerr itself (not the SparkBox dashboard) and go into its own Settings, then find the Sonarr entry - there's usually a broken or red icon next to it. Click into that entry and hit Save (re-enter the address if it asks you to). That refreshes the link. Let me know what you see there.
hotdogtown wrote:
This is what I am doing on the dashboard. I am not manually entering.
tomspark wrote:
Got it, thanks. Just to double check we're talking about the same page - when you say "the dashboard," do you mean Seerr's own settings page (the one listing services like Sonarr, Radarr etc), not the SparkBox Home page? If so, click right on the Sonarr row there - it should pop open an edit box with the address already filled in. Hit Save without changing anything and tell me if it turns green or still shows red.
hotdogtown wrote:
There is no red icon. The test fails to connect. I cant save without changing parameters.
tomspark wrote:
Good news, that actually points right at the fix: the address is fine, but the password Seerr has saved for Sonarr is old, probably left over from before you reinstalled. Open Sonarr itself, go to Settings General, and copy the API Key shown there (there's a little copy icon next to it). Back in Seerr's Sonarr entry, paste that over whatever's in the API Key box now, then hit Test again. If it turns green you can save it as-is.
hotdogtown wrote:
I cant open Sonarr.
tomspark wrote:
Got it - let's make sure we're testing the right link. On your SparkBox Home page (not the Apps page, not a bookmarked address), find the Sonarr tile and click straight on it. What happens: does it open Sonarr's page, show the same connection error as before, or something else? If it opens fine there, the API key step from before should work. If it still won't connect even from that tile, that tells us the problem is on SparkBox's side, not your browser.
hotdogtown wrote:
Clicking on the Sonarr icon on the dashboard launcher it takes me to the dead firefox page.
tomspark wrote:
Good, that rules out your browser and the bookmark - the dashboard link is going to the right place, so this points at something on our side after the reinstall. Can you try one thing: run sudo docker restart sb-gluetun, wait about a minute, then click the Sonarr tile again. That's the container handling the VPN connection for the media apps, and restarting just that one sometimes clears this up. If Sonarr loads normally after that, Seerr should reconnect too - if it still shows the same error, let me know.
hotdogtown wrote:
This is also happening with SABnzdb the same thing when I went to check why nothing was downloading on Radarr it says: All download clients are unavailable due to failures
tomspark wrote:
That actually fits together with what we're checking - Sonarr, Radarr, SABnzbd and qBittorrent all sit behind that same VPN piece, so if it's blocking outside access it'll take all of them down together, not just Sonarr. Go ahead and try the restart I mentioned (sudo docker restart sb-gluetun), give it about a minute, then check Radarr's download clients again. If they all come back green at once that confirms it - if not, let me know and we'll dig further.
hotdogtown wrote:
Now nothing will open apart from bazarr. I see on the dashboard glutun has restarted x12 recently.
tomspark wrote:
Good catch - if it's restarted 12 times on its own, one more manual restart probably won't stick since something keeps making it crash, not just get stuck. Can you run this and paste back what it prints: sudo docker logs sb-gluetun --tail 50 That'll show the actual reason it keeps stopping (usually a clear error line near the bottom). Once we know why it keeps crashing we can fix that directly instead of restarting it over and over - everything behind it should come back once that's sorted.
hotdogtown wrote:
├── Storage settings: | └── Filepath: /gluetun/servers.json ├── OS Alpine settings: | ├── Process UID: 1000 | ├── Process GID: 1000 | └── Timezone: asia/shanghai ├── Public IP settings: | ├── IP file path: /tmp/gluetun/ip | ├── Public IP data base API: ipinfo | └── Public IP data backup APIs: | ├── ifconfigco | ├── ip2location | └── cloudflare └── Version settings: └── Enabled: yes 2026-07-16T17:38:34+08:00 INFO [routing] default route found: interface eth0, gateway 172.20.4.1, assigned IP 172.20.4.2 and family v4 2026-07-16T17:38:34+08:00 INFO [routing] adding route for 0.0.0.0/0 2026-07-16T17:38:34+08:00 INFO [firewall] setting allowed subnets... 2026-07-16T17:38:34+08:00 INFO [routing] default route found: interface eth0, gateway 172.20.4.1, assigned IP 172.20.4.2 and family v4 2026-07-16T17:38:34+08:00 INFO [routing] adding route for 192.168.0.0/16 2026-07-16T17:38:34+08:00 INFO [routing] adding route for 10.0.0.0/8 2026-07-16T17:38:34+08:00 INFO [routing] adding route for 172.16.0.0/12 2026-07-16T17:38:34+08:00 INFO [firewall] setting allowed input port 8989 through interface eth0... 2026-07-16T17:38:34+08:00 INFO [firewall] setting allowed input port 7878 through interface eth0... 2026-07-16T17:38:34+08:00 INFO [firewall] setting allowed input port 9696 through interface eth0... 2026-07-16T17:38:34+08:00 INFO [firewall] setting allowed input port 8686 through interface eth0... 2026-07-16T17:38:34+08:00 INFO [firewall] setting allowed input port 8080 through interface eth0... 2026-07-16T17:38:34+08:00 INFO [firewall] setting allowed input port 8191 through interface eth0... 2026-07-16T17:38:34+08:00 INFO [firewall] setting allowed input port 6767 through interface eth0... 2026-07-16T17:38:34+08:00 INFO [dns] using plaintext DNS at address 1.1.1.1 2026-07-16T17:38:34+08:00 INFO [healthcheck] listening on 127.0.0.1:9999 2026-07-16T17:38:34+08:00 INFO [http server] http server listening on [::]:8000 2026-07-16T17:38:34+08:00 INFO [firewall] allowing VPN connection... 2026-07-16T17:38:34+08:00 INFO [wireguard] Using available kernelspace implementation 2026-07-16T17:38:34+08:00 INFO [wireguard] Connecting to 118.99.2.52:51820 2026-07-16T17:38:34+08:00 INFO [wireguard] Wireguard setup is complete. Note Wireguard is a silent protocol and it may or may not work, without giving any error message. Typically i/o timeout errors indicate the Wireguard connection is not working. 2026-07-16T17:38:40+08:00 WARN [vpn] restarting VPN because it failed to pass the healthcheck: startup check: all check tries failed: parallel attempt 1/2 failed: dialing: dial tcp4: lookup github.com: i/o timeout, parallel attempt 2/2 failed: dialing: dial tcp4: lookup cloudflare.com: i/o timeout 2026-07-16T17:38:40+08:00 INFO [vpn] 👉 See https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md 2026-07-16T17:38:40+08:00 INFO [vpn] DO NOT OPEN AN ISSUE UNLESS YOU HAVE READ AND TRIED EVERY POSSIBLE SOLUTION 2026-07-16T17:38:40+08:00 INFO [vpn] stopping 2026-07-16T17:38:41+08:00 INFO [vpn] starting 2026-07-16T17:38:41+08:00 INFO [firewall] allowing VPN connection... 2026-07-16T17:38:41+08:00 INFO [wireguard] Using available kernelspace implementation 2026-07-16T17:38:41+08:00 INFO [wireguard] Connecting to 156.146.45.151:51820 2026-07-16T17:38:41+08:00 INFO [wireguard] Wireguard setup is complete. Note Wireguard is a silent protocol and it may or may not work, without giving any error message. Typically i/o timeout errors indicate the Wireguard connection is not working. 2026-07-16T17:38:41+08:00 INFO [dns] downloading hostnames and IP block lists 2026-07-16T17:38:41+08:00 INFO [dns] DNS server listening on [::]:53 2026-07-16T17:38:41+08:00 INFO [dns] ready 2026-07-16T17:38:42+08:00 INFO [ip getter] Public IP address is 156.146.45.152 (Hong Kong, Hong Kong, Hong Kong - source: ipinfo+ifconfig.co+ip2location+cloudflare) 2026-07-16T17:38:42+08:00 INFO [vpn] You are running the latest release v3.41.1
tomspark wrote:
Found it - those logs show the VPN restarting because it briefly couldn't reach the internet for a health check, then it reconnected to a different server on its own (that part's actually working as designed, not a crash). But if it's done that 12 times, the server it keeps landing on might just be flaky right now. Try this: edit /opt/sparkbox/.env, find the line starting with SERVERCOUNTRIES, and change it to a country closer to you that isn't Hong Kong (Singapore or Japan are good picks), save it, then run sudo docker restart sb-gluetun. That should land it on a steadier server, and Sonarr/Radarr/qBittorrent/SABnzbd should all come back once it holds.
hotdogtown wrote:
Getting error: no "edit" mailcap rules found for type "application/octet-stream"
tomspark wrote:
Ah, that's on me - "edit" wasn't meant to be typed as its own command, I just meant open and change that file. Instead run this exact line: sudo nano /opt/sparkbox/.env That opens a simple text editor right in the terminal. Use the arrow keys to get to the SERVERCOUNTRIES line, change the country, then press Ctrl+O then Enter to save, and Ctrl+X to exit. After that, run sudo docker restart sb-gluetun again like before.
hotdogtown wrote:
Ok this is weird. When I switched to Singapore, Sonarr and Radarr opened, but Prowlarr and SABnzd didn't, and no downloads are happening. When I changed to Japan, Sonarr won't open, nor will SABnzd, but Prowlarr will, and still nothing is downloading. I checked the system on Radarr; it says: All download clients are unavailable due to failures. I also note sb-npm has stopped. Is there a way to remove glutun and vpn? I think this is the issue?
tomspark wrote:
Pulling gluetun out isn't something to do right now - it's built into how those apps reach the internet, so it's not a simple switch to flip, and it would also turn off the privacy protection those apps use. Since sb-npm stopping is new and different from the VPN piece, let's get the full picture instead of chasing one app at a time: run sudo docker ps -a and paste back the whole list. That'll show exactly what's up, down, or restarting right now so we know what we're really dealing with.
hotdogtown wrote:
Will be great when this is fixed. ├── Storage settings: | └── Filepath: /gluetun/servers.json ├── OS Alpine settings: | ├── Process UID: 1000 | ├── Process GID: 1000 | └── Timezone: asia/shanghai ├── Public IP settings: | ├── IP file path: /tmp/gluetun/ip | ├── Public IP data base API: ipinfo | └── Public IP data backup APIs: | ├── ifconfigco | ├── ip2location | └── cloudflare └── Version settings: └── Enabled: yes 2026-07-16T17:38:34+08:00 INFO [routing] default route found: interface eth0, gateway 172.20.4.1, assigned IP 172.20.4.2 and family v4 2026-07-16T17:38:34+08:00 INFO [routing] adding route for 0.0.0.0/0 2026-07-16T17:38:34+08:00 INFO [firewall] setting allowed subnets... 2026-07-16T17:38:34+08:00 INFO [routing] default route found: interface eth0, gateway 172.20.4.1, assigned IP 172.20.4.2 and family v4 2026-07-16T17:38:34+08:00 INFO [routing] adding route for 192.168.0.0/16 2026-07-16T17:38:34+08:00 INFO [routing] adding route for 10.0.0.0/8 2026-07-16T17:38:34+08:00 INFO [routing] adding route for 172.16.0.0/12 2026-07-16T17:38:34+08:00 INFO [firewall] setting allowed input port 8989 through interface eth0... 2026-07-16T17:38:34+08:00 INFO [firewall] setting allowed input port 7878 through interface eth0... 2026-07-16T17:38:34+08:00 INFO [firewall] setting allowed input port 9696 through interface eth0... 2026-07-16T17:38:34+08:00 INFO [firewall] setting allowed input port 8686 through interface eth0... 2026-07-16T17:38:34+08:00 INFO [firewall] setting allowed input port 8080 through interface eth0... 2026-07-16T17:38:34+08:00 INFO [firewall] setting allowed input port 8191 through interface eth0... 2026-07-16T17:38:34+08:00 INFO [firewall] setting allowed input port 6767 through interface eth0... 2026-07-16T17:38:34+08:00 INFO [dns] using plaintext DNS at address 1.1.1.1 2026-07-16T17:38:34+08:00 INFO [healthcheck] listening on 127.0.0.1:9999 2026-07-16T17:38:34+08:00 INFO [http server] http server listening on [::]:8000 2026-07-16T17:38:34+08:00 INFO [firewall] allowing VPN connection... 2026-07-16T17:38:34+08:00 INFO [wireguard] Using available kernelspace implementation 2026-07-16T17:38:34+08:00 INFO [wireguard] Connecting to 118.99.2.52:51820 2026-07-16T17:38:34+08:00 INFO [wireguard] Wireguard setup is complete. Note Wireguard is a silent protocol and it may or may not work, without giving any error message. Typically i/o timeout errors indicate the Wireguard connection is not working. 2026-07-16T17:38:40+08:00 WARN [vpn] restarting VPN because it failed to pass the healthcheck: startup check: all check tries failed: parallel attempt 1/2 failed: dialing: dial tcp4: lookup github.com: i/o timeout, parallel attempt 2/2 failed: dialing: dial tcp4: lookup cloudflare.com: i/o timeout 2026-07-16T17:38:40+08:00 INFO [vpn] 👉 See https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md 2026-07-16T17:38:40+08:00 INFO [vpn] DO NOT OPEN AN ISSUE UNLESS YOU HAVE READ AND TRIED EVERY POSSIBLE SOLUTION 2026-07-16T17:38:40+08:00 INFO [vpn] stopping 2026-07-16T17:38:41+08:00 INFO [vpn] starting 2026-07-16T17:38:41+08:00 INFO [firewall] allowing VPN connection... 2026-07-16T17:38:41+08:00 INFO [wireguard] Using available kernelspace implementation 2026-07-16T17:38:41+08:00 INFO [wireguard] Connecting to 156.146.45.151:51820 2026-07-16T17:38:41+08:00 INFO [wireguard] Wireguard setup is complete. Note Wireguard is a silent protocol and it may or may not work, without giving any error message. Typically i/o timeout errors indicate the Wireguard connection is not working. 2026-07-16T17:38:41+08:00 INFO [dns] downloading hostnames and IP block lists 2026-07-16T17:38:41+08:00 INFO [dns] DNS server listening on [::]:53 2026-07-16T17:38:41+08:00 INFO [dns] ready 2026-07-16T17:38:42+08:00 INFO [ip getter] Public IP address is 156.146.45.152 (Hong Kong, Hong Kong, Hong Kong - source: ipinfo+ifconfig.co+ip2location+cloudflare) 2026-07-16T17:38:42+08:00 INFO [vpn] You are running the latest release v3.41.1 hotdogtown@RevGT:~$ edit /opt/sparkbox/.env Warning: unknown mime-type for "/opt/sparkbox/.env" -- using "application/octet-stream" Error: no "edit" mailcap rules found for type "application/octet-stream" hotdogtown@RevGT:~$ edit /opt/sparkbox/.env Warning: unknown mime-type for "/opt/sparkbox/.env" -- using "application/octet-stream" Error: no "edit" mailcap rules found for type "application/octet-stream" hotdogtown@RevGT:~$ sudo nano /opt/sparkbox/.env hotdogtown@RevGT:~$ sudo docker restart sb-gluetun sb-gluetun hotdogtown@RevGT:~$ sudo nano /opt/sparkbox/.env hotdogtown@RevGT:~$ sudo docker restart sb-gluetun sb-gluetun hotdogtown@RevGT:~$ sudo nano /opt/sparkbox/.env hotdogtown@RevGT:~$ sudo docker restart sb-gluetun sb-gluetun hotdogtown@RevGT:~$ run sudo docker ps - bash: run: command not found hotdogtown@RevGT:~$ sudo docker ps -a [sudo] password for hotdogtown: CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 3c05d17699e7 tailscale/tailscale:v1.98.8 "/usr/local/bin/cont…" 4 hours ago Up 16 minutes (healthy) sb-tailscale 6080a324643e lscr.io/linuxserver/sabnzbd:4.4.1 "/init" 4 hours ago Up 16 minutes (healthy) sb-sabnzbd ec115b00dbde lscr.io/linuxserver/sonarr:4.0.19 "/init" 4 hours ago Up 16 minutes (healthy) sb-sonarr df768a5aa7eb ghcr.io/flaresolverr/flaresolverr:v3.5.0 "/usr/bin/dumb-init …" 4 hours ago Up 16 minutes (healthy) sb-flaresolverr 9479e5dd7eba lscr.io/linuxserver/qbittorrent:5.2.3 "/init" 4 hours ago Up 16 minutes (healthy) sb-qbittorrent a3d5ca9af0c7 lscr.io/linuxserver/prowlarr:2.4.0 "/init" 4 hours ago Up 16 minutes (healthy) sb-prowlarr a960e28975b9 lscr.io/linuxserver/lidarr:3.1.0 "/init" 4 hours ago Up 16 minutes (healthy) sb-lidarr ab8ca2d896b0 lscr.io/linuxserver/radarr:6.3.0 "/init" 4 hours ago Up 16 minutes (healthy) sb-radarr b94bf29ce013 qmcgaw/gluetun:v3.41.1 "/gluetun-entrypoint" 4 hours ago Up 16 minutes (healthy) 0.0.0.0:7878-7878/tcp, [::]:7878-7878/tcp, 8000/tcp, 0.0.0.0:8191-8191/tcp, [::]:8191-8191/tcp, 8388/tcp, 0.0.0.0:8686-8686/tcp, [::]:8686-8686/tcp, 0.0.0.0:8989-8989/tcp, [::]:8989-8989/tcp, 8888/tcp, 8388/udp, 0.0.0.0:8089-8080/tcp, [::]:8089-8080/tcp, 0.0.0.0:8186-8081/tcp, [::]:8186-8081/tcp, 0.0.0.0:8181-9696/tcp, [::]:8181-9696/tcp sb-gluetun 10db04030381 jellyfin/jellyfin:10.11.11 "/jellyfin/jellyfin" 4 hours ago Up 16 minutes (healthy) 0.0.0.0:8096-8096/tcp, [::]:8096-8096/tcp
tomspark wrote:
Good news: all your containers show healthy in that output. But here's what's concerning — sb-npm (Nginx Proxy Manager, a core SparkBox service) isn't showing up in your docker ps list. That's the piece that handles routing to those apps. It being gone while everything else says healthy explains why apps won't open even though containers are running. That points at something deeper with how the system recovered after the reinstall. I'm flagging this to the team for investigation — hold tight.
tomspark wrote:
Actually good news buried in that paste: everything in your docker ps -a list right now (Sonarr, Radarr, qBittorrent, SABnzbd, Prowlarr, the VPN piece, Jellyfin) shows Up 16 minutes and healthy. So it may already be sorted since that last restart - go check the dashboard now and see if things open and if a download actually moves. One thing that stands out separately: sb-npm doesn't show up anywhere in that list at all, not even as stopped, which is its own issue unrelated to the VPN piece. Can you run this on its own and paste exactly what it says: sudo docker ps -a | grep npm
hotdogtown wrote:
1. So Sonarr, SABnzb still wont open as the original issue. Nothign Downloading, Dashboard pipeline still Saying VPN issue. 2. sudo docker ps -a | grep npm: f0543ae02055 jc21/nginx-proxy-manager:2.15.1 "/init" 4 hours ago Up 24 minutes (healthy) 0.0.0.0:81-81/tcp, [::]:81-81/tcp, 0.0.0.0:8080-80/tcp, [::]:8080-80/tcp, 0.0.0.0:8444-443/tcp, [::]:8444-443/tcp sb-npm
tomspark wrote:
Good news first: sb-npm is up and healthy, so scratch that off the list entirely - false alarm on my end. For Sonarr/SABnzbd still not opening: everything showing "healthy" in docker ps just means the container started up okay, it doesn't mean the VPN connection inside is actually solid right now. Can you do a hard refresh on the SparkBox dashboard page (Ctrl+Shift+R) and tell me exactly what the VPN status area says at this exact moment? That'll tell us if it's stuck showing an old error or if it's genuinely still down.