So I installed the Media stack and at the beginning it ask for VPN info. I entered my NordVPN Private Key, but it still didn't connect even after a few minutes. I used the Tom Sparks affiliate link and purchased Surfshark. I got my private key from my account and tried that but still no luck connecting. Is the public key not needed as well somewhere? They came as a pair but we only use one? I don't have any logs to post as the live logs for the VPN Tunnel just say Connecting... I'll need you to help me help you on this one lol :)
13 replies
tomspark wrote:
Great question. No, you only need YOUR client private key + assigned IP — gluetun has Surfshark's server pubkeys baked in. Most common cause of stuck "Connecting...": the wrong key got pasted. Surfshark's download gives you a pair — PrivateKey (yours) and PublicKey (the server's). You want the PrivateKey. One diagnostic, run on the NAS: sudo docker logs sb-gluetun 2&1 | tail -30 The error there will tell us which side is failing — "failed to parse private key" means wrong value in WIREGUARDPRIVATEKEY, "failed to dial server" means network/server side. Paste those lines and I'll pin the fix in one shot.
GamerX06 wrote:
the output is blank and I triple checked I am using the private key. root@ubuntu:~ docker logs sb-gluetun 2&1 | tail -30 root@ubuntu:~ root@ubuntu:~ printf '%s\n' 'ACqdVrw2acsVTUM31ZksztGqTNGGwpqSSJGeQEs7i1o=' | wg pubkey GNq7lCZxW5ygYMtzHJF+RlNWJ4AAFxJu+6vlFaXxVAg= root@ubuntu:~ (I deleted the key from my account and will make a new one for me to use, so this is secure)
tomspark wrote:
Smart move rotating the key. Your wg pubkey check confirms the private key is syntactically valid AND matches the public key Surfshark registered for your Sparkbox device — so this is NOT a wrong-key issue at all. The real puzzle is that gluetun has zero logs, which usually means the container isn't running (or never actually started). Check its state: sudo docker ps -a --filter name=sb-gluetun --format 'table {{.Names}}\t{{.Status}}' If it shows Created or Exited with a non-zero code, install never finished bringing up the media stack and we'll need to kick it. If it shows Up X seconds (unhealthy), run sudo sparkbox restart media then re-check the logs — fresh container start should write something. Paste the output and we'll go from there.
GamerX06 wrote:
we have our first clue! root@ubuntu:~ docker ps -a --filter name=sb-gluetun --format 'table {{.Names}}\t{{.Status}}' NAMES STATUS sb-gluetun Created root@ubuntu:~ sparkbox restart media [INFO] Restarting module: media (recreating to pick up .env changes) WARN[0000] Found orphan containers ([sb-npm sb-portainer sb-homepage sb-dashboard]) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up. [+] up 10/11 ✔ Container sb-seerr Started 4.2s ✔ Container sb-bazarr Started 4.2s ✔ Container sb-jellyfin-media Started 4.2s ✔ Container sb-deunhealth Started 4.0s ⠦ Container sb-gluetun Starting 4.2s ✔ Container sb-radarr Recreated 0.3s ✔ Container sb-prowlarr Recreated 0.2s ✔ Container sb-qbittorrent Recreated 0.4s ✔ Container sb-sonarr Recreated 0.3s ✔ Container sb-sabnzbd Recreated 0.4s ✔ Container sb-flaresolverr Recreated 0.3s Error response from daemon: error gathering device information while adding custom device "/dev/net/tun": no such file or directory root@ubuntu:~
tomspark wrote:
Found it — the smoking gun is the last line: Error response from daemon: error gathering device information while adding custom device "/dev/net/tun": no such file or directory Your host is missing the tun kernel module / device. Gluetun can't open a WireGuard interface without it. Host-side fix, nothing wrong with your SparkBox config: sudo modprobe tun echo tun | sudo tee -a /etc/modules sudo sparkbox restart media First loads the module now, second makes it persist across reboots, third restarts the stack. Gluetun should come up green this time. Shipping a sparkbox doctor preflight check for /dev/net/tun in the next ~20 min so the next person hits a clear error message instead of having to dig through the docker daemon line. Thanks for the chase — second class-level gluetun bug this week thanks to you and jackhammer57 sticking through it.
GamerX06 wrote:
Ok so running modprobe tun on my PVE host did get Gluetun running and I am getting logs of �2026-05-13T02:44:39.624286664Z 2026-05-13T02:44:39Z ERROR [vpn] finding a VPN server: filtering servers: no server found: for VPN wireguard; protocol udp; country united states; city san jose; target ip address 0.0.0.0 O2026-05-13T02:44:39.624406133Z 2026-05-13T02:44:39Z INFO [vpn] retrying in 15s �2026-05-13T02:44:54.640703308Z 2026-05-13T02:44:54Z ERROR [vpn] finding a VPN server: filtering servers: no server found: for VPN wireguard; protocol udp; country united states; city san jose; target ip address 0.0.0.0 O2026-05-13T02:44:54.640739173Z 2026-05-13T02:44:54Z INFO [vpn] retrying in 30s �2026-05-13T02:45:24.643719237Z 2026-05-13T02:45:24Z ERROR [vpn] finding a VPN server: filtering servers: no server found: for VPN wireguard; protocol udp; country united states; city san jose; target ip address 0.0.0.0 P2026-05-13T02:45:24.643748197Z 2026-05-13T02:45:24Z INFO [vpn] retrying in 1m0s �2026-05-13T02:46:24.676773937Z 2026-05-13T02:46:24Z ERROR [vpn] finding a VPN server: filtering servers: no server found: for VPN wireguard; protocol udp; country united states; city san jose; target ip address 0.0.0.0 P2026-05-13T02:46:24.676803793Z 2026-05-13T02:46:24Z INFO [vpn] retrying in 2m0s �2026-05-13T02:48:24.680925942Z 2026-05-13T02:48:24Z ERROR [vpn] finding a VPN server: filtering servers: no server found: for VPN wireguard; protocol udp; country united states; city san jose; target ip address 0.0.0.0 P.S. the GUI Glitch with the VPN Setting is still a thing
GamerX06 wrote:
I copied over the setting and tried again, this time it connected immediately
tomspark wrote:
Boom — that's the unblock. Glad it landed cleanly. v1.6.105 just shipped with a /dev/net/tun preflight in sparkbox doctor, so the next person who hits this gets pointed straight at modprobe tun instead of chasing the docker daemon error. Appreciate the help nailing the diagnosis.
MintyDuck wrote:
I have followed to this point but still get errors: I have the same issue in Proxmox / LXC Error response from daemon: error gathering device information while adding custom device "/dev/net/tun": no such file or directory Running sudo modprobe tun echo tun | sudo tee -a /etc/modules sudo sparkbox restart media modprobe: FATAL: Module tun not found in directory /lib/modules/7.0.2-2-pve Restarting module: media (recreating to pick up .env changes) WARN[0000] Found orphan containers ([sb-npm sb-portainer sb-homepage sb-filebrowser sb-actual sb-dashboard]) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up. Error response from daemon: error gathering device information while adding custom device "/dev/net/tun": no such file or directory Any help appreciated on next steps
tomspark wrote:
LXC is the wrinkle here. modprobe tun fails inside the container because an LXC shares the Proxmox host's kernel — the module has to be loaded on the host node, and the tun device passed into the container. Two parts. On the Proxmox HOST (not the LXC): modprobe tun echo tun /etc/modules-load.d/tun.conf Then pass the device in — on the host, edit /etc/pve/lxc/<CTID.conf and add these two lines: lxc.cgroup2.devices.allow: c 10:200 rwm lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file Then pct restart <CTID, and inside the container sudo sparkbox restart media. /dev/net/tun will be present and gluetun comes up green. Logging this so the doctor preflight gets an LXC-aware hint next.
MintyDuck wrote:
can confirm this worked, it took a reboot and I reinserted all the VPN details again to be sure.
tomspark wrote:
Perfect, thanks for confirming — and the reboot detail is useful. This LXC path is now logged with your repro, so the sparkbox doctor preflight gets an LXC-aware branch (host-side modprobe + the /etc/pve/lxc passthrough) instead of the bare-metal advice that doesn't apply inside a container. Appreciate you running it down.
tomspark wrote:
Heads up — 1.6.475 just shipped and should cover what you reported here. You can grab it straight from the dashboard: Settings → Updates → Update SparkBox. Let me know if that sorts it, or if you're still hitting it. (Prefer the terminal? sudo sparkbox upgrade — note update only refreshes app images and will not move you to a new release.)