I am having issues downloading the Media App. I set up Surfshark, followed the set-up guide, and no matter what I try I can't get pass this. Any help would be greatly appreciated. Thank you.
47 replies
SimplyRare wrote:
I am having the same issue if you figure it out please tell me and I will do the same.
SimplyRare wrote:
BRO I got mine to work by disabling my VPN (Surfshark) and doing a soft reset on SparkBox within settings
kaufman51 wrote:
Walk me through what you mean by soft reset on SparkBox within settings please.
tomspark wrote:
Thanks — and SimplyRare's onto something. 'VPN app isn't running' means SparkBox's own built-in VPN couldn't connect, so the media apps stay locked behind it. Two key things: (1) you do NOT need the Surfshark desktop app running on your computer — SparkBox uses your Surfshark service credentials directly (the username/password from Surfshark's 'Manual setup' page, not your normal account login), and having the desktop app running on the same machine can actually interfere, which is exactly what SimplyRare found by turning it off. (2) To see why it won't start, run this and paste the last ~15 lines here: sudo sparkbox logs sb-gluetun That usually says it plainly — most often it's the wrong Surfshark credentials, or an OpenVPN hiccup that clears right up by switching that VPN to WireGuard in Settings - Network - VPN. Once it goes green, the media apps unlock on their own. (@SimplyRare — that indexer 'Forbidden' is usually a Cloudflare check in front of the indexer; turning on the bundled solver in the media settings lets Prowlarr through it.)
tomspark wrote:
You're really close — yes, it's the tag. The bypass helper (FlareSolverr, and Byparr uses the same slot) is already connected to Prowlarr out of the box, but a search source only routes through it if you tag it. In Prowlarr, open that source's settings and in the Tags field add: flaresolverr — then save. That sends its requests through the bypass. (Byparr runs on the same port, so the same tag works; nothing else to change.) Give it a minute after saving, then re-test. If it still says Forbidden after tagging, go to Settings - Indexers - that source - Test and tell me exactly what it reports and I'll take it from there.
tomspark wrote:
On the speed thing: if a search source is sluggish or times out, that's almost always that source being slow or overloaded on its own end, not anything in your SparkBox setup — the quick workaround is to lean on a source that responds reliably. And kaufman51, I haven't forgotten your VPN one — whenever you get a chance, pop open the dashboard's Logs tab, pick sb-gluetun, and paste the last few lines here; I'll get the VPN sorted from there. No rush.
SimplyRare wrote:
What i do notice is that Nginx Proxy Manager (NPM), never starts up completely even from a fresh install.
SimplyRare wrote:
Okay so you're going to http://localhost:8443/ (local host can also be your device IP) On the top between Logs and Help it says Settings Upon clicking it on the far right it says Tools After clicking that, maybe scrolling down a little bit you can see Server Management, beneath that clicking Soft Reset
SimplyRare wrote:
Currently I am having issues with indexers, Prowlarr keeps saying: Unable to connect to indexer. Unexpected response status Forbidden code from indexer request Will update when I am able to fix that if at all
SimplyRare wrote:
I was unable to use my preferred Indexer (1337x) within a good enough time but rewatching his video he used the pirate bay which just worked instantly.
SimplyRare wrote:
Many thanks for responding if you mean byparr I have just enabled it and soft restarted, tried 1337 again but to the same error do you mean something else or is there possibly a tag I have to use?
SimplyRare wrote:
If no further setup is required beyond flaresolverr as byparr uses the same, then after specifying the tag flaresolverr with 1337 it still gives the error: Unable to connect to indexer. Unexpected response status Forbidden code from indexer request. Extra: flaresolverr tag is being used with thepiratebay and is currently working and installing content
tomspark wrote:
That actually tells you everything: your setup is correct and working — the proof is that the same flaresolverr tag is getting another source through and downloading fine. When one specific source keeps returning 'Forbidden' even with the bypass tag, it's that source blocking the request on its own end (usually its anti-bot hard-blocking the IP range your VPN exits from), which is outside what SparkBox controls. The one thing that sometimes gets past it: switch your VPN to a different server/location in Settings - Network - VPN (that changes your exit IP), then re-test. If it still won't connect, that source is simply blocking your VPN — nothing wrong on your side. You're all set with the sources that do connect. Nice work getting it going.
kaufman51 wrote:
I've tried doing this a couple of times and still no luck :(
kaufman51 wrote:
Run me through what you mean by "(2) To see why it won't start, run this and paste the last ~15 lines here: sudo sparkbox logs sb-gluetun" Thank you.
tomspark wrote:
No worries — let's skip the terminal entirely, there's an easier way. Open your SparkBox dashboard in a browser (the same address you log into it at, the one ending in :8443). Along the top you'll see a 'Logs' tab — click it. Then pick the VPN from the list (it's called sb-gluetun). That shows its log right there in the page — scroll to the bottom, copy the last 15 or so lines, and paste them here. That log almost always says, in plain words, why the VPN won't start. The most common reason is the Surfshark login: SparkBox needs the special username/password from Surfshark's 'Manual setup' page (not your normal Surfshark account login) — if the log says something like 'auth failed', that's it. Paste the lines and I'll tell you exactly what to change. You're not doing anything wrong — we'll get it sorted.
popuman wrote:
L337x is very slow to respond.
iBangax132 wrote:
im having the exact same issue here - cant seem to fix it - ive done the soft reboot and it didnt do anything logs from the vpn here: J2026-06-18T23:09:03.607282160Z 2026-06-19T00:09:03+01: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 im als unable to click the edit box on the vpn settings - like another post i saw. my surfshark settings seem correct - can ping the ip address it gave me... could do with some help here(newbie friendly)
tomspark wrote:
Thanks for the log — that 'i/o timeout' means the VPN connected but then couldn't look anything up, which on Surfshark is almost always the credentials. The thing that trips most people up: SparkBox doesn't use your normal Surfshark account login. On Surfshark's site, open VPN - Manual setup — that page has a separate service login (and for WireGuard, a key) that's different from your account email/password. Those are the ones SparkBox needs, and WireGuard mode tends to be the most reliable, so use that if you can. On the edit box not opening — when you click it, does nothing happen at all, or does it look greyed out? Tell me which and I'll get it sorted; that may be what's blocking you.
kaufman51 wrote:
So I uninstalled and re-installed the media app and this was the last few line: Error response from daemon: driver failed programming external connectivity on endpoint sb-gluetun (17a2cc97c8cdec1e3f71678a06bf99345c1a52edf23117bb02188ff07290d38a): Bind for 0.0.0.0:8989 failed: port is already allocated [SparkBox] Install exited with code 1. Your pending changes are preserved — review the log above, then Apply again (or untoggle the broken module from the apply bar at the bottom).
tomspark wrote:
That error is just leftover from the reinstall — a piece of the old setup is still holding onto a slot (port 8989), so the new one can't claim it. Nothing's broken, we just clear it. In your SparkBox terminal, run this one line: sudo sparkbox down && sudo sparkbox up The first part fully stops everything (which frees that slot), and the second starts it back up clean. Give it a minute or two to finish. If it STILL says 'port is already allocated' after that, reply here and I'll give you a quick one-liner to remove just the stuck piece. You're close — this is the last hurdle.
kaufman51 wrote:
How do I access the SparkBox Terminal? Sorry, I just turned 40.
tomspark wrote:
Ha, you're doing great — and good news, you can probably skip the terminal entirely. From your SparkBox dashboard, go to Settings (top bar), then Tools (over on the right), and under Server Management click Soft Reset. That restarts everything cleanly and usually clears exactly this 'port already in use' leftover — it's the same move SimplyRare used to get unstuck earlier in this thread. Give it a minute or two afterward. If the port error still shows up after that, just tell me what SparkBox is running on — a NAS, or a regular computer/mini-PC — and I'll walk you to the terminal step by step. No rush at all.
kaufman51 wrote:
No luck after the Soft Reset. I am using a UGreen NAS and I used PuTTY - SSH for the initial SparkBox set-up.
tomspark wrote:
Good — since you've got PuTTY, this is quick. Log into your NAS with PuTTY the same way you did during setup, then paste this and hit Enter: sudo docker ps --filter publish=8989 That lists whatever is currently holding that port (8989) — you'll see a container name on the left, probably something starting with sb-. Tell me the name it shows and I'll give you the exact one-liner to clear just that and restart cleanly. I'd rather see what's actually sitting on the port before we remove anything, so we don't touch the wrong piece. You're nearly there.
kaufman51 wrote:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES e55a15d7056a lscr.io/linuxserver/sonarr:latest "/init" 4 days ago Up 4 d ays 0.0.0.0:8989-8989/tcp, :::8989-8989/tcp sonarr
tomspark wrote:
That's the culprit — and good news, it's not a SparkBox piece at all. That container named 'sonarr' (the linuxserver one) is a separate, standalone Sonarr running outside SparkBox, and it's sitting on the exact port (8989) SparkBox needs for its own copy. SparkBox names all its containers with an 'sb-' prefix, so this plain 'sonarr' is one that got set up on its own — most likely a leftover from before you found SparkBox. If you didn't deliberately set up your own separate Sonarr that you want to keep, it's safe to remove (this won't touch your SparkBox setup or any downloaded media). In PuTTY: sudo docker rm -f sonarr && sudo sparkbox up That frees the port and brings SparkBox's media apps up clean. If you DID set that Sonarr up on purpose and want to keep it, tell me and we'll take a different route.
kaufman51 wrote:
[INFO] Starting SparkBox... [INFO] Active modules: core dashboard media [INFO] Prepared 2 module config dir(s) for PUID=1000 PGID=10 [INFO] .env changed since last up — recreating containers to pick up new values [+] Running 3/3 ✔ Container sb-homepage Started 1.7s ✔ Container sb-portainer Started 1.6s ✔ Container sb-npm Started 4.3s [+] Running 11/11 ✔ Container sb-bazarr Started 5.9s ✔ Container sb-deunhealth Started 3.0s ✔ Container sb-gluetun Recreated 1.0s ✔ Container sb-seerr Started 4.3s ✔ Container sb-jellyfin-media Started 3.5s ✔ Container sb-sabnzbd Recreated 2.0s ✔ Container sb-prowlarr Recreated 2.0s ✔ Container sb-radarr Recreated 2.1s ✔ Container sb-qbittorrent Recreated 2.0s ✔ Container sb-flaresolverr Recreated 2.1s ✔ Container sb-sonarr Recreated 2.0s Error response from daemon: driver failed programming external connectivity on endpoint sb-gluetun (53e007b1cdb00d6c1c427abebec98e24bd7e6b1afd23097701d706aefc19e41c): Bind for 0.0.0.0:7878 failed: port is already allocated
tomspark wrote:
Good — that one moved us forward (8989 is clear now). Same situation one step along: you've got a few of these standalone, non-SparkBox apps from before, and each is holding a port SparkBox needs (this one's 7878, Radarr's). Rather than knock them out one at a time, let's see them all at once. In PuTTY, paste this: sudo docker ps -a --format '{{.Names}} {{.Image}}' That lists every container with its name and image. Copy the whole list back here. I'll pick out the leftover non-SparkBox ones — they're the plainly-named lscr.io/linuxserver apps like the 'sonarr' we just removed (SparkBox's all start with sb-) — and give you a single command to clear them together, so you're not chasing one port at a time.
kaufman51 wrote:
sb-sonarr lscr.io/linuxserver/sonarr:4.0.17 sb-flaresolverr ghcr.io/flaresolverr/flaresolverr:v3.5.0 sb-prowlarr lscr.io/linuxserver/prowlarr:2.3.5 sb-radarr lscr.io/linuxserver/radarr:6.1.1 sb-sabnzbd lscr.io/linuxserver/sabnzbd:4.4.1 sb-qbittorrent lscr.io/linuxserver/qbittorrent:5.2.0 sb-bazarr lscr.io/linuxserver/bazarr:1.5.6 sb-jellyfin-media jellyfin/jellyfin:10.11.8 sb-gluetun qmcgaw/gluetun:v3.41.1 sb-seerr seerr/seerr:v3.2.0 sb-deunhealth qmcgaw/deunhealth:latest sb-npm jc21/nginx-proxy-manager:2.14.0 sb-portainer portainer/portainer-ce:2.42.0 sb-homepage ghcr.io/gethomepage/homepage:v1.13.1 sb-dashboard sparkbox-sparkbox-dashboard linuxserverplex-1 linuxserver/plex:1.43.2 radarr lscr.io/linuxserver/radarr:latest ugreenjellyfin-1 ugreen/jellyfin:v1 qbittorrent-app-1 ugreen/qbittorrent:v1 jellyfin-app-1 ugreen/jellyfin:v1
tomspark wrote:
Perfect, that list tells the whole story. Everything starting with sb- is SparkBox — leave all of those alone. The one causing this exact error is the leftover standalone Radarr (named just 'radarr'), the twin of the 'sonarr' we already cleared. Same safe fix: sudo docker rm -f radarr && sudo sparkbox up One heads-up on the rest of that list: you've also got your NAS's own built-in apps running — 'ugreenjellyfin-1', 'jellyfin-app-1', and 'qbittorrent-app-1' — plus a separate Plex. Those are yours, not SparkBox, and one or two might bump into SparkBox on the same ports next. Please DON'T remove those yet. Let's clear Radarr first and see how far it gets — if it stops on another port, paste me the line and we'll decide together whether to switch those off, since SparkBox now runs its own Jellyfin and qBittorrent for you.
kaufman51 wrote:
[OK] SparkBox is running! [INFO] Auto-firing arr-bootstrap in the background (~90-180s)... [INFO] Jellyfin + Seerr credentials will appear in the launcher modals when ready. Service URLs: Core Infrastructure: Nginx Proxy Manager: http://192.168.1.101:81 Portainer: http://192.168.1.101:9000 Homepage: http://192.168.1.101:3000 SparkBox Dashboard: SparkBox Dashboard: http://192.168.1.101:8443 Media Center: qBittorrent: http://192.168.1.101:8089 Prowlarr: http://192.168.1.101:8181 Sonarr: http://192.168.1.101:8989 Radarr: http://192.168.1.101:7878 Bazarr: http://192.168.1.101:6767 Jellyfin (media bundle): http://192.168.1.101:8096 Seerr: http://192.168.1.101:5055 Lidarr: http://192.168.1.101:8686 SABnzbd (Usenet): http://192.168.1.101:8186 FlareSolverr: http://192.168.1.101:8191 Byparr: http://192.168.1.101:8191 Notifiarr: http://192.168.1.101:5454 Looks like that did the trick - SparkBox VPN working, saying to work on Indexer in Prowler - 1 service need attention.
iBangax132 wrote:
They button shows the hover button but absolutely nothing happens when clicked - i reset cache and same issue nothing pops up, thanks for the support! Im pretty sure it has the correct wireguard privatekey
tomspark wrote:
Thanks for confirming — and that part's a bug on our end, not your setup. A few people have hit the Edit VPN button doing nothing (no popup) even after clearing cache, and it's already flagged to fix. To help me pin it down, one quick thing: press F12, click the 'Console' tab, then click Edit VPN once and copy any red error line that appears — paste it here. That shows exactly why the panel won't open. And if you'd rather just get the VPN running now and you have terminal access to the box, say so — I can give you the handful of lines to set your WireGuard details directly, skipping the button entirely.
iBangax132 wrote:
Ill grab that for you shortly - im running it on linux mint so I have the command line for the linux mint os?
tomspark wrote:
Yep — your Linux Mint terminal is exactly the right place, perfect. Two things from here: 1) When you get a sec, still grab that browser console error (F12 - Console tab - click Edit VPN - copy any red line). That's what pins the button bug so we can fix it. 2) To get your VPN working without the button, let's see what's set right now. In the terminal, run: grep -E 'VPN|WIREGUARD|SERVER' /opt/sparkbox/.env That lists your VPN settings (it won't print the full secret key). Paste it here and I'll tell you exactly which line to fix — for Surfshark on WireGuard it's usually the provider name, the address line, or the key format. We'll get it connected.
iBangax132 wrote:
this is the error i get: Password fields present on an insecure (http://) page. This is a security risk that allows user login credentials to be stolen. myboxip:8443 The resource at “http://myboxip/icons/wireguard.svg” preloaded with link preload was not used within a few seconds. Make sure all attributes of the preload tag are set correctly. my terminal output: MATRIXSERVERNAME=matrix.sparkbox.local VPNPROVIDER=surfshark VPNTYPE=wireguard VPNUSER= VPNPASSWORD= WIREGUARDPRIVATEKEY=2Ge1Lmkem7Wn+QKk5ngNcb20ko WIREGUARDADDRESSES=(the ip is here but i removed do you need it?) VPNENDPOINTIP= VPNENDPOINTPORT= OPENVPNCUSTOMCONFIG= SERVERCOUNTRIES=Switzerland SERVERCITIES= SERVERHOSTNAMES=
tomspark wrote:
Quick but important heads-up first: that WIREGUARDPRIVATEKEY you pasted is a private credential, and it's now public in this thread. Easy fix that makes it harmless — on Surfshark's site, open VPN - Manual setup - WireGuard and generate a NEW config; that instantly makes the old key useless. Please also edit your comment above to delete that key line. Here's the good part: that new Surfshark config gives you BOTH a fresh private key AND an 'Address'. They're a matched pair, and a mismatch there is the usual cause of the 'connects but times out' you hit. So put the new key in WIREGUARDPRIVATEKEY and the exact Address it shows into WIREGUARDADDRESSES. Edit with: sudo nano /opt/sparkbox/.env — change those two lines, save (Ctrl+O, Enter, Ctrl+X), then run sudo sparkbox restart media. Give it a minute; the rest (surfshark / wireguard / Switzerland) is already correct. On the button: thanks for grabbing that — those two console lines are just normal page warnings, not a crash. So the edit form is failing to display rather than erroring, which is a useful clue. Already flagged to fix.
iBangax132 wrote:
do i paste the ip surfshark gives me in the SBhost field or the SBDomain field? those are the only two ip fields there actually nvm i messed up :D 2 secs!
iBangax132 wrote:
okay so ive made those changes to ip and address - its still flagging as not connected
tomspark wrote:
Good — fresh key+address was the right move. Since it's still red, the VPN's own log will tell us exactly why in plain words. Run this and paste the last ~15 lines here: sudo sparkbox logs sb-gluetun --tail 20 Two common culprits it'll reveal: (1) the WIREGUARDADDRESSES needs to be the EXACT value Surfshark gave, including the /16 on the end (it should look like 10.14.0.2/16) — a missing /16 stops it routing; and (2) make sure you ran 'sudo sparkbox restart media' after saving the .env, so it actually picked up the new values. Paste the log and I'll point right at it.
iBangax132 wrote:
2026-06-19T09:45:18+01:00 INFO [vpn] DO NOT OPEN AN ISSUE UNLESS YOU HAVE READ AND TRIED EVERY POSSIBLE SOLUTION 2026-06-19T09:45:18+01:00 INFO [vpn] stopping 2026-06-19T09:45:18+01:00 INFO [vpn] starting 2026-06-19T09:45:18+01:00 INFO [firewall] allowing VPN connection... 2026-06-19T09:45:18+01:00 INFO [wireguard] Using available kernelspace implementation 2026-06-19T09:45:18+01:00 INFO [wireguard] Connecting to 84.12.51.208:51820 (changed ip used example data) 2026-06-19T09:45:18+01: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-06-19T09:45:24+01: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-06-19T09:45:24+01:00 INFO [vpn] 👉 See https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md i manually added the /16 on to the surfshark ip as it didnt come with it on was that correct?
tomspark wrote:
Yes — adding /16 was exactly right. Surfshark's WireGuard address is a /16 (it looks like 10.14.0.2/16), so good instinct. Your log tells the story: WireGuard loaded and connected to a Surfshark server, but traffic isn't actually flowing yet — that's the 'i/o timeout' on the health check. With a fresh key and the right address, the usual cause is that the specific server it landed on isn't completing the handshake. Quick fix: switch to a different Surfshark location. In your .env change SERVERCOUNTRIES=Switzerland to SERVERCOUNTRIES=Netherlands (or United States), save, then sudo sparkbox restart media. Give it a minute and watch the VPN tile. If a second country still times out, double-check that the number before the /16 exactly matches what Surfshark's config shows. We're close — it's connecting, it just needs a server that handshakes.
iBangax132 wrote:
swapped to nertherlands updated the 3 lines key/ip/location and still seeing same issue - i copy the only ip it gives me from the wireguard settings exactly and add the /16 nything else to suggest or i can send you the settings?
tomspark wrote:
Yes, send them — that'll crack it. One important thing first: do NOT paste the WIREGUARDPRIVATEKEY line again (you've already had to rotate one). Run this, which leaves the key out: grep -E 'VPNPROVIDER|VPNTYPE|WIREGUARDADDRESSES|SERVERCOUNTRIES' /opt/sparkbox/.env Here's my strong hunch from 'the only ip it gives me': Surfshark's WireGuard config actually has TWO IPs — an 'Address' that starts with 10. (like 10.14.0.2) and an 'Endpoint' that's a normal public IP. WIREGUARDADDRESSES needs the 10.x 'Address' one, NOT the endpoint. If you copied the public one, that's the whole problem — the tunnel sets up but can't route, which is exactly your i/o timeout. Paste that line and I'll confirm in one look.
iBangax132 wrote:
Thank you so much - the ip was hidden in that file which i never bothered checking so was using the public... duhhhhhhhhhh! god sake thanks so much possibly in guide suggest that its in the config file as i clearly wasnt aware enough (my fault idiot) to check it...! god damn thank you for support
tomspark wrote:
Hahaha that's the one — we've all been there. Really glad it's working now. And that's genuinely useful feedback: you're right that the steps should call out that the address lives inside the WireGuard config file, and that it's the 10.x one (not the public endpoint). I'm going to make that clearer so the next person doesn't hit the same wall. Thanks for sticking with it — enjoy the setup!