It's been a month and NOTHING WORKS YET
Posted by 1ye
Two devices, four reinstalls, endless reboots. I have yet to use a single app for 24 hours without issues. Where is the ease? Where is the simplicity? Where's the help that actually helps? The latest: Something in the milk isn't clean. Ran the disabled command on several apps and those apps are still running. Been uber busy the past couple days and return to find VPN down, several apps crashing, and Tom AI unreachable. I've rebooted my PC five times already. Ran the doctor and status reports. [VPN Tunnel] [ERROR] Gluetun container is exited — it never actually ran VPN not connected, so Sonarr, Radarr, Prowlarr, qBittorrent, Lidarr, Chaptarr, SABnzbd and Byparr can't open — their pages say "can't reach this page" until the VPN connects. They start by themselves once it does; fix the VPN below. Most likely: docker compose couldn't bring it up (missing kernel module, bind-mount permission, or compose-syntax issue). Try: sudo sparkbox restart media 2&1 | tail -5 and look for an 'Error response from daemon:' line — that's the actual cause. [Container Health] [ERROR] sb-chaptarr exists but never started (state: created) │ Docker could not start it (so its own log is empty): cannot join network namespace of a non running container: container sb-gluetun is exited [ERROR] sb-prowlarr exists but never started (state: created) │ Docker could not start it (so its own log is empty): cannot join network namespace of a non running container: container sb-gluetun is exited [ERROR] sb-sabnzbd exists but never started (state: created) │ Docker could not start it (so its own log is empty): cannot join network namespace of a non running container: container sb-gluetun is exited [ERROR] sb-lidarr exists but never started (state: created) │ Docker could not start it (so its own log is empty): cannot join network namespace of a non running container: container sb-gluetun is exited [ERROR] sb-radarr exists but never started (state: created) │ Docker could not start it (so its own log is empty): cannot join network namespace of a non running container: container sb-gluetun is exited [ERROR] sb-qbittorrent exists but never started (state: created) │ Docker could not start it (so its own log is empty): cannot join network namespace of a non running container: container sb-gluetun is exited [ERROR] sb-sonarr exists but never started (state: created) │ Docker could not start it (so its own log is empty): cannot join network namespace of a non running container: container sb-gluetun is exited [ERROR] sb-byparr exists but never started (state: created) │ Docker could not start it (so its own log is empty): cannot join network namespace of a non running container: container sb-gluetun is exited [ERROR] sb-stirling-pdf crashed (exit code 128) [ERROR] sb-wordpress crashed (exit code 128) [ERROR] sb-wordpress-db is running, but its health check is failing (Docker reports 'unhealthy') The app has started but is not answering properly, so it will look broken or half-working. Last few log lines: │ 2026-09-30 17:46:17 7319 [Warning] Access denied for user 'wordpress'@'[LAN address]' (using password: YES) │ 2026-09-30 17:46:33 7322 [Warning] Access denied for user 'wordpress'@'[LAN address]' (using password: YES) │ 2026-09-30 17:46:48 7325 [Warning] Access denied for user 'wordpress'@'[LAN address]' (using password: YES) [ERROR] sb-gluetun crashed (exit code 128) [ERROR] sb-linkding crashed (exit code 137) Try: sudo sparkbox up (and 'sparkbox logs <name' to see why a container is unhappy) sb-chaptarr: exit code 128, OOM-killed: false, stopped at 0001-01-01T00:00:00Z sb-prowlarr: exit code 128, OOM-killed: false, stopped at 0001-01-01T00:00:00Z sb-sabnzbd: exit code 128, OOM-killed: false, stopped at 0001-01-01T00:00:00Z sb-lidarr: exit code 128, OOM-killed: false, stopped at 0001-01-01T00:00:00Z sb-radarr: exit code 128, OOM-killed: false, stopped at 0001-01-01T00:00:00Z sb-qbittorrent: exit code 128, OOM-killed: false, stopped at 0001-01-01T00:00:00Z sb-sonarr: exit code 128, OOM-killed: false, stopped at 0001-01-01T00:00:00Z sb-byparr: exit code 128, OOM-killed: false, stopped at 0001-01-01T00:00:00Z sb-stirling-pdf: exit code 128, OOM-killed: false, stopped at 2026-09-29T20:15:47 sb-wordpress: exit code 128, OOM-killed: false, stopped at 2026-09-29T20:15:46 sb-gluetun: exit code 128, OOM-killed: false, stopped at 2026-09-29T20:15:40 sb-linkding: exit code 137, OOM-killed: false, stopped at 2026-09-29T20:11:31 [WARN] 3 containers stopped within the same minute (2026-09-29 20:15 UTC) and are still down — one event took them all down, not 3 separate app faults Stopped together: sb-gluetun (exit 128), sb-wordpress (exit 128), sb-stirling-pdf (exit 128) None were OOM-killed. Look at what happened on this box at that moment (a VPN restart, an update, a drive or share going away, a reboot) — the exit codes above are the apps' own. Bring them back: sudo sparkbox up (then 'sudo sparkbox logs <name' if one stays down) [Library Import] [INFO] Sonarr/Radarr are not running right now — their import queues were not checked [WARN] Some apps were created but never started (a dependency — usually the VPN tunnel — wasn't healthy in time). Starting them now: [ERROR] These apps are still NOT running: chaptarr prowlarr sabnzbd lidarr radarr qbittorrent sonarr byparr [ERROR] They ride on the VPN tunnel and can't start until it's healthy. [ERROR] Check what's wrong: sudo sparkbox doctor [ERROR] Then bring them up: sudo sparkbox restart media This is absolute madness! What gives?
9 replies
Chris wrote:
I’m sorry—after four reinstalls and repeated reboots, having apps still fail and the VPN down is not the reliable experience you should be getting. Your doctor output shows the VPN container exited; the apps marked created have never started, so they cannot start until that dependency is working. The created-container recovery was added in SparkBox 1.6.453, but I can’t tell from this post which version you’re running. What SparkBox version is installed, and is this on Windows with WSL Docker Engine, Docker Desktop, or a NAS? That will tell us the safe next step; the separate database and app failures still need checking too.
1ye wrote:
Current version: 1.6.815 Windows WSL
Chris wrote:
Thanks, that clarifies the setup: SparkBox 1.6.815 on Windows with WSL. I’m sorry my earlier reply left you with another question instead of a useful next step. The containers marked created have never started, so automatic restarts cannot recover them; SparkBox’s recovery for that state is included from 1.6.453 onward. Please run sudo sparkbox update and then sudo sparkbox up from the WSL terminal, and tell me whether the VPN tunnel starts and those apps leave created—stop there if either command reports an error. The recovery guidance has been corrected so this does not send the next person in circles.
1ye wrote:
Updated to SparkBox v1.6.821. VPN up but apps I switched off are AGAIN running and causing issues. I needed these issues sorted before today. Why does this keep failing me?
Chris wrote:
I’m sorry — my earlier update-and-up advice didn’t address the separate problem of apps you had switched off coming back, and I understand why this feels like another failure. There is a known failure in the command-line disable path where it can report success even if stopping an app failed, then refuse a retry; I can’t tell yet whether that is what happened on your box, and I can’t verify a released fix for it. Please tell me whether you switched them off in the dashboard or with the command line, and name one affected app; don’t retry switching it off yet. I’ve corrected the guidance so it won’t send the next person in circles.
1ye wrote:
1st with command line, then again on dashboard. Mealie, Searxng, Stirling, Gotify, and at least four more that I am flat out too tired to wade through again. Gotify is still running though it doesn't work and Stirling PDF is still running and erroring. Beyond frustrated and I want off the wheel of despair and techno-tussle.
Chris wrote:
I’m sorry—after four reinstalls and all those reboots, you’re still dealing with apps you turned off running or failing, and my last reply asked you to investigate more instead of reducing the burden. You’re on SparkBox 1.6.821 in Windows/WSL. The CLI disable path has a recorded failure where it can say an app was disabled even when stopping it failed; that could explain the command-line attempt, but it does not explain the later dashboard attempt or prove why Gotify and Stirling are failing. I don’t have a verified released fix to offer, and I won’t ask you to repeat the disable steps. If you’re up for one small check, is Gotify still listed as enabled in the dashboard, or is it absent while its container keeps running? That will distinguish the leftover-container problem from the dashboard toggle without making you inspect the other apps. I’ve corrected our guidance to keep those two failure paths separate.
1ye wrote:
Gotify is in the dashboard marked active. Stirling too is in the dashboard but marked unhealthy with a ton of errors. Tom AI is completely unresponsive. What's the purpose for all this if I can't use anything?
Chris wrote:
I’m sorry this is still leaving you with apps you deliberately turned off running or failing, after all the time you’ve already spent trying to recover things. Your update confirms Gotify and Stirling still appear active in the dashboard; that means this is not just a container left behind while the dashboard says the app is removed. We already have confirmed defects where a command-line disable can report success despite a failed stop, and where dashboard removal can leave an app running, but neither explains why yours still appears active or why Stirling is unhealthy. I won’t ask you to repeat those steps or reset anything. One clarification for Gotify: when you say “marked active,” do you mean it is listed as enabled, or are you describing a running-status label?