My box is working and I can stream from my Jellyfin slowly, but my qbittorrent is paused and my AI says "I couldn't reach the AI service — this box's connection to it timed out (EAIAGAIN). That's the network path between your box and our servers, not the app itself: check your internet/VPN, then run sudo sparkbox doctor (its Container Egress check tests that same path). If that's green and this keeps happening, post in d/sparkbox with your install ID and this code so we can check our side." I ran it, and got the following warnings. [Container Egress] [WARN] The apps' network (sbproxy) cannot reach tomsparkbox.com. This is the network every SparkBox app runs on, including the reverse proxy — so anything that fetches from the internet (certificates, metadata, indexers, updates) will fail. It also stops the reverse proxy (sb-npm) finishing its startup: NPM downloads an IP-range list from Amazon the moment it boots, and with no way out that download never answers, so it waits there forever. The container stays 'Up (unhealthy)' and its log ends mid-line at 'Fetching IP Ranges from online services'. Nothing is wrong with NPM; fix egress below and it finishes booting. Testing which layer is blocked (this takes up to a minute)... Layer test: could not run — this box could not resolve the origin on the HOST either, so the fault is not specific to containers. Check the box's own DNS and internet connection first. Re-run 'sparkbox doctor' to verify. [WARN] Docker's default bridge cannot reach tomsparkbox.com. What this breaks: the dashboard's one-click Update button. It downloads from inside a helper container on that bridge, so it fails with 'Could not resolve host: get.tomsparkbox.com'. Optional Pro-tier license activation won't work either. Updating over SSH still works — that downloads on the host: sudo sparkbox upgrade Same layer as the apps' network above — same fix. [Retired Apps] ○ Homarr is retired: it keeps running and updating here, but can't be re-added once removed (remove: sudo sparkbox disable homarr) [Saved Passwords] [WARN] sb-jellyfin-media: the password saved in state/jellyfin-admin-password.txt is NOT accepted (HTTP 401). [WARN] This happens after a reinstall over existing data, or if the password was [WARN] changed inside the app itself — the saved copy then drifts out of sync. Fix it with: sudo /opt/sparkbox/sparkbox reset-password jellyfin [Tailscale Sign-in] [WARN] sb-tailscale is not staying up (status: running, restarts: 3). Remote access over Tailscale is down until it does; your home network is unaffected. See what it says: sudo docker logs sb-tailscale --tail 30 I also ran name@homeserver:~$ sudo sparkbox update name@homeserver:~$ sudo sparkbox upgrade but I still have the same issues with my box not being right. The only thing that's happened recently is that I lost power a few times recently.
17 replies
Chris wrote:
Sorry about the wrong turn. The assistant pointed you at your internet and VPN first, and that was the wrong place to look. Your doctor run shows the box itself could not look up our servers. Its own name lookup failed, which is consistent with the apps' network and Docker's bridge both failing. The doctor's own advice is to check the box's DNS and internet connection before anything else. Your recent power cuts could be related, but we can't tell that from here. We have also corrected what the assistant tells people about this, so it does not happen to the next person. That affects updates too. sudo sparkbox update only refreshes app images and never installs a new SparkBox release. sudo sparkbox upgrade installs releases, but it downloads on the box itself, so it needs the same lookup to reach our download server. Until that works, neither one will finish. One check, run on the box (no sudo needed): getent hosts get.tomsparkbox.com It should print one line with an IP address. If it prints nothing, the box's DNS is the problem. Reply with what it printed, your platform (plain Linux, a NAS, or Windows with WSL), and the output of cat /opt/sparkbox/VERSION. You don't need your install ID or any passwords.
Nultima wrote:
My box has lines like: there is 1 zombie process. 5 devices have a firmware upgrade available. run 'fwupdmgr get-upgrades' for more information 72 updates can be applied immediately. then I ran: getent hosts get.tomsparkbox.com and it printed nothing, it just returned with name@homeserver:~$ using ubuntu 26.04 LTS (GNU/Linux 7.0.0-38-generic x8664) and on sparkbox version 1.7.20
Chris wrote:
Thanks, that narrows it down. When getent prints nothing on the box itself, the box can't look up names at all, so SparkBox's own checks and the upgrade download fail for the same reason. The fault is in the box's network or name lookup, not in the apps. The firmware, apt and zombie-process lines are normal Ubuntu login messages and don't point at SparkBox. One check, run on the box (no sudo needed): ping -c 2 1.1.1.1 If the summary shows 0% packet loss, the internet connection works and only name lookup is broken. If it shows 100% packet loss, the connection itself is down. Reply with the summary line from that output and we'll go from there. The Jellyfin password and Tailscale warnings may share this cause, but we'll check them after the lookup works, so please hold off on the commands the doctor suggested for them until then.
Nultima wrote:
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data 64 bytes from 1.1.1.1: icmpseq=1 ttl=57 time=4.21 ms 64 bytes from 1.1.1.1: icmpseq=2 ttl=57 time=4.01 ms --- 1.1.1.1 ping statistucs --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 4.010/4.110/4.211/0.100 ms
Chris wrote:
Thanks, that settles one part: 0% packet loss to 1.1.1.1 means the box's internet connection works. Only name lookup is failing, so the next check is DNS. Run these two on the box, one after the other (no sudo needed): cat /etc/resolv.conf getent hosts ubuntu.com What to expect: - The first prints one or more lines starting with nameserver. On Ubuntu that is often 127.0.0.53 (the local resolver) or your router's address. A blank result, or an address you don't recognise, is what to look at. - The second prints one line with an IP address if the box can resolve any public name. If it prints nothing, name lookup is broken for the whole box, not only for SparkBox's servers. The power cuts are a possible cause, since an outage can change which DNS server the box uses. That is a hypothesis until these outputs confirm it. Reply with what the two commands printed. In the nameserver lines you can replace the last two digits of any IP address with xx. Please don't paste anything else from the file. Still hold off on the Jellyfin password and Tailscale commands until name lookup works. Once getent hosts get.tomsparkbox.com prints an address, sudo sparkbox upgrade should be able to download again.
Nultima wrote:
nameserver 100.100.100.100 nameserver: fd7a:115c:a1xx: :53 search tail9f6de3.ts.net The second prints nothing
Chris wrote:
Thanks, that's the clearest picture so far. The box is sending every name lookup to 100.100.100.100 first. That is Tailscale's own name service. When Tailscale on the box is not connected, it cannot answer public names, so ubuntu.com and get.tomsparkbox.com both get no answer. That is why the SparkBox checks and the upgrade download fail: they all depend on that same lookup. Why the box is pointed there is not yet known. Our guess is that Tailscale on the box took over the DNS settings and stopped connecting after the power cuts. That is a hypothesis until the check below confirms it. The second nameserver line doesn't read as a valid entry, which may be from how the paste was edited. A resolver skips a line it can't read, so it is not the main problem. One check, run on the box (no sudo needed): tailscale status Reply with its first two lines, with any device names or addresses removed. If it says Tailscale is stopped or needs a login, that accounts for the failed lookups. If it lists your devices and says you're connected, tell us that and we'll look further. Still hold off on the Jellyfin and Tailscale commands from the doctor until this is sorted.
Nultima wrote:
.00.68.106.xx homeserver 7fjh9b68xx@ linux - .00.94.135.1xx desktop-name 7fjh9b68xx@ windows offline last seen 79d ago .00.117.1.xx homeserver-1 7fjh9b68xx@ linux - tailscale failed to fetch the DNS configuration of your device: exit status 1 exit status 1
Chris wrote:
Thanks, that's the piece we were missing. A correction first: we guessed that Tailscale on the box was signed out. Your output shows it is signed in and can see your devices, so that guess was wrong, and I'm sorry for the detour. The line that matters is "tailscale failed to fetch the DNS configuration of your device." Tailscale is running, but it could not load its name settings. The box still sends name lookups to Tailscale's resolver, which is why public names like get.tomsparkbox.com get no answer. That fits the failed lookups from the doctor and from getent. We have not confirmed what caused this or whether the power cuts did. Please don't restart, reinstall or reset anything yet. One read-only check, run on the box: tailscale status | tail -n 15 If there is a block of lines starting with under a heading such as Health check, paste only those lines, with device names and addresses removed. If there is no such block, paste the last three lines of the output as they are. Reply with that output and we'll give you one command to try, with what each result means before you run it.
Nultima wrote:
it has the exact same output as before: .00.68.106.xx homeserver 7fjh9b68xx@ linux - .00.94.135.1xx desktop-name 7fjh9b68xx@ windows offline last seen 79d ago .00.117.1.xx homeserver-1 7fjh9b68xx@ linux - tailscale failed to fetch the DNS configuration of your device: exit status 1 exit status 1
Chris wrote:
Thanks. That same line is the key one: tailscale failed to fetch the DNS configuration of your device. Two read-only checks, run on the box. Please don't change anything yet. 1. Which resolver the box uses (no sudo needed): ls -l /etc/resolv.conf Expected: either a link pointing into /run/systemd/resolve/ (the system's resolver manages the file), or a plain file (the Tailscale client wrote it directly). Paste that one line. 2. Tailscale's own log of the failure: sudo journalctl -u tailscaled --since '2 days ago' --no-pager | grep -i dns | tail -n 10 Expected: a few lines that mention DNS and give a reason. Paste only those lines, with addresses and device names removed. If it prints nothing, say so and paste nothing else. When we have both outputs we'll give you one change to try, and what each result means before you run it. Until then, please hold off on the Jellyfin and Tailscale commands the doctor suggested.
Nultima wrote:
im just now noticing some of what i write is incomplete because the display cuts off the first character, i will try to fill that character with a '?' to denote: ?rw-r--r-- 1 root root 258 Nov 1 04:08 /etc/resolv.conf ?ov 05 05:42:29 homeserver tailscaled[1275]: dns: resolver: forward: no upstream resolvers set, returning SERVFAIL (basically this like 9 times) ?ov 05 05:42:29 homeserver tailscaled[1275]: [RATELIMIT] format("dns: resolver: forward: no upstream resolvers set, returning SERVFAIL")
Chris wrote:
Thanks, this log is the one we needed. Your box sends its name lookups to Tailscale's resolver (100.100.100.100). Your /etc/resolv.conf is a plain file that lists only that address, not the system resolver link SparkBox's installer normally sets up, so it looks like Tailscale wrote it. Tailscale's log says it could not load its DNS settings, so it has no upstream servers to pass public names to, and it answers SERVFAIL. That is why the SparkBox checks, the update download and the upgrade all fail. Your ping to 1.1.1.1 works, so the internet connection is fine and only name lookup is broken. The power cuts may be what left Tailscale's DNS settings unloaded. We can't confirm that from these logs. One change to try. It restarts only the Tailscale service on the box. If you are connected to the box over Tailscale, that connection will drop for a minute, so reconnect after it. Your home network is not affected: sudo systemctl restart tailscaled getent hosts get.tomsparkbox.com What the results mean: - The getent line prints an IP address: name lookup is working again. Run sudo sparkbox upgrade next and reply with its last few lines. - It prints nothing: the restart did not reload the settings. Run nothing else on the box yet, and reply with the output of those two commands. The Jellyfin password and sb-tailscale warnings from the doctor wait until name lookup works.
Nultima wrote:
neither line printed any output, though the first line took at least 10 seconds before it let me type in a new command. while i have tailscale on my box, i dont actively use it and dont think ive ever configured it before since i only have ever used the IP from within my network to access the box for things like jellyfin
Chris wrote:
Thanks, that tells us the restart did not reload Tailscale's DNS settings. The box is still sending every name lookup to Tailscale's name service, and that service has no way to answer public names. Sorry this has taken this many rounds. Your box is still in that state, and we don't have a released fix for it yet. The change that names this exact state is not in a published SparkBox version, so sudo sparkbox update and sudo sparkbox upgrade will not clear it by themselves for now. We also want to confirm the exact Tailscale setting before you change anything, since a wrong change could cut off your remote access. Two read-only checks, run on the box (no sudo needed): systemctl is-active systemd-resolved ls -l /run/systemd/resolve/resolv.conf Expected: the first prints active or inactive. The second prints one line describing the file, or No such file or directory. Reply with both results, and leave the Jellyfin and Tailscale warnings from the doctor on hold until we've looked at them. For reference, your box reports SparkBox 1.7.20. The newest published release is 1.7.36, and sudo sparkbox upgrade is the command that installs it once name lookups work.
Nultima wrote:
active ?rw-r--r-- 1 systemd-resolve systemd-resolve 933 Nov 4 03:22/run/systemd/resolve/resolv.conf I'm getting pretty tired of this shit tonight and will check back tomorrow, please just understand that I can only run things on my box or via ssh and if you come up with a solution tomorrow it can't be something as dumb as "update the box to fix it" I hope to hear back from you two or three times between now and noon. btw "could cut off your remote access" again, ive never used tailscale for remote access, and I dont even think ive set up tailscale before since I haven't tried to browse outside of my network
Chris wrote:
You're right that 'update the box' was the wrong answer, and I'm sorry for the rounds of guesses. Here is what your outputs show. Your internet works (1.1.1.1 answers) and the box's own name service is running. The problem is the file that tells the box where to look up names. /etc/resolv.conf is a plain file that sends every lookup to Tailscale's name service. Tailscale could not load its name settings after the power cuts, so it has nowhere to forward public names. That is why the checks and the download fail. The power cuts are the likely trigger, but we have not confirmed that. Two corrections to what we said earlier: the Tailscale sign-in guess was wrong, and SparkBox's installer does not normally set up the link that fixes this. It only does that on some installs, so please don't assume it applies to yours. We don't have a released fix for this yet, so 'sudo sparkbox update' and 'sudo sparkbox upgrade' won't clear it on their own. Keep the Jellyfin and Tailscale commands on hold. One change to try. It keeps a backup and changes only the name-lookup file. There's no need to run it tonight: sudo cp -a /etc/resolv.conf /etc/resolv.conf.before-fix sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf getent hosts get.tomsparkbox.com If the last line prints an IP address, name lookup is working. Reply with what it printed, and 'sudo sparkbox upgrade' should be able to download again. If it prints nothing, put the original file back with 'sudo mv /etc/resolv.conf.before-fix /etc/resolv.conf' and reply with the output of all three commands. What our assistant and our support notes say about this has been corrected, so it does not happen to the next person.