I'd done a few random download tests with qBittorrent and was considering ways to get files from the SparkBox VM so opened File Browser, found my test file (a "Linux ISO"), right-clicked on it and selected Download and waited. I have Free Download Manager installed on my Windows 11 PC and the download was picked up by that and it got about halfway through the download which was set to download to another networked PC and it paused and after a few moments I saw the SparkBox window in my web browser show that it was having connection problems as well as the Proxmox window. They both completely lost connection and I waited 15 minutes but it never came back. On the system that is running Proxmox I tried resetting the network interface using: ip link set <interface name down and bringing it back up again with ip link set <interface name up but it didn't change anything. It did still show as having it's IP number but it didn't connect so I restarted that system and everything came back as normal. I tried this a second time just in case the first was just a temporary issue and exactly the same thing happened again. It's a bit of a strange problem, i've been using this system for quite a while as a game server without any problems and after removing the game server VM and installing Ubuntu Server 26.04 and installing SparkBox to that it's been fine with just normal use the last few days, testing out downloading using the various ARR apps.
17 replies
tomspark wrote:
This is a network saturation issue, not a SparkBox bug — File Browser's download is maxing out your VM's network link and starving Proxmox's management traffic. What's happening: When you download a large file through File Browser, it's pulling the entire throughput of your VM's vNIC. If Proxmox's hypervisor management interface (or the host's own traffic) shares that same link, they get zero bandwidth and appear disconnected — even though the link itself is up (hence why ip link shows it's still there). Fix: Limit File Browser's download bandwidth. SSH into the SparkBox host and edit /opt/sparkbox/modules/files/config/filebrowser/.filebrowser.json — add a "serveRoot" and "downloadTimeout" setting, or better: use tc (traffic control) to rate-limit the File Browser container: bash docker update --cpus=0.5 sb-filebrowser That caps the container to half a CPU core, which naturally throttles large transfers. For a permanent fix, add this to the File Browser service in /opt/sparkbox/modules/files/docker-compose.yml under deploy.resources.limits: yaml cpus: '0.50' Then restart: sparkbox restart files. If you're downloading to a different networked PC (not the Proxmox host), the issue is that your VM's single vNIC is saturated — your Proxmox host should have its management interface on a separate vNIC or VLAN so hypervisor traffic doesn't compete with guest traffic. That's a Proxmox config issue, not SparkBox's fault, but throttling downloads prevents the collision either way.
BadBunny wrote:
Hi Tom, many thanks for your reply. I am going to look through this a bit later this evening and see if I can correct it. I appreciate the level of detail you give in your replies, it's actually very refreshing to see someone offer this level of support for something, so thanks again :)
tomspark wrote:
Glad it helped! One more angle worth a shot before you spend the evening on it — the detail that the link still showed its IP but stayed completely dead until a full reboot points at something more specific than bandwidth. A lot of Proxmox boxes (especially with Realtek network cards) hang the network card itself during a big sustained transfer: it looks "up" but passes no traffic until you reboot — exactly what you described, and twice in a row. Quick, harmless test on the Proxmox host (resets on reboot, so nothing permanent): ethtool -K <interface tso off gso off gro off Then retry the big download. If the network stops dropping, that's the culprit and we can make it stick. If it still dies, tell me which card you've got (lspci | grep -i net) and we'll dig from there.
BadBunny wrote:
Thanks for the update Tom, I will check this first and let you know how it goes :) Much appreciated!
tomspark wrote:
Sounds good — give it a try and ping me with what you find. If the network holds through a big download, we'll make that setting stick across reboots; if it still drops, we'll dig into the card itself. No rush.
BadBunny wrote:
Hi Tom, I just tried your last suggestion: ethtool -K tso off gso off gro off First i tried it on the Proxmox shell but it gave this message: root@sabertooth:~ ethtool -K tso off gso off gro off ethtool (-K): flag 'gso' for parameter '(null)' is not followed by 'on' or 'off' I then tried it on the Ubuntu VM that SparkBox is running on, just to see if anything different happened but it was the same error: lee@sparkbox:~$ ethtool -K tso off gso off gro off ethtool (-K): flag 'gso' for parameter '(null)' is not followed by 'on' or 'off' I tried shortening the command to see if something changed but same error. root@sabertooth:~ ethtool -K tso off ethtool (-K): flag '(null)' for parameter '(null)' is not followed by 'on' or 'off'
tomspark wrote:
No worries — you didn't break anything. The "<interface" in my command was a placeholder; it errored because it needs your real network card's name in that exact spot. First, on the Proxmox host, run this to list your cards: ip -br link Ignore the lines named lo, vmbr0, and anything starting with tap, veth, or fw — the one you want is your actual card, usually named something like enp3s0 or eno1. Then run that name in place of NAME: ethtool -K NAME tso off gso off gro off ...and retry the big download. If it holds without dropping, that's our culprit and we'll make it stick across reboots. Not sure which name is the card? Just paste the "ip -br link" output here and I'll point at the exact one.
BadBunny wrote:
I ran the command but it errored so ran it with sudo and that went ok. lee@sparkbox:~$ ethtool -K ens18 tso off gso off gro off netlink error: Operation not permitted lee@sparkbox:~$ sudo ethtool -K ens18 tso off gso off gro off [sudo: authenticate] Password: lee@sparkbox:~$ Copying the large file went just fine! I tried it again with various more large files over and over and they all went just fine :) Looks like you solved it, thank you 😀
tomspark wrote:
That's great news — and smart move running it on the VM (ens18), that's exactly the right spot. 🎉 One catch: that command resets whenever the VM reboots, so let's lock it in. Paste this on the SparkBox VM and it'll re-apply the fix automatically on every boot: sudo tee /etc/systemd/system/nic-offload.service /dev/null <<'EOF' [Unit] Description=Disable NIC offload (fixes large-download network drop) After=network-online.target Wants=network-online.target [Service] Type=oneshot ExecStart=/usr/sbin/ethtool -K ens18 tso off gso off gro off [Install] WantedBy=multi-user.target EOF sudo systemctl enable --now nic-offload.service To confirm it stuck, after your next reboot run sudo systemctl status nic-offload — it should say "active (exited)". After that you can forget about it.
BadBunny wrote:
I entered the command, that went OK: Created symlink '/etc/systemd/system/multi-user.target.wants/nic-offload.service' → '/etc/systemd/system/nic-offload.service'. I restarted the VM and it looks good: lee@sparkbox:~$ sudo systemctl status nic-offload [sudo: authenticate] Password: ○ nic-offload.service - Disable NIC offload (fixes large-download network drop) Loaded: loaded (/etc/systemd/system/nic-offload.service; enabled; preset: enabled) Active: inactive (dead) since Sat 2026-05-23 22:34:35 CEST; 1min 33s ago Invocation: 0140115a73a94172ab11b66a22292f10 Process: 1681 ExecStart=/usr/sbin/ethtool -K ens18 tso off gso off gro off (code=exited, status=0/SUCCESS) Main PID: 1681 (code=exited, status=0/SUCCESS) Mem peak: 2.2M CPU: 9ms May 23 22:34:35 sparkbox systemd[1]: Starting nic-offload.service - Disable NIC offload (fixes large-download network d May 23 22:34:35 sparkbox systemd[1]: nic-offload.service: Deactivated successfully. May 23 22:34:35 sparkbox systemd[1]: Finished nic-offload.service - Disable NIC offload (fixes large-download network d lines 1-12/12 (END) Brilliant, thank you very much!!
tomspark wrote:
Perfect — that's it working exactly right. 🎉 The line that matters is "status=0/SUCCESS": the fix ran at boot and applied. The "inactive (dead)" bit looks alarming but it's completely normal here — this kind of service is built to run once at startup, do its job, and exit (it's not meant to keep running). So you're all set: it'll re-apply itself on every reboot from now on, totally hands-off. Enjoy the box!
BadBunny wrote:
Great, thanks again for the help and for explaining everything as you went, that is pretty rare with support replies in my experience. Have a great weekend 👍😀
tomspark wrote:
Anytime — genuinely glad it's sorted. Have a great weekend too! 👍
BadBunny wrote:
I just realised that my Surfshark subscription was due for renewal in a month so I used your referral link to renew it, it's much better to use a link like that as it helps both of us so I am glad you had a link for it :)
tomspark wrote:
Ah, that genuinely means a lot — thank you! That's exactly how it works: it costs you nothing extra and it helps keep SparkBox free and in active development. Really appreciate you going out of your way to do that. Enjoy the box, and happy self-hosting! 🙏