Sorry for the deluge of text, but the AI thought it was worth sending your way. I'm afraid the issue still persists after the recommended fix. VPN has a problem ? 🌐 — IP — qBit probe failed Kill switch at risk ✗ Tunnel down Progress — gluetun started this time. But the tunnel isn't up yet. Run: sparkbox logs sb-gluetun Paste the last 20-30 lines. At this point it's most likely one of: - WIREGUARDADDRESSES mismatch — your config shows /24 but TorGuard sometimes issues /32 addresses. Worth double-checking your TorGuard WG config file for the exact address. - Bad endpoint — 146.70.49.74:1443 needs to be reachable from your box - WIREGUARDPUBLICKEY not matching the server endpoint The logs will tell us exactly which one. Paste them and we'll nail it. 2026-06-07T00:49:35Z 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-07T00:49:35Z INFO [vpn] 👉 See https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md 2026-06-07T00:49:35Z INFO [vpn] DO NOT OPEN AN ISSUE UNLESS YOU HAVE READ AND TRIED EVERY POSSIBLE SOLUTION 2026-06-07T00:49:35Z INFO [vpn] stopping 2026-06-07T00:49:36Z INFO [vpn] starting 2026-06-07T00:49:36Z INFO [firewall] allowing VPN connection... 2026-06-07T00:49:36Z INFO [wireguard] Using available kernelspace implementation 2026-06-07T00:49:36Z INFO [wireguard] Connecting to 89.187.182.71:51820 2026-06-07T00:49:36Z 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-07T00:49:42Z 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-07T00:49:42Z INFO [vpn] 👉 See https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md 2026-06-07T00:49:42Z INFO [vpn] DO NOT OPEN AN ISSUE UNLESS YOU HAVE READ AND TRIED EVERY POSSIBLE SOLUTION 2026-06-07T00:49:42Z INFO [vpn] stopping 2026-06-07T00:49:42Z INFO [vpn] starting 2026-06-07T00:49:42Z INFO [firewall] allowing VPN connection... 2026-06-07T00:49:42Z INFO [wireguard] Using available kernelspace implementation 2026-06-07T00:49:42Z INFO [wireguard] Connecting to 193.29.61.160:51820 2026-06-07T00:49:42Z 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-07T00:49:48Z 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 cloudflare.com: i/o timeout, parallel attempt 2/2 failed: dialing: dial tcp4: lookup github.com: i/o timeout 2026-06-07T00:49:48Z INFO [vpn] 👉 See https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md 2026-06-07T00:49:48Z INFO [vpn] DO NOT OPEN AN ISSUE UNLESS YOU HAVE READ AND TRIED EVERY POSSIBLE SOLUTION 2026-06-07T00:49:48Z INFO [vpn] stopping 2026-06-07T00:49:48Z INFO [vpn] starting 2026-06-07T00:49:48Z INFO [firewall] allowing VPN connection... 2026-06-07T00:49:48Z INFO [wireguard] Using available kernelspace implementation 2026-06-07T00:49:48Z INFO [wireguard] Connecting to 94.140.11.29:51820 2026-06-07T00:49:48Z 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. Two things jump out here: 1. It's connecting to random endpoints like 89.187.182.71, 193.29.61.160, 94.140.11.29:51820 — none of which match your VPNENDPOINTIP=146.70.49.74 and VPNENDPOINTPORT=1443. It's ignoring your endpoint entirely and pulling from a server list somewhere. 2. WireGuard connects but DNS lookups time out every time — classic sign the tunnel is up but traffic isn't flowing through it, usually a wrong public key or mismatched addresses. The random endpoints suggest gluetun isn't reading VPNENDPOINTIP/VPNENDPOINTPORT from your env. Double-check these two things: 1. Confirm the keys are actually in .env exactly as written: grep -E "VPNENDPOINT|VPNSERVICEPROVIDER" /opt/sparkbox/.env 2. Check if the media compose is overriding anything: grep -E "VPNENDPOINT|SERVER" /opt/sparkbox/modules/media/docker-compose.yml My hunch is either the compose file has hardcoded server values that are winning over your .env, or VPNENDPOINTIP has a typo in the key name. Paste both outputs and we'll sort it. $ sudo grep -E "VPNENDPOINT|SERVER" /opt/sparkbox/modules/media/docker-compose.yml SERVERCOUNTRIES: SERVERCITIES: prompt: "Optional: comma-separated city names to narrow gluetun's server pick within the country. Useful when SERVERCOUNTRIES is huge (US/Canada/Russia) and gluetun otherwise picks a server far from you. Pick 2-3 cities near you for low-latency with fallback. Leave blank to let gluetun pick anywhere in the country." SERVERHOSTNAMES: - SERVERCOUNTRIES=${SERVERCOUNTRIES:-United States} - SERVERCITIES=${SERVERCITIES:-} - SERVERHOSTNAMES=${SERVERHOSTNAMES:-} - SERVERREGIONS=${SERVERREGIONS:-} - HEALTHSERVERADDRESS=127.0.0.1:9999 There it is: - SERVERCOUNTRIES=${SERVERCOUNTRIES:-United States} That's the culprit. The compose file has a default fallback — if SERVERCOUNTRIES is blank in .env, it falls back to United States. So gluetun gets SERVERCOUNTRIES=United States no matter what you put in .env, and then goes hunting for a US server from its built-in list instead of using your custom endpoint. This is a SparkBox bug — the default fallback makes sense for named providers but breaks custom. Workaround for now: You can't fix the compose file directly (it'll get overwritten on update), but you can force the value to something gluetun will accept as empty for custom. Edit /opt/sparkbox/.env: Actually — the cleanest fix here is to set a dummy override. Create a file at: /opt/sparkbox/modules/media/docker-compose.override.yml With this content: services: sb-gluetun: environment: - SERVERCOUNTRIES= - SERVERCITIES= - SERVERHOSTNAMES= - SERVERREGIONS= Then: sparkbox restart media That override file will blank out the defaults and let your custom endpoint take over. I'd also hit the 'Share to demox' button below so Tom can fix that fallback default to not apply when VPNSERVICEPROVIDER=custom — that's worth a patch.
15 replies
tomspark wrote:
Love hearing that, and genuinely, thanks for sticking with it through all the back-and-forth. TorGuard over OpenVPN can be fiddly and you pushed right through it. Your downloads are routed through the VPN and your tile's back, so you're all set. A couple of the rough edges you hit along the way (the VPN tile needing the media module re-ticked, and that session-log spam) are flagged to Tom to smooth out so the next person has an easier ride. Enjoy the setup, and shout if anything else comes up.
tomspark wrote:
Thanks for the detailed logs, that's genuinely helpful, and sorry the first fix didn't land. The telling part is gluetun connecting to random servers (89.187..., 193.29...) instead of your TorGuard endpoint, then DNS timing out every time. That means it's pulling from a built-in provider's server list rather than using your custom endpoint, so the SERVERCOUNTRIES tweak alone was never going to be enough. One check points the way. Run: grep -E "VPNPROVIDER|VPNTYPE" /opt/sparkbox/.env If VPNPROVIDER isn't set to torguard, that's the gap, gluetun does support TorGuard by name. Paste that line back and I'll give you the exact value to change before you touch anything, so we're not guessing. We've also flagged the custom-endpoint side of this to get patched properly, so thanks for surfacing it.
popuman wrote:
$ sudo grep -E "VPNPROVIDER|VPNTYPE" /opt/sparkbox/.env VPNTYPE=wireguard popuman@zb2-sparkbox
tomspark wrote:
That's the smoking gun, thank you. See how the grep returned VPNTYPE=wireguard but NO VPNPROVIDER line at all? With that line missing, SparkBox quietly falls back to NordVPN, so gluetun goes hunting for Nord servers your TorGuard keys can't log into, which is exactly the random-endpoint loop in your log. The fix is one line. Add VPNPROVIDER=torguard (gluetun knows TorGuard by name), then restart: echo 'VPNPROVIDER=torguard' | sudo tee -a /opt/sparkbox/.env && sudo sparkbox restart media Your TorGuard WireGuard key and address from setup stay exactly as they are. Give it a minute and the VPN light should go green. If it's still red, grab a fresh sb-gluetun log and we'll finish it off.
popuman wrote:
Did as requested. Now gluetun is unhealthy. SparkBox v1.6.196 - Self-Hosted Privacy Stack Created by Tom Spark | youtube.com/@TomSparkReviews Environment: NAS (generic) [INFO] Starting SparkBox... [INFO] Active modules: core dashboard files media tailscale [INFO] .env changed since last up — recreating containers to pick up new values [+] up 3/3 ✔ Container sb-npm Started 4.3s ✔ Container sb-portainer Started 4.2s ✔ Container sb-homepage Started 4.2s [+] up 1/1 ✔ Container sb-filebrowser Started 0.9s [+] up 12/12 ✔ Container sb-jellyfin-media Recreated 1.6s ✘ Container sb-gluetun Error dependency gluetun failed to start 9.5s ✔ Container sb-deunhealth Recreated 0.5s ✔ Container sb-bazarr Recreated 4.0s ✔ Container sb-seerr Recreated 1.7s ✔ Container sb-sonarr Recreated 6.2s ✔ Container sb-sabnzbd Recreated 4.4s ✔ Container sb-prowlarr Recreated 5.9s ✔ Container sb-lidarr Recreated 7.1s ✔ Container sb-radarr Recreated 6.2s ✔ Container sb-qbittorrent Recreated 4.1s ✔ Container sb-flaresolverr Recreated 0.8s dependency failed to start: container sb-gluetun is unhealthy [+] up 1/1 ✔ Container sb-tailscale Started
tomspark wrote:
Good, that's actually a step forward, not back. "Unhealthy" here just means gluetun is now genuinely trying TorGuard (instead of the wrong NordVPN it was using before) but the tunnel hasn't passed its connection check yet. Nothing's broken and your other apps are fine. One log and we'll see exactly why: sudo docker logs sb-gluetun --tail 25 Paste that back and I'll read it, it shows whether it's reaching a TorGuard server now and the specific reason it's not connecting. We're close.
popuman wrote:
For the record, it was previously set as custom. $ sudo docker logs sb-gluetun --tail 25 @...-@@ @@@@.@@.@@@ @@@ @@@@@@=======@@@=@@@@ @@@@@@@@ @@@.-%@.+@@@@@@@@ @@@@@%============@@@@ @@@.--@..@@@@.-@@@@@@@==============@@@@ @@@@ @@@-@--@@.@@.---@@@@@==============@@@@@ @@@ @@@.@@-@@.@@--@@@@@===============@@@@@@ @@@@.@--@@@@@@@@@@================@@@@@@@ @@@..--@@@@@@@@================@@@@+@@ @@@.---@@.@@@@=================@@@@--@@ @@@-.---@@@@@@================@@@@--@@@ @@@.:-@@@@@@===============@@@@.---@@ @@@.-------.@@@============@@@@@@.--@@@ @@@..--------:@@@=========@@@@@@@@.--@@@ @@@.-@@@@@@@@@@@========@@@@@ @@@.--@@ @@.@@@@===============@@@@@ @@@@@@---@@@@@@ @@@@@@@==============@@@@@@@@@@@@@---@@@@@@@@ @@@@@@=============@@@@@ @@@...------------.@@@ @@@@%===========@@@@@@ @@@..------@@@@.-----.-@@@ @@@@@@.=======@@@@@@ @@@.-------@@@@@@-.------=@@ @@@@@@@@@===@@@@@@ @@.------@@@@ @@@@.-----@@@ @@@==@@@=@@@@@@@ @@@.-@@@@@@@ @@@@@@@--@@ @@@@@@@@@@@@@ @@@@@@@@ @@@@@@@ @@@@@@@@ @@@@ @@@@ 2026-06-07T01:54:19Z ERROR VPN settings: provider settings: VPN provider name is not valid for Wireguard: value is not one of the possible choices: torguard must be one of airvpn, custom, fastestvpn, ivpn, mullvad, nordvpn, protonvpn, surfshark or windscribe 2026-06-07T01:54:19Z INFO Shutdown successful
tomspark wrote:
That log nails it, thank you, and it shows the torguard tip I gave you was wrong, sorry about that. See the line "name is not valid for Wireguard"? The VPN engine SparkBox uses only knows a fixed list of providers, and TorGuard isn't one of them. You were right to have it on custom before, but custom mode needs one more piece that SparkBox doesn't wire up yet, so TorGuard can't fully connect right now. That's a gap on our end, not anything you did, and I've flagged it to get fixed properly. If you want privacy working today, the quickest path is a provider the engine supports out of the box, Mullvad, Proton, or Surfshark all just work. Surfshark's the one we test against, and there's a deal on now (87% off + 4 months free): https://get.surfshark.net/affc?offerid=1126&affid=9447&affsub=hr52es
popuman wrote:
i'll try openvpn on torguard.. i already pay for that service. you should include torguard in your wireguard providers list.
tomspark wrote:
Good call, that's the right instinct. TorGuard does work with our VPN engine over OpenVPN, it's only the WireGuard list that leaves it out, and that list is the engine's, not something we can add to on our end. The proper fix we're building is a custom path that'll let you bring TorGuard's WireGuard setup later. For the OpenVPN route, open /opt/sparkbox/.env and set these four (use your TorGuard VPN username/password, which TorGuard shows in your account area, sometimes different from your website login): VPNTYPE=openvpn VPNPROVIDER=torguard VPNUSER=your-torguard-username VPNPASSWORD=your-torguard-password Then run sudo sparkbox restart media. Give it a minute and the VPN light should go green. If it doesn't, grab a fresh sb-gluetun log and I'll read it.
popuman wrote:
Sorry for the deluge but this is how I managed to get torguard's vpn working. Logs below: Yeah fair enough, let's just switch to OpenVPN — often more reliable with custom providers anyway. You'll need from TorGuard: - Your TorGuard username and password - An OpenVPN config file (.ovpn) — download one from TorGuard's client area for whatever server/country you want Once you have the .ovpn file, here's what to set in /opt/sparkbox/.env: VPNSERVICEPROVIDER=custom VPNTYPE=openvpn OPENVPNCUSTOMCONFIG=/gluetun/custom.conf OPENVPNUSER=your-torguard-username OPENVPNPASSWORD=your-torguard-password Then copy the .ovpn file to gluetun's config directory: sudo cp your-torguard-config.ovpn /opt/sparkbox/modules/media/config/gluetun/custom.conf Confirm the path exists first: ls /opt/sparkbox/modules/media/config/gluetun/ If the gluetun folder doesn't exist: sudo mkdir -p /opt/sparkbox/modules/media/config/gluetun/ Then: sparkbox restart media Then test: docker exec sb-gluetun wget -qO- https://ipinfo.io Should return a TorGuard IP this time. Paste the logs if it doesn't and we'll go from there. SparkBox v1.6.196 - Self-Hosted Privacy Stack Created by Tom Spark | youtube.com/@TomSparkReviews Environment: NAS (generic) [INFO] Starting SparkBox... [INFO] Active modules: core dashboard files media tailscale [+] up 3/3 ✔ Container sb-npm Running 0.0s ✔ Container sb-portainer Running 0.0s ✔ Container sb-homepage Running 0.0s [+] up 1/1 ✔ Container sb-filebrowser Running 0.0s [+] up 14/14 ✔ Network sparkboxsbmediainternal Created 0.1s ✔ Network sparkboxsbmedia Created 0.1s ✘ Container sb-gluetun Error dependency gluetun failed to start 4.5s ✔ Container sb-seerr Started 1.7s ✔ Container sb-bazarr Started 1.6s ✔ Container sb-deunhealth Started 1.2s ✔ Container sb-jellyfin-media Started 1.7s ✔ Container sb-prowlarr Created 0.3s ✔ Container sb-flaresolverr Recreated 0.4s ✔ Container sb-radarr Created 0.3s ✔ Container sb-sabnzbd Created 0.3s ✔ Container sb-sonarr Created 0.4s ✔ Container sb-lidarr Recreated 0.5s ✔ Container sb-qbittorrent Created 0.4s dependency failed to start: container sb-gluetun is unhealthy [+] up 1/1 ✔ Container sb-tailscale Running 0.0s popuman@zb2-sparkbox:/opt/sparkbox/modules/media $ sudo docker exec sb-gluetun wget -qO- https://ipinfo.io Error response from daemon: Container 0a2f7b849b2eb5121d15f251c73db7928d99274ea3088e3d3a4e0ae3fb3b37eb is restarting, wait until the container is running gluetun is crash-looping. Get the logs fast: docker logs sb-gluetun --tail 30 Most likely cause: the OPENVPNCUSTOMCONFIG path is wrong or the .ovpn file isn't there yet. Let's verify: ls /opt/sparkbox/modules/media/config/gluetun/ Paste both outputs and we'll know exactly what's wrong. $ sudo docker logs sb-gluetun --tail 30 @@@@@@ @@@@.@@ @@@@@@@@@@ @@@@.@@@ @@@@@@@@==@@@@ @@@.@..@@ @@@@@@@=@..==@@@@ @@@@ @@@.@@.@@ @@@@@@===@@@@.=@@@ @...-@@ @@@@.@@.@@@ @@@ @@@@@@=======@@@=@@@@ @@@@@@@@ @@@.-%@.+@@@@@@@@ @@@@@%============@@@@ @@@.--@..@@@@.-@@@@@@@==============@@@@ @@@@ @@@-@--@@.@@.---@@@@@==============@@@@@ @@@ @@@.@@-@@.@@--@@@@@===============@@@@@@ @@@@.@--@@@@@@@@@@================@@@@@@@ @@@..--@@@@@@@@================@@@@+@@ @@@.---@@.@@@@=================@@@@--@@ @@@-.---@@@@@@================@@@@--@@@ @@@.:-@@@@@@===============@@@@.---@@ @@@.-------.@@@============@@@@@@.--@@@ @@@..--------:@@@=========@@@@@@@@.--@@@ @@@.-@@@@@@@@@@@========@@@@@ @@@.--@@ @@.@@@@===============@@@@@ @@@@@@---@@@@@@ @@@@@@@==============@@@@@@@@@@@@@---@@@@@@@@ @@@@@@=============@@@@@ @@@...------------.@@@ @@@@%===========@@@@@@ @@@..------@@@@.-----.-@@@ @@@@@@.=======@@@@@@ @@@.-------@@@@@@-.------=@@ @@@@@@@@@===@@@@@@ @@.------@@@@ @@@@.-----@@@ @@@==@@@=@@@@@@@ @@@.-@@@@@@@ @@@@@@@--@@ @@@@@@@@@@@@@ @@@@@@@@ @@@@@@@ @@@@@@@@ @@@@ @@@@ 2026-06-07T02:48:32Z ERROR VPN settings: OpenVPN settings: user is empty 2026-06-07T02:48:32Z INFO Shutdown successful popuman@zb2-sparkbox:/opt/sparkbox/modules/media $ ls /opt/sparkbox/modules/media/config/gluetun/ custom.conf servers.json popuman@zb2-sparkbox:/opt/sparkbox/modules/media $ The config file is there. The problem is OPENVPNUSER is empty — gluetun isn't reading it from .env. Check if it's actually set: grep "OPENVPNUSER\|OPENVPNPASSWORD\|VPNTYPE\|VPNSERVICEPROVIDER" /opt/sparkbox/.env My guess is one of two things: - OPENVPNUSER is missing or blank in .env - VPNTYPE is still set to wireguard instead of openvpn Paste the key names/values (mask the password if you want) and we'll fix it. Once .env looks right, run: sparkbox restart media $ sudo sparkbox up / | | | | ) \ \| ' \ / | '| |/ / \ / \ \/ / ) | |) | (| | | | <| |) | () < |/| ./ \,|| ||\\/ \//\\ || SparkBox v1.6.196 - Self-Hosted Privacy Stack Created by Tom Spark | youtube.com/@TomSparkReviews Environment: NAS (generic) [INFO] Starting SparkBox... [INFO] Active modules: core dashboard files media tailscale [INFO] Prepared 2 module config dir(s) for PUID=1000 PGID=1000 [INFO] .env changed since last up — recreating containers to pick up new values [+] up 3/3 ✔ Container sb-npm Started 4.3s ✔ Container sb-portainer Started 4.3s ✔ Container sb-homepage Started 4.4s [+] up 1/1 ✔ Container sb-filebrowser Started 0.9s [+] up 14/14 ✔ Network sparkboxsbmediainternal Created 0.1s ✔ Network sparkboxsbmedia Created 0.1s ✘ Container sb-gluetun Error dependency gluetun failed to start 5.9s ✔ Container sb-deunhealth Started 1.3s ✔ Container sb-bazarr Started 2.7s ✔ Container sb-seerr Started 1.9s ✔ Container sb-jellyfin-media Started 2.1s ✔ Container sb-qbittorrent Created 0.3s ✔ Container sb-lidarr Recreated 0.5s ✔ Container sb-radarr Created 0.3s ✔ Container sb-sabnzbd Created 0.3s ✔ Container sb-prowlarr Created 0.4s ✔ Container sb-flaresolverr Recreated 0.5s ✔ Container sb-sonarr Created 0.3s dependency failed to start: container sb-gluetun is unhealthy [+] up 1/1 ✔ Container sb-tailscale Started 1.3s popuman@zb2-sparkbox:/opt/sparkbox/modules/media Still failing. Get the new error: docker logs sb-gluetun --tail 10 That ASCII art takes up most of the output — just need the last few lines after it where the actual error is. Bet it's still user is empty or a new complaint about the config file format. 2026-06-07T02:55:15Z ERROR VPN settings: OpenVPN settings: user is empty 2026-06-07T02:55:15Z INFO Shutdown successful Still user is empty. The .env change isn't being read. Let's see exactly what's in there: grep "OPENVPN" /opt/sparkbox/.env $ grep "OPENVPN" /opt/sparkbox/.env OPENVPNCUSTOMCONFIG=/gluetun/custom.conf OPENVPNUSER=popuman OPENVPNPASSWORD= Ok the values are there. Let's check what's actually getting passed to the container: docker inspect sb-gluetun | grep -i "openvpn" My hunch is VPNTYPE is still set to wireguard in .env so gluetun is ignoring the OpenVPN settings entirely. Check: grep "VPNTYPE\|VPNSERVICEPROVIDER" /opt/sparkbox/.env $ sudo docker inspect sb-gluetun | grep -i "openvpn" "VPNTYPE=openvpn", "OPENVPNUSER=", "OPENVPNPASSWORD=", "OPENVPNENDPOINTIP=", "OPENVPNENDPOINTPORT=", "OPENVPNPROTOCOL=udp", "OPENVPNUSERSECRETFILE=/run/secrets/openvpnuser", "OPENVPNPASSWORDSECRETFILE=/run/secrets/openvpnpassword", "OPENVPNVERSION=2.6", "OPENVPNVERBOSITY=1", "OPENVPNFLAGS=", "OPENVPNCIPHERS=", "OPENVPNAUTH=", "OPENVPNPROCESSUSER=root", "OPENVPNMSSFIX=", "OPENVPNCUSTOMCONFIG=", "PRIVATEINTERNETACCESSOPENVPNENCRYPTIONPRESET=", "OPENVPNCERT=", "OPENVPNKEY=", "OPENVPNCLIENTCRTSECRETFILE=/run/secrets/openvpnclientcrt", "OPENVPNCLIENTKEYSECRETFILE=/run/secrets/openvpnclientkey", "OPENVPNENCRYPTEDKEY=", "OPENVPNENCRYPTEDKEYSECRETFILE=/run/secrets/openvpnencryptedkey", "OPENVPNKEYPASSPHRASE=", "OPENVPNKEYPASSPHRASESECRETFILE=/run/secrets/openvpnkeypassphrase", "org.opencontainers.image.description": "VPN client in a thin Docker container for multiple VPN providers, written in Go, and using OpenVPN or Wireguard, DNS over TLS, with a few proxy servers built-in.", popuman@zb2-sparkbox:/opt/sparkbox/modules/media $ sudo grep "VPNTYPE\|VPNSERVICEPROVIDER" /opt/sparkbox/.env VPNSERVICEPROVIDER=custom VPNTYPE=openvpn popuman@zb2-sparkbox:/opt/sparkbox/modules/media $ There's the problem. Look at the inspect output: "OPENVPNUSER=", "OPENVPNCUSTOMCONFIG=", Both empty — despite being set in .env. The compose file is hardcoding these as empty values, overriding whatever's in .env. The .env values are being ignored. Check the compose file: grep -n "OPENVPNUSER\|OPENVPNCUSTOMCONFIG\|OPENVPNPASSWORD" /opt/sparkbox/modules/media/docker-compose.yml Bet they're defined like this with no variable substitution: - OPENVPNUSER= - OPENVPNPASSWORD= - OPENVPNCUSTOMCONFIG= If so, change them to: - OPENVPNUSER=${OPENVPNUSER} - OPENVPNPASSWORD=${OPENVPNPASSWORD} - OPENVPNCUSTOMCONFIG=${OPENVPNCUSTOMCONFIG} Then sparkbox restart media. This is a SparkBox compose file issue — hit 'Share to demox' after so Tom can patch these variables in properly for custom provider OpenVPN support.
tomspark wrote:
Ah, I see exactly what went sideways, and it's not your fault. The steps you followed used gluetun's own variable names (OPENVPNUSER, OPENVPNCUSTOMCONFIG, VPNSERVICEPROVIDER), but SparkBox uses its OWN names and fills gluetun in for you. That's why the container shows OPENVPNUSER empty even though you set it, SparkBox never reads that line. In /opt/sparkbox/.env, delete the OPENVPN and VPNSERVICEPROVIDER lines you added, and use exactly these four: VPNTYPE=openvpn VPNPROVIDER=torguard VPNUSER=popuman VPNPASSWORD=your-torguard-password Picking torguard by name means you don't need the .ovpn file at all. Then sudo sparkbox restart media and the VPN light should go green. If gluetun still complains, grab docker logs sb-gluetun --tail 15 and I'll read it.
popuman wrote:
Looks kite it’s working, but the VPN status is not showing up on the dashboard. So I think this is also a dashboard display bug. Here are the logs: vpn status not showing up on dashboard The dashboard logs show a session-file rename error that's spamming pretty hard — but that's a separate issue. For the VPN tile specifically, the most likely cause is that only core and dashboard modules are enabled, and the media module (which contains gluetun) isn't running. Check what's actually up: docker ps | grep gluetun If nothing comes back, gluetun isn't running — the VPN tile has nothing to poll. If you haven't enabled the media module yet, do it from the dashboard Modules page, or: sparkbox up media If gluetun is running but the tile still shows nothing, run: sparkbox logs sb-gluetun --tail 30 Paste what you get and I can tell you exactly what's wrong. --- Also flagging those session rename errors in your logs — they're a dashboard bug (the session file gets deleted mid-write during reaping). Not crashing anything right now, but it's Tom's code so I'm not 100% sure it's harmless long-term. If it keeps happening or you start getting kicked out of the dashboard randomly, hit the "Share to demox" button so Tom can ship a fix. $ sudo docker ps | grep gluetun [sudo] password for popuman: a64028eac735 qmcgaw/gluetun:v3.41.1 "/gluetun-entrypoint" 44 minutes ago Up 44 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 popuman@zb2-sparkbox:~ OK so gluetun is running healthy. The tile polling issue is on the dashboard side then. Quick fix — just restart the dashboard: sparkbox restart dashboard Then hard refresh the browser (Ctrl+Shift+R or Cmd+Shift+R on Mac). The VPN tile should pick up gluetun's status after that. If it's still blank after the restart, check what IP the dashboard thinks gluetun is on: docker inspect sb-gluetun | grep -i ipaddress Paste that and I'll dig further. But 9 times out of 10 a dashboard restart clears this. sudo docker inspect sb-gluetun | grep -i ipaddress "IPAddress": "172.20.4.4", "IPAddress": "172.20.5.2", That's normal — two IPs just means gluetun is on two networks (the media stack network + sbproxy). That's not the problem. Try the restart first if you haven't yet: sparkbox restart dashboard Hard refresh after. If the tile is still blank, tell me exactly what it shows — grey/blank, spinner, an error icon, or something else. That'll tell me whether it's a polling failure or a display bug. Also worth confirming: which dashboard version are you on? Check Settings in the dashboard or run: sparkbox version If it's stale, a sparkbox update might just fix it outright — Tom's shipped a few VPN tile fixes in recent versions. Still not showing VPN status. $ sudo sparkbox version SparkBox v1.6.196 You're on the latest so it's not a stale version thing. Let me check what the dashboard is actually getting when it polls gluetun. Run this from the box: curl -s http://172.20.4.4:8000/v1/vpn/status And also try the other IP: curl -s http://172.20.5.2:8000/v1/vpn/status Paste both responses. Port 8000 is gluetun's control API — if the dashboard can't reach it there, the tile stays blank. Also check if port 8000 is actually exposed on the container. From your docker ps output earlier I can see 8000/tcp is listed but without a host mapping (no 0.0.0.0: in front of it) — that's correct, it should only be internal. So if those curls fail it's a network routing issue between dashboard and gluetun containers. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update curl -s http://172.20.4.4:8000/v1/vpn/status && curl -s http://172.20.5.2:8000/v1/vpn/status {"status":"running"} {"status":"running"} OK so gluetun's API is responding fine. The dashboard can reach it and it's returning running. This is a dashboard display bug then, not a connectivity issue. A few things to try in order: 1. Clear browser cache fully Not just a hard refresh — full cache clear for the site. In Chrome: DevTools → Application → Storage → Clear site data. 2. Try a different browser or incognito Rules out a cached JS issue. 3. Check the dashboard container logs for any polling errors: sparkbox logs dashboard --tail 50 | grep -i vpn Paste anything that comes back. If none of that surfaces anything obvious, this is starting to look like a dashboard rendering bug specific to your setup — probably worth hitting the "Share to demox" button so Tom can take a look. The API side is working perfectly, so the fix needs to be on the dashboard end.
tomspark wrote:
First off, your VPN is actually working now, that's the big one — gluetun's healthy and routing through TorGuard, so your downloads are protected even with the tile blank. Nice work getting there. The blank tile is almost always one thing: SparkBox's records don't have the media module ticked as "on" (it can quietly drop off that list even while the containers keep running), and the VPN tile only shows when it's ticked. Quick check: grep media /opt/sparkbox/state/modules.conf If nothing comes back, that's it — run sudo sparkbox enable media, then refresh the dashboard and the tile should appear. If "media" IS listed, paste sudo sparkbox logs dashboard --tail 40 and I'll read what's tripping it up. (Those session-error lines you spotted are a separate NAS-storage quirk we're aware of, harmless, and I've flagged it to get cleaned up.)
popuman wrote:
It’s working now. Took a long time but it’s all working.