I cannot update, ask Tom or connect through ssh. I updated the box to 1.175 after that check for app updates, and after that the problems startet. Cloudflare down, jellyfin-media-admin-init unhealthy, navidrome unhealthy, seer unhealthy. Site loading very slow. Cannot update to 1.717. With putty no connection . Sofware problem caused the abort , putty error
36 replies
Chris wrote:
Sorry, losing SSH and the apps right after an update is a bad spot to be in. Let's find out where it stopped before changing anything. Please send me three things, and don't reinstall or reset anything yet, since that can remove app data: 1. What the box is: a dedicated Linux PC or mini PC, a NAS, a cloud VPS, or Windows with WSL. 2. The exact message PuTTY shows when it fails (for example "timed out" or "connection refused") and the IP address you typed into it. 3. Whether the SparkBox dashboard opens from another device on your home network at http://THE-BOX-IP:8443. If it does, tell me the version it shows. With those I can give you one specific check next.
franciscus wrote:
ugreen nas 8800 plus I had sparkbox doctor running on putty but was stuck on halfway so I quit The error was caused from software, it showed but not what software v1.7.15 VPN has a problem It just updated to the newest version
Chris wrote:
Thanks, a UGREEN NAS on 1.7.15 is exactly what I needed. I'm sorry the doctor run stalled halfway. Please don't reinstall, reset or upgrade yet. Two read-only checks, in order: 1. Connect with PuTTY. If it connects, run: sudo docker ps -a --filter name=admin-init --format '{{.Names}} {{.Status}}' You should get two lines, one for sb-jellyfin-media-admin-init and one for sb-navidrome-admin-init. Send me those two lines. Exited (0) means that setup finished; Exited (1) or another non-zero code means it failed. 2. If PuTTY does not connect, send me the exact message it shows. You can leave the IP out. Also, from another device on your network, open http://THE-BOX-IP:8443 and tell me the version it shows. Stop there and send me what you get; that is enough for the next step. You asked about Tom earlier: he is our CEO and does not work the support queue. Chris and Anthony are Tom's support team and handle support end to end.
franciscus wrote:
sb-navidrome-admin-init Exited (0) 27 minutes ago sb-seerr-admin-init Exited (0) 27 minutes ago sb-jellyfin-media-admin-init Exited (0) 27 minutes ago sb-immich-server-admin-init Exited (0) 27 minutes ago on the box: VPN has a problem
Chris wrote:
Thanks, that helps. All four setup containers (Navidrome, Seerr, Jellyfin media and Immich) show Exited (0), which means their one-time setup finished cleanly. So those setup jobs are not what is stopping the VPN. One read-only check next, over PuTTY: sudo docker ps -a --filter name=sb-gluetun --format '{{.Names}} {{.Status}}' Send me the single line it prints. It will look like 'sb-gluetun Up 2 hours (healthy)', or it may say unhealthy, restarting or exited. Leave out any IP address or key. Until we know the VPN state, please don't update, reinstall or reset.
franciscus wrote:
sb-gluetun Up 34 minutes (healthy) Media pipeline on homepage: Media pipeline ! VPN ✓ Download apps ✓ Indexers ✓ Storage ✓ Into your library on top of homepagenotifications : Cloudflared keeps crashing and coming back (12 times in 6 hours).
Chris wrote:
Thanks, that is useful. The VPN app itself is running and reports healthy, so the red VPN step on your Media pipeline is a separate check, and I want its exact wording before guessing. One read-only check: on the homepage, copy the sentence printed under the VPN step (not the title; leave out any IP address or key). That sentence says which case you are in, and each case has a different fix. Please hold the update until then. The box reports 1.7.15 and the newest published version is 1.7.17, so you are not on the latest yet. Once I have that sentence I will give you the exact update step.
franciscus wrote:
It already updated, I wrote it before. I have v1.7.17 I updated it once and come back could not update : error. 10 min. later it was updated.
Chris wrote:
Thanks, good to hear the update went through, even after the error. The 1.7.17 notes cover drive uploads, reset safety and the installer. They do not change the VPN, so the red VPN step may still show after the update. Two read-only checks, please: 1. Does PuTTY connect now? If yes, just say so. If no, send me the exact message it shows, without the IP address. 2. On the homepage, type out the sentence printed under the VPN step (not the title). Leave out any IP address or key. The screenshot did not come through on my side, so a typed copy is easiest. That sentence tells us which VPN case you are in, and each case has a different fix. Please don't reinstall or reset in the meantime.
franciscus wrote:
Handled on its own (2) Cloudflared was slow for 4 min — back to normal. 2 min ago The VPN blinked and reconnected — downloads resumed. 5 min ago
Chris wrote:
Thanks, the two screenshots came through on the forum. I cannot open images from my side, so I still need the sentence under the VPN step typed out, with no IP address or key. Three read-only checks, in this order, over PuTTY or on the homepage: 1. Does PuTTY connect now? Just say yes, or send the exact message it shows without the IP address. 2. On the homepage, type out the sentence printed under the VPN step (not the title). 3. Cloudflared is the optional Cloudflare Tunnel app. If you did not set it up on purpose, you can ignore it for now. If you did, run: sudo docker ps -a --filter name=sb-cloudflared --format '{{.Names}} {{.Status}}'. Send that one line, and do not paste the tunnel token. Stop after those and send me what you get. Please don't reinstall, reset or upgrade in the meantime.
franciscus wrote:
Putty does connect but slow, I think cloudflare is the culprit. It starts several times
franciscus wrote:
Protected by Surfshark WireGuard ? Edit Recheck 🇩🇪 Frankfurt am Main, Hesse, DE IP ...138 Downloads protected by VPN ✓ If VPN drops downloads stop automatically ✓ VPN connection up The "kill switch" means if your VPN ever disconnects, your server automatically stops downloading until it reconnects — so nothing is ever downloaded without protection. Green here means the tunnel works and your traffic is routed correctly — it does NOT confirm this VPN server allows P2P/torrent traffic. Some server locations block torrenting even though ordinary browsing (and this check) works fine. If downloads never start, edit your VPN settings and try a different country whose servers allow P2P traffic — see the VPN choice guide. Media pipeline ✓ VPN ✓ Download apps ✓ Indexers ✓ Storage ✓ Into your library For now everything is green and up, but in a few minutes cloudflare restarting again
Chris wrote:
Good to hear PuTTY connects again. Slow sessions that restart several times are worth tracking down. Cloudflare Tunnel is optional, and it only carries traffic for web addresses you published through Cloudflare. A PuTTY session to the box's own address stays on your home network, so the tunnel is not in that path. That makes it an unlikely cause of slow SSH, though I can't be sure until we see its status. Two read-only checks, over PuTTY: 1. sudo docker ps -a --filter name=sb-cloudflared --format '{{.Names}} {{.Status}}' 2. Tell me whether the address you typed into PuTTY is a plain number (like 192.168.x.x) or a Cloudflare web name. Please don't post the number itself. Also still needed: the sentence printed under the VPN step on the homepage, typed out with no IP address or key. Please don't reinstall or reset in the meantime.
franciscus wrote:
sparkbox doctor: [VPN Tunnel] [ERROR] Gluetun reports healthy but its tunnel keeps rebuilding — nothing is getting through The container is up, so the dashboard tiles read green, but gluetun's own log shows it dropping the tunnel and reconnecting every few seconds. Downloads and indexers cannot work in that state. Your VPN's saved server list hasn't been refreshed in 312 days. Providers change their servers' keys, and an old list gives a tunnel that connects and carries nothing. Refresh it first (it restarts the VPN for you): sudo sparkbox refresh-vpn-servers Still cycling a few minutes later? Then try the steps below. Your VPN connects, but nothing inside the tunnel can look up an address, so its own health check times out and it restarts. Encrypted DNS is already off on this box, so that is ruled out: the tunnel isn't carrying traffic at all. Re-check your VPN key and address, and on WireGuard try: sudo sparkbox set-env WIREGUARDMTU 1280 then 1220 sudo sparkbox restart media Full log: sudo sparkbox logs sb-gluetun after that doctor stops and I have to stop it ctrl+c
franciscus wrote:
Putty error: software caused connection abort
Chris wrote:
Thanks for pasting the doctor output. The line that matters is "Gluetun reports healthy but its tunnel keeps rebuilding": the VPN connects, then drops and reconnects every few seconds, so nothing gets through. The doctor also says the VPN's saved server list is 312 days old. Providers change their server keys over time, and an old list gives a tunnel that connects and carries nothing. One step, over PuTTY: sudo sparkbox refresh-vpn-servers It downloads a current server list (the old copy is kept, and restored if the download fails) and restarts the VPN. Downloads pause during the restart. Then give it about five minutes and check the VPN step on the Media pipeline. Please don't run the WIREGUARDMTU lines from the doctor yet. Only come back to them if the tunnel still keeps rebuilding after the refresh. The cloudflared and PuTTY address questions can wait until we see the result. Tell me whether the VPN step stays green for ten minutes or starts rebuilding again.
Chris wrote:
Thanks, that message matters before you run the refresh. "Software caused connection abort" is a Windows network error. It usually means the SSH connection was cut on your PC's side, for example by a Wi-Fi or network drop, the PC sleeping, or a security program on the PC. It doesn't prove a fault on the box yet, but it does mean PuTTY can drop during a long command. When you run the refresh from my last reply, keep the PuTTY window open until the prompt comes back. If the window drops before that, reconnect and send me the last line it printed before you run anything again. Please don't run the WIREGUARDMTU lines from the doctor yet.
franciscus wrote:
after several attemps here is the log: 2026-10-31T21:19:50+01:00 INFO [wireguard] Using available kernelspace implementation 2026-10-31T21:19:50+01:00 INFO [wireguard] Connecting to xxxxxxxxx:51820 2026-10-31T21:19:50+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-10-31T21:19:56+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-10-31T21:19:56+01:00 INFO [vpn] 👉 See https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md 2026-10-31T21:19:56+01:00 INFO [vpn] DO NOT OPEN AN ISSUE UNLESS YOU HAVE READ AND TRIED EVERY POSSIBLE SOLUTION 2026-10-31T21:19:56+01:00 INFO [vpn] stopping 2026-10-31T21:19:56+01:00 INFO [vpn] starting 2026-10-31T21:19:56+01:00 INFO [firewall] allowing VPN connection... 2026-10-31T21:19:56+01:00 INFO [wireguard] Using available kernelspace implementation 2026-10-31T21:19:56+01:00 INFO [wireguard] Connecting to xxxxxxxxxx:51820 2026-10-31T21:19:56+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-10-31T21:20:02+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-10-31T21:20:02+01:00 INFO [vpn] 👉 See https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md 2026-10-31T21:20:02+01:00 INFO [vpn] DO NOT OPEN AN ISSUE UNLESS YOU HAVE READ AND TRIED EVERY POSSIBLE SOLUTION 2026-10-31T21:20:02+01:00 INFO [vpn] stopping 2026-10-31T21:20:02+01:00 INFO [vpn] starting 2026-10-31T21:20:02+01:00 INFO [firewall] allowing VPN connection... 2026-10-31T21:20:02+01:00 INFO [wireguard] Using available kernelspace implementation 2026-10-31T21:20:02+01:00 INFO [wireguard] Connecting to xxxxxxxxx:51820 2026-10-31T21:20:02+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-10-31T21:20:08+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-10-31T21:20:08+01:00 INFO [vpn] 👉 See https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md 2026-10-31T21:20:08+01:00 INFO [vpn] DO NOT OPEN AN ISSUE UNLESS YOU HAVE READ AND TRIED EVERY POSSIBLE SOLUTION 2026-10-31T21:20:08+01:00 INFO [vpn] stopping 2026-10-31T21:20:09+01:00 INFO [vpn] starting 2026-10-31T21:20:09+01:00 INFO [firewall] allowing VPN connection... 2026-10-31T21:20:09+01:00 INFO [wireguard] Using available kernelspace implementation 2026-10-31T21:20:09+01:00 INFO [wireguard] Connecting to xxxxxxxxxx:51820 2026-10-31T21:20:09+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-10-31T21:20:15+01:00 INFO [ip getter] Public IP address is xxxxxxxxx (Germany, Hesse, Frankfurt am Main - source: ipinfo+ifconfig.co+ip2location+cloudflare) 2026-10-31T21:33:00+01:00 WARN [vpn] restarting VPN because it failed to pass the healthcheck: small periodic check: all check tries failed: attempt 1 (5003ms): timed out waiting for ICMP echo reply from 1.1.1.1 attempt 2 (5003ms): timed out waiting for ICMP echo reply from 8.8.8.8 attempt 3 (5003ms): timed out waiting for ICMP echo reply from 1.1.1.1 attempt 4 (10004ms): timed out waiting for ICMP echo reply from 8.8.8.8 attempt 5 (10004ms): timed out waiting for ICMP echo reply from 1.1.1.1 attempt 6 (10008ms): timed out waiting for ICMP echo reply from 8.8.8.8 attempt 7 (15001ms): timed out waiting for ICMP echo reply from 1.1.1.1 attempt 8 (15008ms): timed out waiting for ICMP echo reply from 8.8.8.8 attempt 9 (15011ms): timed out waiting for ICMP echo reply from 1.1.1.1 attempt 10 (30001ms): timed out waiting for ICMP echo reply from 8.8.8.8 2026-10-31T21:33:00+01:00 INFO [vpn] 👉 See https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md 2026-10-31T21:33:00+01:00 INFO [vpn] DO NOT OPEN AN ISSUE UNLESS YOU HAVE READ AND TRIED EVERY POSSIBLE SOLUTION 2026-10-31T21:33:00+01:00 INFO [vpn] stopping 2026-10-31T21:33:00+01:00 INFO [vpn] starting 2026-10-31T21:33:00+01:00 INFO [firewall] allowing VPN connection... 2026-10-31T21:33:00+01:00 INFO [wireguard] Using available kernelspace implementation 2026-10-31T21:33:00+01:00 INFO [wireguard] Connecting to xxxxxxxx:51820 2026-10-31T21:33:00+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-10-31T21:33:06+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 cloudflare.com: i/o timeout, parallel attempt 2/2 failed: dialing: dial tcp4: lookup github.com: i/o timeout 2026-10-31T21:33:06+01:00 INFO [vpn] 👉 See https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md 2026-10-31T21:33:06+01:00 INFO [vpn] DO NOT OPEN AN ISSUE UNLESS YOU HAVE READ AND TRIED EVERY POSSIBLE SOLUTION 2026-10-31T21:33:06+01:00 INFO [vpn] stopping 2026-10-31T21:33:06+01:00 INFO [vpn] starting 2026-10-31T21:33:06+01:00 INFO [firewall] allowing VPN connection... 2026-10-31T21:33:06+01:00 INFO [wireguard] Using available kernelspace implementation 2026-10-31T21:33:06+01:00 INFO [wireguard] Connecting to xxxxxxxxxx:51820 2026-10-31T21:33:06+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-10-31T21:33:12+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 cloudflare.com: i/o timeout, parallel attempt 2/2 failed: dialing: dial tcp4: lookup github.com: i/o timeout 2026-10-31T21:33:12+01:00 INFO [vpn] 👉 See https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md 2026-10-31T21:33:12+01:00 INFO [vpn] DO NOT OPEN AN ISSUE UNLESS YOU HAVE READ AND TRIED EVERY POSSIBLE SOLUTION 2026-10-31T21:33:12+01:00 INFO [vpn] stopping 2026-10-31T21:33:13+01:00 INFO [vpn] starting 2026-10-31T21:33:13+01:00 INFO [firewall] allowing VPN connection... 2026-10-31T21:33:13+01:00 INFO [wireguard] Using available kernelspace implementation 2026-10-31T21:33:13+01:00 INFO [wireguard] Connecting to xxxxxxxx:51820 2026-10-31T21:33:13+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-10-31T21:33:19+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-10-31T21:33:19+01:00 INFO [vpn] 👉 See https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md 2026-10-31T21:33:19+01:00 INFO [vpn] DO NOT OPEN AN ISSUE UNLESS YOU HAVE READ AND TRIED EVERY POSSIBLE SOLUTION 2026-10-31T21:33:19+01:00 INFO [vpn] stopping 2026-10-31T21:33:19+01:00 INFO [vpn] starting 2026-10-31T21:33:19+01:00 INFO [firewall] allowing VPN connection... 2026-10-31T21:33:19+01:00 INFO [wireguard] Using available kernelspace implementation 2026-10-31T21:33:19+01:00 INFO [wireguard] Connecting to xxxxxxxx:51820 2026-10-31T21:33:19+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-10-31T21:33:25+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-10-31T21:33:25+01:00 INFO [vpn] 👉 See https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md 2026-10-31T21:33:25+01:00 INFO [vpn] DO NOT OPEN AN ISSUE UNLESS YOU HAVE READ AND TRIED EVERY POSSIBLE SOLUTION 2026-10-31T21:33:25+01:00 INFO [vpn] stopping 2026-10-31T21:33:25+01:00 INFO [vpn] starting 2026-10-31T21:33:25+01:00 INFO [firewall] allowing VPN connection... 2026-10-31T21:33:25+01:00 INFO [wireguard] Using available kernelspace implementation 2026-10-31T21:33:25+01:00 INFO [wireguard] Connecting to xxxxxxxxx:51820 2026-10-31T21:33:25+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 Wi
Chris wrote:
Thanks, the full log helps. It shows the VPN getting an exit address in Frankfurt at 21:20, so the key and address are working. After that, the VPN's own checks to 1.1.1.1 and 8.8.8.8 get no reply for long stretches, and it restarts about every six seconds. The Cloudflare connector restarting, the slow site and the dropped PuTTY sessions also point at the box's normal internet connection. The Cloudflare connector does not go through the VPN, so its restarts point at that connection rather than the VPN. This is a hypothesis until we measure it. One read-only test, over PuTTY, run on the NAS itself: ping -c 20 1.1.1.1 If the connection is clean, the end of the output shows 0% packet loss and steady times. If you see lost packets or "Request timed out", the box's own connection is unstable. Send me the last three lines, including the summary line. Also tell me whether sudo sparkbox refresh-vpn-servers finished and printed a success line. Please keep the WIREGUARDMTU lines the doctor printed on hold until we have the ping result.
franciscus wrote:
[ERROR] The refresh failed. Last lines from the updater: 2026-10-31T21:31:01Z INFO merging by most recent 20957 hardcoded servers and 20957 servers read from /gluetun/servers.json 2026-10-31T21:31:01Z INFO updating Surfshark servers... 2026-10-31T21:31:22Z WARN note: if running the update manually, you can use the flag -minratio to allow the update to succeed with less servers found 2026-10-31T21:31:22Z ERROR updating server information: getting surfshark servers: not enough servers found: 185 and expected at least 290 2026-10-31T21:31:22Z INFO Shutdown successful Most common cause: this box can't reach the internet directly. Check that first: sudo sparkbox doctor Your existing server list was left exactly as it was.
franciscus wrote:
[Container Health] [ERROR] sb-cloudflared 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-10-31T21:32:17Z ERR Connection terminated error="failed to dial to edge with quic: timeout: no recent network activity" connIndex=0 │ 2026-10-31T21:32:18Z ERR Connection terminated error="failed to dial to edge with quic: timeout: no recent network activity" connIndex=1 │ 2026-10-31T21:32:20Z ERR Connection terminated error="failed to dial to edge with quic: timeout: no recent network activity" connIndex=3 │ health check: {\"status\":503,\"readyConnections\":0,\"connectorId\":\"[UUIDREDACTED]\"} Try: sudo sparkbox up (and 'sparkbox logs <name' to see why a container is unhappy)
Chris wrote:
Thanks, that output is what I needed. The refresh did not change anything. It reached your VPN provider but got back 185 servers, and it needs at least 290 before it will replace the list. So it stopped, your current list is still in place, and the VPN was not restarted. The line "Most common cause: this box can't reach the internet directly" is a general hint our tool prints for every failed refresh, so it is not a finding about your box yet. A short list can also come from a connection that drops partway through the download, so the connection check still matters. Please don't run the refresh again yet, and keep the WIREGUARDMTU lines on hold. One read-only check over PuTTY, run on the NAS itself: ping -c 20 1.1.1.1 Send me the last three lines, including the summary line with the packet loss. A clean run (0% loss, steady times) points away from the box's own connection and toward the VPN tunnel. Lost packets or timeouts point at the connection. The Cloudflared and PuTTY address questions can wait until we have this result.
franciscus wrote:
Cloudflared keeps crashing and coming back (4 times in 6 hours). More just now · ×4
Chris wrote:
Thanks, this explains the Cloudflare restarts. The connector reports zero ready connections, and its log says it cannot reach Cloudflare's edge at all (the "no recent network activity" lines). The connector only makes outbound connections, so this points at the box's own internet connection, the same place the VPN checks and the failed server-list refresh point. That is still a hypothesis until we measure it. Please skip the "sudo sparkbox up" line from that output for now. Recreating the containers will not change the connection. The next step is the one from my last reply: run ping -c 20 1.1.1.1 on the NAS and send the last three lines, including the summary with the packet loss. Cloudflare Tunnel is optional. If you do not publish any apps through it, you can leave it alone while we check the connection. Please keep the tunnel token out of any post.
franciscus wrote:
I tried 5 times to connect ssh using putty error every time: software caused connection abort
Chris wrote:
Five failed PuTTY attempts in a row is frustrating, and I'm sorry you've had to keep retrying. Please try PuTTY once more and stop after that attempt. Tell me where it fails: either before the login prompt appears (a message like 'Network error: Connection timed out' or 'Connection refused'), or after you log in and it drops later. Either answer narrows it down. If you get in, run this one check and send me the last three lines, including the summary line: ping -c 20 1.1.1.1 Until we have that result, please don't run the refresh or the WIREGUARDMTU lines again.
franciscus wrote:
ping -c 20 1.1.1.1 ping: socktype: SOCKRAW ping: socket: Operation not permitted ping: = missing capnetraw+p capability or setuid?
Chris wrote:
Sorry, the ping command I gave you left out sudo, so it could not run. Your login is a normal user, and on this box ping needs administrator rights to send its test packets. The error is about permissions, not your connection, so there is no result yet. I should have included sudo the first time. Please run it with sudo. It will ask for your admin password: type it into PuTTY, and do not paste it here. sudo ping -c 20 1.1.1.1 When it finishes, send the last three lines, including the summary line that shows packet loss. Please still hold the refresh and the WIREGUARDMTU lines until we have that result.
franciscus wrote:
--- 1.1.1.1 ping statistics --- 20 packets transmitted, 8 received, 60% packet loss, time 19236ms rtt min/avg/max/mdev = 7.107/7.475/8.731/0.578 ms
Chris wrote:
Thanks, that result is the one we needed. 12 of the 20 test packets to 1.1.1.1 got no reply, and the test ran on the NAS itself, outside the VPN. So the trouble is in the box's own connection to the internet. The VPN restarts, the Cloudflare restarts and the dropped PuTTY sessions most likely come from that same link. This is our best reading of the evidence so far, not yet the exact faulty part. One check next, to tell whether the NAS or the shared line is at fault. From a Windows PC on the same network (plugged into the same router, or on the same Wi-Fi), open Command Prompt and run: ping -n 20 1.1.1.1 If the PC also loses packets, the problem is upstream of the NAS: the router, its cable or the internet line. If the PC is clean, the fault is in the NAS's own network link, and I will give you the next step for that. Until we have that answer, please leave the VPN server refresh and the WIREGUARDMTU lines alone. They address the VPN, not packets lost on the link itself.
franciscus wrote:
--- 1.1.1.1 ping statistics --- 20 packets transmitted, 20 received, 0% packet loss, time 19023ms rtt min/avg/max/mdev = 7.015/7.187/7.332/0.076 ms the cable from the nas to the switch was defect
Chris wrote:
Thank you for tracing that. The earlier test showed 12 of 20 packets lost on the NAS's own link, and a faulty cable between the NAS and the switch fits that, along with the dropped PuTTY sessions, the VPN restarts and the Cloudflare connector restarts. Please tell me two things: did you replace or reseat that cable, and was the 0% loss result from the sudo ping run on the NAS itself? Then leave the box alone for ten minutes and tell me whether the VPN step on the Media pipeline stays green and PuTTY stays connected. If both hold, we can retry the VPN server list refresh next. Please don't run that refresh until then.
franciscus wrote:
everything works, replaced the cable, vpn works no errors, and that command no packet losses.
Chris wrote:
Thanks for working through every step, and I'm sorry it took several rounds and some dropped PuTTY sessions to find this. The first ping from the NAS lost 12 of 20 packets, so the link between the NAS and the switch was dropping packets. That most likely explains the dropped SSH sessions, the VPN tunnel restarting and the Cloudflare connector restarting. After the cable was replaced, the same ping on the NAS shows 0% loss, so the connection is clean again. No further changes are needed. Please leave the VPN server list refresh and the WIREGUARDMTU settings alone while the box is stable. If the VPN step goes red again, PuTTY drops, or Cloudflare starts restarting, send us the time and the last line you see, and we'll pick it up from there.