tried to open qbittorrent and it opens a new window that simply says "unauthorized". I was able to radarr to connect on setup. here is the log: Connecting... S2026-05-17T21:23:00.772505285Z [custom-init] No custom services found, skipping... 42026-05-17T21:23:00.856924126Z [migrations] started @2026-05-17T21:23:00.857008224Z [migrations] no migrations found �2026-05-17T21:23:00.925165603Z ─────────────────────────────────────── 2026-05-17T21:23:00.925191994Z k2026-05-17T21:23:00.925199092Z ██╗ ███████╗██╗ ██████╗ p2026-05-17T21:23:00.925204709Z ██║ ██╔════╝██║██╔═══██╗ j2026-05-17T21:23:00.925209546Z ██║ ███████╗██║██║ ██║ j2026-05-17T21:23:00.925214110Z ██║ ╚════██║██║██║ ██║ z2026-05-17T21:23:00.925219170Z ███████╗███████║██║╚██████╔╝ u2026-05-17T21:23:00.925223869Z ╚══════╝╚══════╝╚═╝ ╚═════╝ 2026-05-17T21:23:00.925228489Z C2026-05-17T21:23:00.925232623Z Brought to you by linuxserver.io �2026-05-17T21:23:00.925237505Z ─────────────────────────────────────── 2026-05-17T21:23:00.925466859Z ?2026-05-17T21:23:00.925485737Z To support LSIO projects visit: B2026-05-17T21:23:00.925492662Z https://www.linuxserver.io/donate/ 2026-05-17T21:23:00.925497583Z �2026-05-17T21:23:00.925506989Z ─────────────────────────────────────── '2026-05-17T21:23:00.925512458Z GID/UID �2026-05-17T21:23:00.925516853Z ─────────────────────────────────────── 2026-05-17T21:23:00.928822969Z 12026-05-17T21:23:00.928843434Z User UID: 1000 /2026-05-17T21:23:00.928849590Z User GID: 10 �2026-05-17T21:23:00.928854273Z ─────────────────────────────────────── K2026-05-17T21:23:00.930219238Z Linuxserver.io version: 5.2.0v2.0.12-ls457 E2026-05-17T21:23:00.930420946Z Build-date: 2026-05-13T10:53:59+00:00 �2026-05-17T21:23:00.930454995Z ─────────────────────────────────────── $2026-05-17T21:23:00.930464984Z P2026-05-17T21:23:01.005114683Z [custom-init] No custom files found, skipping... i2026-05-17T21:23:01.103523382Z WebUI will be started shortly after internal preparations. Please wait... 2026-05-17T21:23:01.186363483Z =2026-05-17T21:23:01.186388486Z Information b2026-05-17T21:23:01.186392416Z To control qBittorrent, access the WebUI at: http://localhost:8080 J2026-05-17T21:23:01.186432419Z The WebUI administrator username is: admin �2026-05-17T21:23:01.186449637Z The WebUI administrator password was not set. A temporary password is provided for this session: X2026-05-17T21:23:01.186455614Z You should set your own password in program preferences. a2026-05-17T21:23:02.033400027Z Connection to localhost (::1) 8080 port [tcp/http-alt] succeeded! 22026-05-17T21:23:02.043109934Z [ls.io-init] done.
44 replies
tomspark wrote:
You've hit the same qBit bug as jackhammer57 — third report of it now, all on UGREEN NAS. It's on our side: the install-time password isn't sticking, qBit mints a fresh random one every boot, and after enough failed auto-login attempts from the dashboard, qBit flips its webserver into "no login form" lockdown across every IP. Manual unstick (~1 min): sudo docker stop sb-qbittorrent && sudo rm -rf /opt/sparkbox/modules/media/config/qbittorrent && sudo sparkbox up media Then grab the fresh temp password from the last "A temporary password is provided for this session:" line in sparkbox logs sb-qbittorrent. Open http://YOUR-NAS-IP:8089 DIRECTLY (not via the dashboard's Open button — that's what re-triggers the loop), sign in with admin + that password, then immediately go to Settings → Web UI and set your own permanent password. After that the rotation stops for good. Real fix queued on our side.
tomspark wrote:
You didn't break anything — this is a known SparkBox-side hiccup where qBittorrent sometimes starts up without the password we set for it, so the dashboard's auto-login gets bounced with "unauthorized." Quick way back in: open the qBittorrent log (the Logs view in the dashboard, or run sparkbox logs sb-qbittorrent) and find the line "A temporary password is provided for this session:" — the password is printed right after it. Go to http://localhost:8080, sign in with username admin and that temporary password, then set a permanent one in qBittorrent's Settings, Web UI tab. That unblocks you right now. To help us fix the actual cause so the dashboard button stops doing this, paste the full output of sparkbox logs sb-qbittorrent here — that log is the one thing we need to pin it down.
jackhammer57 wrote:
Joe@DXP4800PRO-868A:/volume2$ sparkbox logs sb-qbittorrent [custom-init] No custom services found, skipping... [migrations] started [migrations] no migrations found ─────────────────────────────────────── ██╗ ███████╗██╗ ██████╗ ██║ ██╔════╝██║██╔═══██╗ ██║ ███████╗██║██║ ██║ ██║ ╚════██║██║██║ ██║ ███████╗███████║██║╚██████╔╝ ╚══════╝╚══════╝╚═╝ ╚═════╝ Brought to you by linuxserver.io ─────────────────────────────────────── To support LSIO projects visit: https://www.linuxserver.io/donate/ ─────────────────────────────────────── GID/UID ─────────────────────────────────────── User UID: 1000 User GID: 10 ─────────────────────────────────────── Linuxserver.io version: 5.2.0v2.0.12-ls457 Build-date: 2026-05-13T10:53:59+00:00 ─────────────────────────────────────── [custom-init] No custom files found, skipping... WebUI will be started shortly after internal preparations. Please wait... Information To control qBittorrent, access the WebUI at: http://localhost:8080 The WebUI administrator username is: admin The WebUI administrator password was not set. A temporary password is provided for this session: Nm8sQGYIv You should set your own password in program preferences. Connection to localhost (::1) 8080 port [tcp/http-alt] succeeded! [ls.io-init] done. Catching signal: SIGTERM Exiting cleanly [custom-init] No custom services found, skipping... [migrations] started [migrations] no migrations found usermod: no changes ─────────────────────────────────────── ██╗ ███████╗██╗ ██████╗ ██║ ██╔════╝██║██╔═══██╗ ██║ ███████╗██║██║ ██║ ██║ ╚════██║██║██║ ██║ ███████╗███████║██║╚██████╔╝ ╚══════╝╚══════╝╚═╝ ╚═════╝ Brought to you by linuxserver.io ─────────────────────────────────────── To support LSIO projects visit: https://www.linuxserver.io/donate/ ─────────────────────────────────────── GID/UID ─────────────────────────────────────── User UID: 1000 User GID: 10 ─────────────────────────────────────── Linuxserver.io version: 5.2.0v2.0.12-ls457 Build-date: 2026-05-13T10:53:59+00:00 ─────────────────────────────────────── [custom-init] No custom files found, skipping... WebUI will be started shortly after internal preparations. Please wait... Information To control qBittorrent, access the WebUI at: http://localhost:8080 The WebUI administrator username is: admin The WebUI administrator password was not set. A temporary password is provided for this session: 3J8UzpbI2 You should set your own password in program preferences. Connection to localhost (::1) 8080 port [tcp/http-alt] succeeded! [ls.io-init] done. when I try to go through localhost I get safari can't connect to server
tomspark wrote:
Two things. Quick one: localhost only works when typed ON the NAS itself — from your Mac, Safari reads that as your Mac, not the NAS. Use the NAS's own address instead: http://YOUR-NAS-IP:8080 (same IP as your SparkBox dashboard, just with :8080). Bigger one: your log shows qBittorrent restarting and minting a brand-new random password every boot instead of keeping the one we set for it — that's a real bug on our side, not anything you did, and it hits UGREEN NAS setups specifically. I've logged it with your full log and we're on a fix. If the page loads at the NAS IP, set your own password in qBittorrent's Settings, Web UI tab so it stops rotating; if it won't stay up at all, that's the same bug — sit tight. Thanks for the full log, that's exactly what pinned it down.
jackhammer57 wrote:
myIP:8080 gives me safari can't connect to server myIP:8089 is unauthorized
tomspark wrote:
My mistake on the port — it's 8089, not 8080 (qBit lives on 8089 on the NAS; my earlier number was wrong, sorry). The 8089 "unauthorized" is qBit reachable but the dashboard's auto-login still hitting the same bug. To get in manually: open http://your-NAS-IP:8089 (that's the qBit login page), username is admin. For the password — since it changes every reboot — grab the current one fresh: run sparkbox logs sb-qbittorrent (or open the qBittorrent log in the dashboard) and find the line "A temporary password is provided for this session:" — copy what's right after it. Paste that. Once you're in, go to qBittorrent's Settings → Web UI and set your own permanent password. That stops the rotation on your side for good.
jackhammer57 wrote:
I think there might be a problem with gluetun. VPN banner shows vpn check failed
tomspark wrote:
Good catch — that's likely the real root, and the qBit chase was a fork off the actual problem. qBit routes all its traffic through gluetun's VPN tunnel, so if gluetun's VPN check is failing, qBit keeps restart-looping behind it and never stays up long enough to keep a password — which also explains the brand-new temp password every boot. Let's fix gluetun first. Grab its log: sudo sparkbox logs sb-gluetun The last 20–30 lines will say exactly what failed — usually a wrong VPN provider, bad credentials, or gluetun can't reach the VPN servers. Paste them here and I'll point at the single setting to change. Once gluetun is green, the qBit password thing should settle on its own.
jackhammer57 wrote:
myNASIP:8089 still giving unauthorized error.
tomspark wrote:
That "unauthorized" on 8089 will keep happening until gluetun is fixed — qBit is just a downstream symptom of the VPN check failing. We can't fix qBit directly while the VPN underneath it is unhealthy. So one thing I need from you: paste the output of sudo sparkbox logs sb-gluetun (just the last 20-30 lines). That tells me exactly what failed about your VPN setup and I can give you the one-line fix. The qBit page will heal on its own once gluetun is happy.
jackhammer57 wrote:
here is the log: 2026-05-19T11:03:03-07:00 INFO [routing] default route found: interface eth0, gateway 172.20.4.1, assigned IP 172.20.4.2 and family v4 2026-05-19T11:03:03-07:00 INFO [routing] adding route for 0.0.0.0/0 2026-05-19T11:03:03-07:00 INFO [firewall] setting allowed subnets... 2026-05-19T11:03:03-07:00 INFO [routing] default route found: interface eth0, gateway 172.20.4.1, assigned IP 172.20.4.2 and family v4 2026-05-19T11:03:03-07:00 INFO [routing] adding route for 192.168.0.0/16 2026-05-19T11:03:03-07:00 INFO [routing] adding route for 10.0.0.0/8 2026-05-19T11:03:03-07:00 INFO [routing] adding route for 172.16.0.0/12 2026-05-19T11:03:03-07:00 INFO [firewall] setting allowed input port 8989 through interface eth0... 2026-05-19T11:03:03-07:00 INFO [firewall] setting allowed input port 7878 through interface eth0... 2026-05-19T11:03:03-07:00 INFO [firewall] setting allowed input port 9696 through interface eth0... 2026-05-19T11:03:03-07:00 INFO [firewall] setting allowed input port 8686 through interface eth0... 2026-05-19T11:03:03-07:00 INFO [firewall] setting allowed input port 8080 through interface eth0... 2026-05-19T11:03:03-07:00 INFO [firewall] setting allowed input port 8191 through interface eth0... 2026-05-19T11:03:03-07:00 INFO [firewall] setting allowed input port 6767 through interface eth0... 2026-05-19T11:03:03-07:00 INFO [dns] using plaintext DNS at address 1.1.1.1 2026-05-19T11:03:03-07:00 INFO [healthcheck] listening on 127.0.0.1:9999 2026-05-19T11:03:03-07:00 INFO [http server] http server listening on [::]:8000 2026-05-19T11:03:03-07:00 INFO [firewall] allowing VPN connection... 2026-05-19T11:03:03-07:00 INFO [wireguard] Using available kernelspace implementation 2026-05-19T11:03:03-07:00 INFO [wireguard] Connecting to 146.70.202.50:51820 2026-05-19T11:03:03-07: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-05-19T11:03:08-07:00 INFO [dns] downloading hostnames and IP block lists 2026-05-19T11:03:08-07:00 INFO [dns] DNS server listening on [::]:53 2026-05-19T11:03:09-07:00 INFO [dns] ready 2026-05-19T11:03:12-07:00 INFO [ip getter] Public IP address is 185.220.69.155 (United States, New York, New York City - source: ipinfo+ifconfig.co+ip2location+cloudflare) 2026-05-19T11:03:12-07:00 INFO [vpn] You are running the latest release v3.41.1
tomspark wrote:
Good news first — your gluetun log shows it working fine. It connected to Mullvad's NYC server and is routing traffic through it. The dashboard's "VPN check failed" banner is just stale, ignore it. For the 8089 unauthorized — the password we set on install isn't sticking on UGREEN NAS (real bug on our side), so qBit hands out a fresh temp one every restart. Run sparkbox logs sb-qbittorrent again and scroll to the very bottom — the most recent "A temporary password is provided for this session:" line has the current password (it rotated, so it's not what you saw earlier). Copy that, go to http://YOUR-NAS-IP:8089, sign in with admin + that fresh password. Then in qBittorrent's Settings → Web UI, set your own permanent password. That ends the rotation.
jackhammer57 wrote:
is there another way to input the username and password? because the web browser won't even go to login page, just goes direct to unauthorized.
tomspark wrote:
That "Unauthorized" page with no login form is qBit's own auto-block kicking in — the dashboard's auto-login button keeps trying the old (rotated) password, qBit sees those as failed attempts, and after a few it refuses all connections from your computer. The login form sits behind that block. Two steps to break out: sparkbox restart media (20 seconds, restarts the media stack and clears the block) Then open a private/incognito browser window (Cmd-Shift-N in Safari) and visit http://YOUR-NAS-IP:8089 — you should see a real login form this time. Grab the most recent temp password from the very bottom of sparkbox logs sb-qbittorrent and sign in with admin + that password. Then go straight to Settings → Web UI and set your own permanent password — that breaks the cycle for good. Don't click the dashboard's Open qBittorrent button between now and then, or the block recurs.
jackhammer57 wrote:
Even in private mode it still went to the unauthorised page. I’m shutting down for the night. We shall continue tomorrow.
tomspark wrote:
Roger that, get some sleep. The restart + private window not clearing it tells me it's not the live block I thought — qBit is actually remembering your computer as a denied client across restarts. That memory expires on its own after about an hour, but each retry probably refreshes it. I'll have a clean unstick for you tomorrow morning, just ping me when you're back on it.
UnCoNoob wrote:
I am also getting this error as well. The logs show the password and when I click on the app in the dashboard, it shows the password as well but they are not the same. When I open it in a browser there is no pop up to enter the username or password. I have tried Incongnito, connected through Tailscale, through my phone on a total different IP and browser. They all throw this error and not provide a sign in box.
UnCoNoob wrote:
Thanks, I have installed on VM but it is showing NAS device in the settings. I tried this and opened in private browser and manually typed in the address, There is no log in screen to enter the password and the same Unauthorized error message pops up
tomspark wrote:
Good — the wipe DID work (you got a fresh config), which actually rules OUT the earlier theory and points at the real cause: qBit's own Host Header check. qBit 5.x defaults to rejecting any request whose Host header doesn't match what it expects, and accessing via a raw IP doesn't match — so it returns "Unauthorized" with no login form. Same behavior at every IP you tried, because the Host header is what gets rejected, not the source. One command disables it: sudo bash -c 'echo "WebUI\\HostHeaderValidation=false" /opt/sparkbox/modules/media/config/qbittorrent/qBittorrent/qBittorrent.conf' && sudo docker restart sb-qbittorrent Wait 20s. http://YOUR-VM-IP:8089 should finally show a real login form. Grab the latest temp password from sparkbox logs sb-qbittorrent and sign in, then set a permanent password in Settings → Web UI. Re: the "NAS device" showing on your VM — separate detection bug, doesn't break anything functional but I've flagged it.
UnCoNoob wrote:
I still get Unauthorized show up. Installed a new browser to make sure its not the cache ran the command again and logged in manually typing the address still the same issue
tomspark wrote:
Damn, that should've worked. Need to see what's actually in the conf to diagnose. Run: sudo find /opt/sparkbox/modules/media/config/qbittorrent -name qBittorrent.conf | sudo xargs cat Paste everything it prints (especially the [Preferences] section). Two possibilities: my command wrote to a path qBit doesn't actually read, or qBit overwrites the conf from in-memory state on every restart — wiping our HostHeaderValidation=false line each time. Either way, the conf contents will tell me which.
UnCoNoob wrote:
Hey here is the output, Seems it did not add the line. Could I just enter it manually with nano and save? [AutoRun] enabled=false program= [BitTorrent] Session\AddTorrentStopped=false Session\DefaultSavePath=/downloads/ Session\Port=6881 Session\QueueingSystemEnabled=true Session\SSL\Port=51786 Session\ShareLimitAction=Stop Session\TempPath=/downloads/incomplete/ [LegalNotice] Accepted=true [Meta] MigrationVersion=8 [Network] Cookies=@Invalid() PortForwardingEnabled=false Proxy\HostnameLookupEnabled=false Proxy\Profiles\BitTorrent=true Proxy\Profiles\Misc=true Proxy\Profiles\RSS=true [Preferences] Connection\PortRangeMin=6881 Connection\UPnP=false Downloads\SavePath=/downloads/ Downloads\TempPath=/downloads/incomplete/ WebUI\Address= WebUI\ServerDomains=
UnCoNoob wrote:
Also notice all has a single backslash but the command above has a double would this be an issue?
tomspark wrote:
Nice catch — two things from that paste. (1) My line never made it into the file because qBit overwrites the conf from in-memory state on SIGTERM, and docker restart issues a SIGTERM before bring-up. Right order is stop → edit → start, not append → restart. (2) You already have WebUI\ServerDomains= in there, which actually accepts any Host header — so my host-check theory was off too. Going more aggressive: bypass auth entirely. Run this exact command: sudo docker stop sb-qbittorrent && sudo bash -c 'printf "WebUI\\AuthSubnetWhitelistEnabled=true\nWebUI\\AuthSubnetWhitelist=0.0.0.0/0\n" /opt/sparkbox/modules/media/config/qbittorrent/qBittorrent/qBittorrent.conf' && sudo docker start sb-qbittorrent That tells qBit to skip auth for any source IP. Hit your VM IP at :8089 — should drop you straight into qBit's UI with no auth prompt. Once you're in, go to Settings → Web UI and set a real password (the bypass is safe behind your LAN, but a permanent password is cleaner). On single vs double backslashes — your eye is right, the file uses single. In bash, double \\ collapses to single \ after parsing, so the file actually gets one. Restart-overwrite is what killed the last attempt, not the syntax.
UnCoNoob wrote:
I added it manually to the qBittorrent.conf and restarted the container. when it starts it deletes the entry
tomspark wrote:
Hold on — I shouldn't have recommended the AuthSubnetWhitelist=0.0.0.0/0 bypass earlier. That disables auth entirely from any source, which is a security weakening I shouldn't have posted even as a temporary workaround. Walking it back. Glad it didn't stick. Your finding (qBit deletes the entry on restart) is actually really useful — it means qBit normalizes the conf on every start, dropping keys outside its expected allowlist. So no manual file edit will work. Different approach — verify whether auth itself works by hitting qBit's API directly, bypassing browser-side rendering. Two commands. First grab the current temp password from logs: sudo docker logs sb-qbittorrent 2&1 | grep "temporary password" | tail -1 Copy what's after "session:". Then (replace PASTE with that password): curl -i http://localhost:8089/api/v2/auth/login --data "username=admin&password=PASTE" Paste the full response. "Ok." with HTTP 200 = auth works and only your browser's rendering is broken (different fix). 401/403 = the temp password isn't being accepted = the root bug we've been chasing.
jackhammer57 wrote:
Good morning Tom, found this on reddit.... Add the following line to the qBittorrent.conf file: WebUI\HostHeaderValidation=false Make sure the docker container has been shutdown before editing qBittorrent.conf. This is because the conf file is written to on shutdown, so any changes made whilst it's still running will be lost otherwise. reading through the updates am I right to assume that is what this line was trying to do? sudo bash -c 'echo "WebUI\\HostHeaderValidation=false" /opt/sparkbox/modules/media/config/qbittorrent/qBittorrent/qBittorrent.conf' && sudo docker restart sb-qbittorrent I think he said it didn't work. Was the container shutdown before the edit? I didn't see that mentioned.
jackhammer57 wrote:
just logged into sparkbox and now qbit is missing
tomspark wrote:
You're right on both counts. That reddit line is the same setting I was trying to set, and the gotcha you spotted is the bug in my command order: qBit overwrites the conf when it shuts down, so the edit has to land while the container is fully stopped, not just restarted. My docker restart reorder was wrong. Sorry for the loop. Put that on pause though, your other post (qBit, Radarr and Prowlarr missing) is the bigger thing now. Replying there next, one command brings them back. We can pick the host-header trick back up once qBit is actually present again.
jackhammer57 wrote:
then would this be correct to get it to work? sudo docker stop sb-qbittorrent sudo bash -c 'echo "WebUI\\HostHeaderValidation=false" /opt/sparkbox/modules/media/config/qbittorrent/qBittorrent/qBittorrent.conf' sudo docker restart sb-qbittorrent
tomspark wrote:
Your order is correct in shape — stop → edit → start is the right move. But UnCoNoob already tested that flow and qBit still wiped the HostHeaderValidation line on the next startup. qBit normalizes its own conf and drops keys outside its expected list, so any on-disk edit is a dead end for this version. Get qBit back first with sudo sparkbox up media from the other thread. Once the container exists again we'll go at the unauth via qBit's API directly — that path doesn't depend on the conf surviving, and tells us whether the bug is auth itself or just the login form rendering.
jackhammer57 wrote:
so I have qbit and the there containers up and healthy now
tomspark wrote:
Nice. Now to check whether qBit's actually refusing auth or just hiding the login form. Two commands — first grabs the current temp password from logs, second tests login against qBit's API directly: sudo docker logs sb-qbittorrent 2&1 | grep "temporary password" | tail -1 Copy what comes after "session:". Then (replace PASTE with that password): curl -i http://localhost:8089/api/v2/auth/login --data "username=admin&password=PASTE" Paste the full response. If it ends with "Ok." then auth works and only the form rendering is broken — I've got a one-shot fix. If it returns 401, the bug is deeper and we go a different route.
jackhammer57 wrote:
comes up with 401 error HTTP/1.1 401 Unauthorized connection: keep-alive content-length: 12 content-security-policy: default-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; script-src 'self' 'unsafe-inline'; object-src 'none'; form-action 'self'; frame-src 'self' blob:; frame-ancestors 'self'; content-type: text/plain; charset=UTF-8 cross-origin-opener-policy: same-origin date: Thu, 21 May 2026 22:17:12 GMT referrer-policy: same-origin x-content-type-options: nosniff x-frame-options: SAMEORIGIN x-xss-protection: 1; mode=block
tomspark wrote:
401 with no Set-Cookie is qBit rejecting the credentials specifically — not a malformed request, not a missing endpoint. Could be either (a) the temp password rotated again between the log line and your curl, or (b) qBit's anti-bruteforce or whitelist is blocking everything. Quickest way to split that: curl -i http://localhost:8089/api/v2/app/version If that returns 401 too, it's a global block (not your password). If it returns a version string, the password is the problem — re-grab the freshest one from logs (each restart mints a new one) and retry the auth call.
jackhammer57 wrote:
that also returned a 401 error
tomspark wrote:
Sorry for the runaround. The host-header edits kept vanishing because qBit drops any setting it doesn't recognize on restart — but the password field is qBit's OWN, so it WILL stick. That also kills the root problem: qBit's been minting a new random password every reboot (the bug on our side), and setting a permanent one stops that. Do this with qBit fully stopped (it rewrites the file on shutdown, exactly as you spotted): 1. sudo docker stop sb-qbittorrent 2. sudo nano /opt/sparkbox/modules/media/config/qbittorrent/qBittorrent/qBittorrent.conf 3. Find the [Preferences] line. Delete any existing line starting with WebUI\PasswordPBKDF2, then paste this directly under [Preferences]: WebUI\PasswordPBKDF2="@ByteArray(mfu3xCOwW27rzGVYWJW2fQ==:GbVvlitRBcBVjZ5vwvuYS9tOLUcV57KEyC3yNzcQGhdlH6H4GrJkNabQl4ZdOFQJZP8qUW8rOLEKOkkp+IanJQ==)" 4. Save (Ctrl-O, Enter, Ctrl-X), then: sudo sparkbox up media Now open your-NAS-IP:8089 and log in with admin / SparkBoxTemp2026 — then change it in Settings, Web UI right away (that password is public here). We're shipping a fix so it sticks on its own; your debugging nailed the cause.
tomspark wrote:
Quick correction to my last comment before you run it — drop the double-quotes around the @ByteArray part. qBit returns 401 if that value is quoted (known gotcha, and it's exactly the error you're already seeing). Use this exact line instead, no quotes: WebUI\PasswordPBKDF2=@ByteArray(mfu3xCOwW27rzGVYWJW2fQ==:GbVvlitRBcBVjZ5vwvuYS9tOLUcV57KEyC3yNzcQGhdlH6H4GrJkNabQl4ZdOFQJZP8qUW8rOLEKOkkp+IanJQ==) Everything else is the same: stop qBit, edit the conf, save, then sudo sparkbox up media. Log in with admin / SparkBoxTemp2026 and change it right away. Sorry for the back-and-forth.
jackhammer57 wrote:
this is what comes up [Preferences] Connection\PortRangeMin=6881 Connection\UPnP=false Downloads\SavePath=/downloads/ Downloads\TempPath=/downloads/incomplete/ WebUI\Address= WebUI\ServerDomains=
tomspark wrote:
Perfect — that confirms it: there's no password line at all, which is exactly the bug. Just add this single line inside that [Preferences] block (right under the [Preferences] header is fine), with qBit stopped: WebUI\PasswordPBKDF2=@ByteArray(mfu3xCOwW27rzGVYWJW2fQ==:GbVvlitRBcBVjZ5vwvuYS9tOLUcV57KEyC3yNzcQGhdlH6H4GrJkNabQl4ZdOFQJZP8qUW8rOLEKOkkp+IanJQ==) Save, then: sudo sparkbox up media Open your-NAS-IP:8089 and log in with admin / SparkBoxTemp2026, then change it in Settings → Web UI. That password's public here, so change it right away. (We just shipped a fix so new installs set this automatically — you're the last person who'll have to do it by hand.)
jackhammer57 wrote:
so there is no password line so add like this? [Preferences] WebUI\PasswordPBKDF2=@ByteArray(mfu3xCOwW27rzGVYWJW2fQ==:GbVvlitRBcBVjZ5vwvuYS Connection\PortRangeMin=6881 Connection\UPnP=false Downloads\SavePath=/downloads/ Downloads\TempPath=/downloads/incomplete/ WebUI\Address= WebUI\ServerDomains=
tomspark wrote:
Yep, that's exactly right — line goes right under [Preferences], unquoted. The you see at the end is just nano telling you the line runs off the right edge of the screen (it's a long line); the whole value is still there on that one line, which is what you want. Just don't press Enter anywhere inside it. Save (Ctrl-O, Enter), exit (Ctrl-X), then: sudo sparkbox up media Then open your-NAS-IP:8089 and log in with admin / SparkBoxTemp2026, and change it in Settings → Web UI once you're in.
jackhammer57 wrote:
ok I got qbit open. tried using just the webUI\password line came back unauthorized. when I opened the config file again the string had quotes around it. removed tried again and again same thing. so I added the WebUI\HostHeaderValidation=false and reran. that got it to work
tomspark wrote:
That's the one — nicely done getting in. Good eye, too: qBit re-adding the quotes to the password line on restart is its own annoying quirk, and pairing it with HostHeaderValidation=false is exactly the combo that sticks on the NAS. You're sorted. Two quick things: now that you're in, set your own password in Settings, Web UI (the one I posted is public here). And heads-up — we just shipped v1.6.139, which bakes this into fresh installs, so after your next sudo sparkbox update you won't have to hand-edit any of it again. Thanks for the patience and the genuinely great debugging on this one.