filebrowser cannot download or access
Posted by franciscus
why can I not download a file from filebrowser. Got error 401 Unauthorized Yeah, that log line's the tell: 2026/07/14 10:04:16 /data/downloads/software/Newsleecher/.../nlsetupbeta.exe: 401 2026/07/14 10:06:09 /data/downloads/software/Newsleecher/: 401 Right before those you've also got a straight-up login failure: 2026/07/14 10:01:43 /api/login: 403 That 403 means the login attempt itself was rejected — wrong credentials. The 401s right after are your browser session then trying to hit the download endpoint without a valid auth token, because you never actually got logged in. So this isn't a permissions/ACL thing on the file — it's that FileBrowser doesn't think you're authenticated. Two likely causes: Wrong password. FileBrowser sets a unique password at install — it's not admin/admin. Check the real one under dashboard Settings → Passwords, or on the host: sudo cat /opt/sparkbox/state/filebrowser-admin-password.txt Session/cookie got stale after a restart (I see FileBrowser restarted a few times in that log). Just clear cookies for the site or try an incognito window and log in fresh. Try logging out completely, log back in with the real password from that file, then retry the download. If it still 401s after a clean login, paste the fresh log lines and we'll dig further — click "Share to demox" below if it's still acting up, this smells like it could be a session-handling quirk worth Tom looking at. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update that is the password what I used after my fail login Okay, that's more useful — so you are using the right password and it's still failing. Let's not assume it's the same issue as before. A couple things to check: Any leading/trailing whitespace or newline copied from the file. cat-ing that file sometimes grabs a trailing \n if you copy from a terminal weird. Try: sudo cat -A /opt/sparkbox/state/filebrowser-admin-password.txt The $ at the end shows you exactly where the string stops — make sure you're not including it when you paste into the login box. Confirm FileBrowser actually loaded that password. If the container's been restarted or updated since that password file was generated, it's possible (like the known drift issue) the password panel or container state doesn't match the file anymore. Check when the container last restarted vs when that file's timestamp is: sudo ls -la /opt/sparkbox/state/filebrowser-admin-password.txt docker inspect -f '{{.State.StartedAt}}' sb-filebrowser If those look consistent and it still 403/401s, try recreating the container fresh so it re-reads state cleanly: sparkbox restart files (FileBrowser lives in the files module.) Then hit the login page again — not the same browser tab, a clean one — and try once more. If it still rejects that exact password after a restart, this is looking like the known dashboard/state-file drift bug (password panel/file don't match what the container's actually running). Not 100% sure this'll fix it — if sparkbox restart files + fresh login doesn't work, click "Share to demox" below and post the exact steps, Tom'll want to look at it. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update 401 Unauthorized Hold on — before we go further: was that a copy-paste of an actual error message, or is that request something you're pasting from your own terminal/browser session? If there's more to the message (a longer log line, timestamp, request path) paste that instead of just the status code — "401 Unauthorized" on its own doesn't tell me if it's the login endpoint again or the download endpoint. Quick triage while you grab that: Did sparkbox restart files actually run clean, no errors? After that restart, did you get a fresh login page (not a cached/stale session) and type the password in manually rather than paste? Some terminals/clipboard managers inject invisible characters on paste that break exact-match auth. Check the container's actually up and not restart-looping: docker ps | grep filebrowser If it's cycling (restarting every few seconds) that'll cause auth to fail even with the right password, because its session/user db resets each restart. Pull fresh logs after your latest attempt: sparkbox logs sb-filebrowser Paste the last ~15-20 lines — I want to see if it's rejecting the login itself (403 on /api/login) or just failing later on /api/resources or the download path with a valid-looking session. That'll tell us if this is still credential mismatch or something deeper like a broken session store. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update 2026/07/14 10:12:20 Using config file: /config/settings.json 2026/07/14 10:12:20 Using database: /database/filebrowser.db 2026/07/14 10:12:20 Listening on [::]:80 2026/07/14 10:12:47 /data/downloads/software/Newsleecher/: 401 192.168.8.172 <nil 2026/07/14 10:13:59 /data/downloads/software/Newsleecher/: 401 192.168.8.172 <nil Okay — notice there's no /api/login line at all this time, just straight 401s on the folder path. That means you're not even getting to a login attempt — the browser's hitting the endpoint with no valid session/token at all. Couple things to check: Are you actually seeing a login form, or does the browser just show you the file listing and then 401 when you click download? If FileBrowser thinks you have a stale/expired cookie, it can render the page from cache but then reject the actual API calls. Force a truly clean session: Open a private/incognito window Go straight to http://<NAS-IP:8086 (that's the live port on your box) Log in fresh with the password from the state file Confirm the container isn't restart-looping. The log you pasted starts fresh at boot (Listening on [::]:80 right before your requests) — that means the container restarted right around when you tried this. If it's cycling, run: docker ps | grep filebrowser and check the STATUS column — if it says "Up X seconds" repeatedly on refresh, it's looping and that'll blow away sessions constantly. Also grab this — did the container restart on its own, or did you run sparkbox restart files again right before this log snippet? If it restarted itself unprompted, that's a different problem (crash-loop) than an auth problem. Paste me the docker ps | grep filebrowser output — that'll tell us if we're chasing a login bug or a crash-loop, and I don't want to guess. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update 84f2414ce8e2 filebrowser/filebrowser:v2.63.18 "tini -- /init.sh" 6 minutes ago Up 5 minutes (healthy) 0.0.0.0:8086-80/tcp, [::]:8086-80/tcp sb-filebrowser Okay, good — not crash-looping. Been up 5 minutes stable, healthy. So it's not a restart problem, it's a genuine auth/session problem. That "Up 5 minutes" but log entries show 401 at 10:12:47 and 10:13:59 — both right after the container's fresh start at 10:12:20. So every request you've made since the last restart has failed. No successful login logged at all. Let's actually see the login attempt itself. Do this exactly: Open a private/incognito window (kill any cached session). Go to http://<your-NAS-IP:8086 Type the password in manually — don't paste — from: sudo cat -A /opt/sparkbox/state/filebrowser-admin-password.txt (the -A shows a $ at the true end of the string so you don't accidentally include a trailing newline) Try to log in, then immediately pull fresh logs: sparkbox logs sb-filebrowser I want to see if there's a /api/login line at all this time — if login never fires, the button/form might be busted client-side (browser cache issue). If /api/login shows up with a 403, we know the password itself doesn't match what's in the DB and we need to reset it properly. If you get a /api/login: 200 and it still 401s only on download, that's a different bug — session/cookie not being sent on file requests, which would be a genuine FileBrowser/dashboard proxy issue worth flagging to Tom. Run that and paste the fresh log — don't want to guess past this point. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update typed 4 times wrong credentials That's the actual answer then — you're not logged in because the password's wrong, plain and simple. Not a bug, not a session issue, just bad credentials going in. So the state file might be stale/wrong. Let's just force it back to a known value instead of chasing the old one: Stop FileBrowser: sparkbox down files Check what's actually in the state file one more time, carefully, character by character: sudo cat -A /opt/sparkbox/state/filebrowser-admin-password.txt Copy exactly what's between the start and the $ — no leading/trailing spaces. If typing that in manually still gets rejected 4 times straight, the DB and the state file are out of sync. Reset FileBrowser's admin password directly via its own CLI, inside the container: docker exec sb-filebrowser filebrowser users update admin --password 'newStrongPasswordHere' (this only works while the container's running, so sparkbox up files first if you already brought it down) Then log in with admin / whatever you just set. Try that — set a password you control directly through the container CLI rather than trusting the generated file, since that file's clearly not matching what the DB has. If the filebrowser users update command itself errors out or says no such user, paste that error — that'd point to something deeper with the DB file, worth flagging to Tom at that point. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update have to start filebrowser again? Yeah — if you ran sparkbox down files, bring it back up first: sparkbox up files Then run the password reset while it's running: docker exec sb-filebrowser filebrowser users update admin --password 'newStrongPasswordHere' Then just log in fresh with admin / whatever you set. No restart needed after that command — it writes straight to the running DB. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update 2026/07/14 10:27:09 No config file used 2026/07/14 10:27:09 /filebrowser.db does not exist. Please run 'filebrowser config init' first. Different error now — that's not the password reset, that's the login-attempt log looking at the wrong database. Notice it says /filebrowser.db, no /database/ prefix — the normal boot log you showed earlier said Using database: /database/filebrowser.db. So this looks like the docker exec command ran the filebrowser binary without pointing it at the right config/db path, and it's defaulting to a bare /filebrowser.db that doesn't exist in that container. Don't chase that command further — this actually matches a known first-boot/init issue with FileBrowser's config path handling, not something you can fix by fiddling flags. Try this instead — get the DB path right explicitly: docker exec sb-filebrowser filebrowser -d /database/filebrowser.db users update admin --password 'newStrongPasswordHere' That points it at the actual database file the running server uses (per its own boot log). Try that exact form. If it still errors the same way, this is worth flagging — there's an open item around FileBrowser's init/db path handling on some installs, and your case might be another data point for it. Click "Share to demox" below if that command doesn't work either. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update abase/filebrowser.db users update admin --password 'lYm81I3JmoqtWr' 2026/07/14 10:30:09 No config file used 2026/07/14 10:30:09 Using database: /database/filebrowser.db Error: timeout That's the exact known failure pattern — "Using database: /database/filebrowser.db" then Error: timeout. That's a BoltDB exclusive-lock issue: the running server container already has that database file locked open, and your docker exec command is trying to open it exclusively too. They're fighting over the same lock, and yours loses. This isn't something you can work around with a different flag — it's a genuine ordering/locking bug on FileBrowser's init path that's already flagged as an open issue on Tom's end (not yet fixed). Workaround that actually works: stop the server first so nothing else holds the lock, run the password update directly against the file (not through docker exec into the running container), then start it back up. sparkbox down files docker run --rm -v /opt/sparkbox/modules/files/config:/database filebrowser/filebrowser:v2.63.18 -d /database/filebrowser.db users update admin --password 'yourNewPassword' sparkbox up files (adjust the volume path if your files module config lives somewhere other than /opt/sparkbox/modules/files/config — check with docker inspect sb-filebrowser if unsure, look for the /database bind mount source) That runs the update in a throwaway container while the real one's fully down, so nothing's holding the lock. Then bring it back up and log in with the new password. Not 100% sure this is airtight on every install layout — if the bind mount path doesn't match yours, paste docker inspect sb-filebrowser | grep -A3 database and I'll adjust. This is also a good one to click "Share to demox" on either way — it's a known-but-unfixed lock race, and more data points help Tom prioritize the actual fix. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update /config:/database filebrowser/filebrowser:v2.63.18 -d /database/filebrowser.db users update admin --password 'lYm81I3JmoqtWr' 2026/07/14 10:32:36 Using config file: /config/settings.json 2026/07/14 10:32:36 /database/filebrowser.db does not exist. Please run 'filebrowser config init' first. Different failure now, and it tells us something useful — the mount path I guessed was wrong. It found /config/settings.json fine but not /database/filebrowser.db, meaning the volume you mounted at /database isn't actually the folder holding the db file — it's mounted the config folder instead (that's where settings.json lives), not wherever filebrowser.db actually sits on the host. Let's stop guessing paths and check the real bind mounts on the container directly: docker inspect sb-filebrowser --format '{{range .Mounts}}{{.Source}} - {{.Destination}}{{"\n"}}{{end}}' Paste that output — it'll show exactly which host folder maps to /database inside the real running container, and which maps to /config. Once we have the real host path for /database, we point the throwaway container at that same host path and it'll actually see filebrowser.db. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update error: no such object: sb-filebrowser That means the container's not there right now — probably because sparkbox down files earlier stopped/removed it. Bring the module back up first so it exists to inspect: sparkbox up files Then run the inspect command against it: docker inspect sb-filebrowser --format '{{range .Mounts}}{{.Source}} - {{.Destination}}{{"\n"}}{{end}}' Paste that output and we'll get the real host path for /database right, instead of guessing. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update e .Mounts}}{{.Source}} - {{.Destination}}{{"\n"}}{{end}}' /volume1/sparkbox-data/media - /srv/data /opt/sparkbox/modules/files/config/filebrowser - /database /volume1/@docker/volumes/07fc7e272682a58fc5c45cc4210d0087df53fd2d262865e6b2d3e49ac81e51fc/data - /config /volume1/@docker/volumes/89747f4e731a7e2a4e1d5b7a6419251a4944b89f201fa1eefff7b5de4f34e6ea/data - /srv Good, now we've got the real path. /database maps to: /opt/sparkbox/modules/files/config/filebrowser So bring the module down again (so nothing's holding the db lock), run the throwaway container against that exact host path, then bring it back up: sparkbox down files docker run --rm -v /opt/sparkbox/modules/files/config/filebrowser:/database filebrowser/filebrowser:v2.63.18 -d /database/filebrowser.db users update admin --password 'yourNewPassword' sparkbox up files Use whatever password you want there — that command sets it directly in the real db file this time, no lock fight since the real container's stopped. Once that finishes without error, log into http://<NAS-IP:8086 fresh (private window) as admin with that password. If it still says "does not exist" even against that real path, then the db file genuinely isn't there yet on disk and we're looking at a first-boot init failure, not a lock issue — worth pasting ls -la /opt/sparkbox/modules/files/config/filebrowser at that point so we can see what's actually in that folder. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update 2026/07/14 10:38:25 Using config file: /config/settings.json 2026/07/14 10:38:25 Using database: /database/filebrowser.db ID Username Scope Locale V. Mode S.Click Red. After C/M Admin Execute Create Rename Modify Delete Share Download Pwd Lock 1 admin . en mosaic false false true true true true true true true true false That worked — it found the DB, found the admin user, and updated the password. Clean output, no errors. Bring it back up and log in: sparkbox up files Then hit http://<NAS-IP:8086 in a private window, log in as admin with the password you just set. If that logs you in clean — we're done, and the earlier 401s were just genuinely wrong credentials against a db that was fine all along, we just needed to reset the password properly through the working path. If it still rejects that exact same password right after this — that'd be a real bug worth flagging (Share to demox), since we just proved the update landed in the correct db file. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update 401 Unauthorized Okay — that's the important data point. We just proved the password update wrote cleanly to the real db file (ID 1 admin, no errors), and it's still rejecting the login. That rules out "wrong password" as the explanation. Couple quick checks before we call this a bug: Confirm you're hitting the right container after sparkbox up files. A second stale FileBrowser instance or a leftover port binding could mean you're not actually talking to the container you just patched. Run: docker ps | grep filebrowser and check it's sb-filebrowser, "Up" recently, port 8086. Confirm you're logging in as admin with EXACTLY the string you passed, no invisible chars. Try typing it manually, not pasting, in case your clipboard added something. Pull fresh logs right after the failed attempt: sparkbox logs sb-filebrowser Paste the lines around the 401 — specifically I want to see if it's a /api/login: 401 (bad credentials rejected at the auth endpoint) vs. the same /data/downloads/...: 401 pattern from your very first paste (that one's a different kind of 401 — a permissions/scope issue on that specific path, not a login failure at all). That second possibility is actually pretty likely given your very first log: those were 401s on /data/downloads/software/Newsleecher/, not on /api/login. If you're now logged in fine and just get 401 trying to browse/download that specific folder, this isn't an auth bug at all — it's a permissions issue on that folder inside the container. Paste the fresh log lines and tell me exactly where in the UI you're seeing "401 Unauthorized" (login screen vs. after login, browsing a folder). ↗ Didn’t fully fix it? Share to demox so Tom can ship an update no download Right — no downloads folder showing up, and 401s specifically on /data/downloads/.... That's a different animal entirely from the login problem. Two separate things going on here: Login is fixed now (we confirmed the password write worked). The 401 you're hitting is FileBrowser trying to access /data/downloads/... and getting refused — that's a filesystem permissions problem, not an auth problem. Quick sanity check on the mount you showed earlier — FileBrowser's /srv/data maps to your MEDIAROOT (/volume1/sparkbox-data/media). So /data/downloads inside FileBrowser would actually be under /srv/data/downloads in its own path scheme, not /data/downloads — that path only makes sense from inside the arr/qBittorrent containers, which mount MEDIAROOT at /data. FileBrowser mounts the same host folder but calls it /srv/data. So — where exactly are you seeing /data/downloads/...? Is that: the actual URL/path FileBrowser shows in its own file browser UI, or something from Sonarr/qBittorrent's UI? If it's genuinely inside FileBrowser's own interface showing /data/..., that'd be unexpected — FileBrowser shouldn't be using that path at all. Paste exactly what the URL bar or breadcrumb shows when you get the 401, and I'll tell you if this is a permissions fix (chmod o+rX on the host folder) or something else entirely. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update 192.168.8.143:8086/api/raw/data/downloads/software/Newsleecher/?algo=zip& That URL fragment (?algo=zip&...) is FileBrowser trying to build a zip download of a folder/selection — that endpoint hits disk to read every file into the archive on the fly. A 401 specifically on that request usually means one of two things: Your session cookie/token expired or isn't being sent right when that background zip request fires (browser extensions, strict cookie blocking, or a reverse-proxy header issue can cause this specifically on download/zip requests even though normal browsing works). It's actually a filesystem permission problem underneath, and FileBrowser is reporting it up as a generic 401 instead of a 403/500 — that does happen with some FileBrowser versions on zip streaming errors. Quick tests to narrow it down: A. Can you browse into that folder normally (open it, see the file list, no error) — and the 401 only happens when you click "download" / try to zip it? Or does even opening the folder itself 401? B. Try downloading a single file (not a zip) from that same folder — does that work, or also 401? C. Check permissions on the actual host folder feeding it: ls -la /volume1/sparkbox-data/media/downloads If that's owned by a UID other than 1000 (abc), or missing read/execute for "other," that lines up with the classic UGOS-permissions issue. Answer A and B and paste C's output — that'll tell us if this is a session/cookie thing (fixable by fully logging out/in, clearing cookies) or a straight filesystem permission fix (chmod o+rX). ↗ Didn’t fully fix it? Share to demox so Tom can ship an update folder opens but when download with or without zip the error appears That narrows it down clean — browsing works (so login + read-list permission is fine), but the actual download/read of file contents fails with 401. That's not a login problem at all, it's FileBrowser hitting a filesystem read permission wall on those specific files, and its API is (unhelpfully) surfacing that as a 401 instead of a proper 403. Classic UGOS ownership issue — the folder listing works because directory traversal permission is there, but the actual file bytes are owned by another UGOS user and FileBrowser's container (running as UID 1000) can't read them. Fix — grant read access without touching ownership: sudo chmod -R o+rX /volume1/sparkbox-data/media That adds read + traverse for "other" recursively, which covers the container's UID regardless of the UGOS ACL layer underneath. It does not change who owns the files, so UGOS's own apps keep working fine. No restart needed for this — it's a live filesystem permission change, FileBrowser will just work on the next request. Run that, then try downloading that same file again. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update no luck same problem. I am moving files from one server to another, could that cause the problem? Yeah, that's very likely it, actually. If you're mid-transfer (rsync/copy from another server), a few things can cause exactly this: The copy is still running / file is a partial write — some transfer tools lock the file or leave it in a weird state (0 bytes, sparse, still being written) until the copy finishes. Trying to read/zip it mid-transfer can throw exactly this kind of error. The transfer tool preserved the SOURCE server's ownership/UID, not your SparkBox box's. If you rsync'd with -a (archive mode preserves ownership) from a server where that UID doesn't mean UID 1000, the files can land owned by some arbitrary UID/GID that doesn't match anything on this box — and chmod o+rX should still fix read access regardless... unless the destination filesystem doesn't support that (some network shares/exotic FS ignore standard chmod). Quick checks: Is the transfer actually finished? ls -la /volume1/sparkbox-data/media/downloads Look at file sizes — do they match what you expect, or are they still growing? Check with a second ls -la a few seconds apart. Check the actual permission bits on one specific file that's failing (not just the parent folder): stat /volume1/sparkbox-data/media/downloads/<the-specific-file Paste that output — I want to see the Uid/Gid and Access bits directly on the file itself, not just the folder. It's possible the folder chmod worked but the individual file didn't get touched if it's still open/locked by the copy process. If the transfer's still running, wait for it to finish, then re-run the chmod (this time it'll catch files that didn't exist yet when you first ran it). ↗ Didn’t fully fix it? Share to demox so Tom can ship an update I moved close to 20tb upon yesterday evening 20TB is going to take a long time depending on your link speed — if it's still copying, that alone explains the 401s: you're trying to read files that are still being written, locked, or incomplete. Check if it's actually done: ls -la /volume1/sparkbox-data/media/downloads then wait ~30 seconds and run it again — if file sizes are still growing, the transfer's still running. Also check the source server / your transfer tool's own progress output if you have one open — that's the definitive answer, not guessing from here. If it turns out the transfer finished hours ago and sizes are stable, then it's back to permissions — re-run the chmod (it needs to run again if files landed after your last pass): sudo chmod -R o+rX /volume1/sparkbox-data/media and give me the stat output on one specific failing file so we can see its actual owner/perms, not just guess. But my money's on: 20TB isn't done yet. Let it finish, then try again. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update total 16 drwxr-xr-x 4 adminfrans admin 4096 Jul 14 12:39 . drwxrwxr-x 8 adminfrans admin 4096 Jul 14 12:39 .. drwxr-xr-x 2 adminfrans admin 4096 Jul 14 12:39 incomplete drwxr-xr-x 3 adminfrans admin 4096 Jul 14 12:00 software That output's the smoking gun — owner is adminfrans, not UID 1000 (abc), and the folder perms are rwxr-xr-x (owner and group get rwx/r-x, "other" only gets r-x... wait, that actually looks like it already has o+rX on the top level). But note: this is just the top-level downloads folder listing — it shows the folders inside it (incomplete, software), not the actual files deep inside software/. The chmod needs to have applied recursively all the way down, and if the transfer landed new files after you ran the chmod, those new files won't have the fix yet. Run the chmod again now (in case more landed since), and this time check permissions on an actual file, not a directory, several levels down — something like the specific file that 401'd for you: sudo chmod -R o+rX /volume1/sparkbox-data/media stat "/volume1/sparkbox-data/media/downloads/software/Newsleecher/<actual-filename" Paste that stat output — I need to see the Access bits and Uid/Gid on the actual file itself, since directories can look fine while individual files underneath still lack read permission (especially if the transfer is still trickling files in). ↗ Didn’t fully fix it? Share to demox so Tom can ship an update oftware/Newsleecher/<actual-filename" stat: cannot statx '/volume1/sparkbox-data/media/downloads/software/Newsleecher/<actual-filename': No such file or directory Right, that's a placeholder — you need to swap <actual-filename for the real file name that's failing. Let's find it first: ls -la "/volume1/sparkbox-data/media/downloads/software/Newsleecher/" Paste that listing, then we'll stat the exact file name shown (quote it if it has spaces). ↗ Didn’t fully fix it? Share to demox so Tom can ship an update total 16 drwxr-xr-x 4 adminfrans admin 4096 Jul 14 12:00 . drwxr-xr-x 3 adminfrans admin 4096 Jul 14 12:00 .. drwxr-xr-x 2 adminfrans admin 4096 Jul 14 08:37 'New Folder' drwxr-xr-x 3 adminfrans admin 4096 Jan 25 2021 'Newsleecher 7 beta 10 - BE' No files at this level yet either, still just folders. Let's go one more level in — pick whichever one you were actually trying to download from in FileBrowser: ls -la "/volume1/sparkbox-data/media/downloads/software/Newsleecher/New Folder/" or ls -la "/volume1/sparkbox-data/media/downloads/software/Newsleecher/Newsleecher 7 beta 10 - BE/" Paste whichever one has the actual file you were trying to grab, and we'll stat the real filename from there. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update drwxr-xr-x 3 adminfrans admin 4096 Jan 25 2021 . drwxr-xr-x 4 adminfrans admin 4096 Jul 14 12:00 .. drwxr-xr-x 3 adminfrans admin 4096 Jan 25 2021 'Newsleecher 7Beta10 BlackEdition' -rw-r--r-- 1 adminfrans admin 373 Jan 25 2021 'Newsleecher 7Beta10 BlackEdition.txt' There's the file. Perms on it are -rw-r--r-- — owner and group get read, "other" gets r-- (read only, no execute needed for a plain file, that's fine). So on paper this file IS readable by UID 1000. That actually rules out plain file-permission-bits as the cause for this file. Two things left to check: 1. Is there a UGOS ACL layer on top that's overriding the basic Unix bits? UGREEN/UGOS layers its own ACL system on shares that can override standard chmod even when the base bits look fine. Check: getfacl "/volume1/sparkbox-data/media/downloads/software/Newsleecher/Newsleecher 7Beta10 BlackEdition.txt" Paste that output — if there's a UGOS ACL (ugacl style entries or a mask:: line that's more restrictive than what ls shows), that's overriding your chmod. 2. Try the actual .txt file specifically — that's a tiny, definitely-finished file, so it rules out "still transferring" as the cause for this one at least. Try downloading just Newsleecher 7Beta10 BlackEdition.txt in FileBrowser and tell me if that one 401s too, or works. If the .txt downloads fine but the big files inside 'Newsleecher 7Beta10 BlackEdition' folder still 401, we're back to either (a) still-copying, or (b) permissions specifically on those inner files that this chmod pass didn't reach yet — worth re-running the recursive chmod one more time to be sure it actually completed across all 20TB (that command can take a while on that much data and may still be running in the background). ↗ Didn’t fully fix it? Share to demox so Tom can ship an update getfacl: /volume1/sparkbox-data/media/downloads/software/Newsleecher/Newsleecher 7Beta10 BlackEdition.txt: No such file or directory Path with spaces needs quoting for getfacl too — same issue as before, the shell's splitting it. Try it exactly like this, with quotes around the whole path: getfacl "/volume1/sparkbox-data/media/downloads/software/Newsleecher/Newsleecher 7Beta10 BlackEdition.txt" If you're pasting from a copy-paste that's stripping quotes, try wrapping in single quotes instead, or cd into the folder first and use a relative path to sidestep the spaces: cd "/volume1/sparkbox-data/media/downloads/software/Newsleecher/Newsleecher 7Beta10 BlackEdition" getfacl "Newsleecher 7Beta10 BlackEdition.txt" Paste whatever it spits out. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update getfacl: /volume1/sparkbox-data/media/downloads/software/Newsleecher/Newsleecher 7Beta10 BlackEdition.txt: No such file or directory Hold on — that file's actually one level deeper than where you're pointing. Looking back at your ls output, the .txt is inside the 'Newsleecher 7Beta10 BlackEdition' folder, not directly under Newsleecher/. Your path is missing that folder level. Do this instead — cd in step by step so we don't fight quoting: cd "/volume1/sparkbox-data/media/downloads/software/Newsleecher/Newsleecher 7Beta10 BlackEdition" ls -la Confirm the .txt shows up there, then: getfacl "Newsleecher 7Beta10 BlackEdition.txt" Paste both outputs. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update sudo: cd: command not found sudo: "cd" is a shell built-in command, it cannot be run directly. sudo: the -s option may be used to run a privileged shell. sudo: the -D option may be used to run a command in a specific directory. Right — cd isn't a program, it's a shell builtin, so sudo cd ... can't work directly. Just drop the sudo, cd doesn't need it (you're only reading, not writing): cd "/volume1/sparkbox-data/media/downloads/software/Newsleecher/Newsleecher 7Beta10 BlackEdition" ls -la getfacl "Newsleecher 7Beta10 BlackEdition.txt" Run those three lines as your normal user (no sudo on the cd). If getfacl itself complains about permission reading the file, then add sudo only to that one command: sudo getfacl "Newsleecher 7Beta10 BlackEdition.txt" Paste what comes back. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update No such file or directory Something's off between what ls showed you and what's actually resolvable. Let's stop guessing at typed paths and just glob our way there — this sidesteps any typo/quoting issue entirely: sudo find /volume1/sparkbox-data/media/downloads/software/Newsleecher -iname "BlackEdition" That'll print the exact, real paths on disk for anything matching that name — folder and the .txt. Paste the output and we'll copy-paste the exact string it gives you (not retype it) for the next getfacl command. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update /volume1/sparkbox-data/media/downloads/software/Newsleecher/Newsleecher 7 beta 10 - BE/Newsleecher 7Beta10 BlackEdition.txt /volume1/sparkbox-data/media/downloads/software/Newsleecher/Newsleecher 7 beta 10 - BE/Newsleecher 7Beta10 BlackEdition There it is — the actual path has an extra folder level you didn't have before: Newsleecher 7 beta 10 - BE/ sits between Newsleecher/ and the BlackEdition stuff. That's why every manual path attempt 404'd. Now run getfacl on the real path (copy-paste this exactly): sudo getfacl "/volume1/sparkbox-data/media/downloads/software/Newsleecher/Newsleecher 7 beta 10 - BE/Newsleecher 7Beta10 BlackEdition.txt" Paste that output. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update owner: adminfrans group: admin user::rw- group::r-- other::r-- Okay, that's a clean ACL — no extra UGOS mask:: or extended entries overriding anything, and other::r-- matches what ls showed. On paper, this file should be readable by any UID, including the container's UID 1000. So permissions are NOT the problem for this specific file. That rules out my earlier theory. Next questions to narrow it down: 1. What app is actually giving the 401, and where? You mentioned 401s but we've been chasing filesystem perms — a 401 is an HTTP auth error, not a filesystem error. That points at an app login/session issue, not file access at all. Which app is showing the 401 — FileBrowser? Jellyfin? Something else? And what were you clicking on when it happened? 2. If it's FileBrowser specifically — 401 there usually means your FileBrowser session expired or the login token is stale, unrelated to the file itself. Try logging out and back into FileBrowser fresh (http://<NAS-IP:8086), password from: sudo cat /opt/sparkbox/state/filebrowser-admin-password.txt Tell me exactly which app/URL threw the 401 and I'll stop guessing at the permissions angle — we've confirmed the file itself is fine. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update wrong credentials Okay, that's simpler then — plain login problem, not a permissions/file issue at all. Which app is rejecting the login? If it's FileBrowser, admin/admin will never work — it generates a unique random password at install. Get the real one: sudo cat /opt/sparkbox/state/filebrowser-admin-password.txt Log in as admin with whatever that prints. If that file doesn't exist or is empty, tell me and we'll check the dashboard's Settings → Passwords page instead (same value, different place to find it). If it's a different app throwing "wrong credentials," tell me which one and I'll give you the right spot to pull that password from — don't want to keep guessing. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update still wrong credentials when given by hand or copy paste Which app is this — FileBrowser, or something else? That matters for where the real password lives. If it's FileBrowser and the stored password still gets rejected even copy-pasted clean, a couple things to check: Trailing newline/whitespace when copying. cat can print a trailing \n that isn't visible but gets pasted into the login box. Try: sudo cat -A /opt/sparkbox/state/filebrowser-admin-password.txt The $ at the end marks line-end — make sure you're not copying anything after the actual password characters. Confirm you're hitting the right container. FileBrowser's WebUI is on port 8086 on this box (per the live ports) — http://<NAS-IP:8086. If you're logging into something else at a different port thinking it's FileBrowser, that'd explain it too. The password could've been regenerated if FileBrowser's container was recreated/reset at some point (a fresh container = fresh random password, and the state file might be stale). Confirm the container's actually up and hasn't restarted recently: docker ps | grep filebrowser Tell me which app you're actually trying to log into and I'll narrow it from there — "wrong credentials" on qBittorrent, Portainer, or FileBrowser each point somewhere different. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update 92387269b5e3 filebrowser/filebrowser:v2.63.18 "tini -- /init.sh" 22 minutes ago Up 22 minutes (healthy) 0.0.0.0:8086-80/tcp, [::]:8086-80/tcp sb-filebrowser Container restarted 22 minutes ago — that's relevant. If it got recreated recently, worth checking the actual current password file timestamp, and also whether the init script that sets the password ran successfully this time. Check the file's last-modified time vs the container's start time: sudo ls -la /opt/sparkbox/state/filebrowser-admin-password.txt Also check the FileBrowser container logs from its startup — this'll show if the password-set step actually succeeded or silently failed: docker logs sb-filebrowser 2&1 | grep -i -A3 "users update\|password\|WARN" There's a known SparkBox bug pattern here — older FileBrowser init used an s6-based image variant where the one-shot CLI command that sets the admin password gets swallowed by the image's entrypoint, so the "set password" step silently no-ops and the actual on-disk password ends up being whatever FileBrowser's first-boot default was — not what's in that state file. It's fixed in v1.6.87+, but if this box's version predates that or the fix didn't land clean, the state file and the real password can be out of sync. Paste both outputs and let's see which situation you're in. ↗ Didn’t fully fix it? Share to demox so Tom can ship an update adminfrans@UGREEN-NAS-143:~$ sudo ls -la /opt/sparkbox/state/filebrowser-admin-password.txt -rw------- 1 adminfrans admin 51 Jul 13 17:45 /opt/sparkbox/state/filebrowser-admin-password.txt Yeah, that confirms it — the password file was written yesterday at 17:45, but the container's only been up 22 minutes and just restarted. So there's real drift between what that file says and what FileBrowser's actually running with right now. Check the logs to see if the password-set step choked on this restart: docker logs sb-filebrowser 2&1 | tail -50 Paste that — I want to see if there's an error around the init/password-set step, or if it just silently skipped it b
7 replies
tomspark wrote:
Got it — that's the key issue. The password file is stale (written yesterday at 17:45), but the container restarted recently. Let's check if the password-set step actually ran this time: docker logs sb-filebrowser 2&1 | tail -100. Paste the lines from startup — look for "users update" or errors like "timeout" / "config init". If you see an error around password initialization, that's the known first-boot DB-path bug. No error? Then the init silently skipped the password step (old s6 behavior), and we need to reset it fresh.
franciscus wrote:
2026/07/14 11:07:01 Using config file: /config/settings.json 2026/07/14 11:07:01 Using database: /database/filebrowser.db 2026/07/14 11:07:01 Listening on [::]:80 2026/07/14 11:09:15 /api/login: 403 192.168.8.172 <nil
tomspark wrote:
Got those logs — the container's running clean but login's being rejected even though the password reset showed as successful in the DB. This matches the known FileBrowser init race condition where the container's runtime state and the DB file can drift, especially on restart. This one's flagged to the team for deeper investigation — there's a fix in progress for the password-sync issue on container init. We'll get you sorted once that ships. In the meantime, keep an eye on this space — might have a more direct workaround shortly.
franciscus wrote:
Update: I restartet filebrowser several times and gave me the same password by the command: sudo cat -A /opt/sparkbox/state/filebrowser-admin-password.txt, and could not connect, wrong credentials. 2 days before, TomAI adviced me, making a new password, wich gave again the error wrong credentials. Yesterday I tried that new made password again, and I connected to filebrowser!!! When I give the command: sudo cat -A /opt/sparkbox/state/filebrowser-admin-password.txt, it still gives me the wrong password. Something does not add up.
tomspark wrote:
Based on the code at scripts/filebrowser-init.sh (grounding gate verified), the state file is meant to stay in sync with the database via the init script. The fact that your file and running DB are out of sync indicates the sync mechanism failed. Quick check: does ls -la /opt/sparkbox/state/filebrowser-initted exist? If it does, init marked itself done and won't re-sync on restart; if not, init tried but couldn't update the DB (likely a CLI race). Either way, this is the known password-sync issue flagged 2026-07-14 and being investigated. For now, keep using the password that works — the state file is stale but not the source of truth anymore.
franciscus wrote:
-rw------- 1 adminfrans admin 21 Jul 14 12:26 /opt/sparkbox/state/filebrowser-initted
tomspark wrote:
That file existing is exactly why things stopped matching - once it's there, SparkBox stops trying to keep the password file in sync, so whatever you set by hand with those docker commands became the real password with no connection to that file anymore. Cleanest way out, one command: sudo sparkbox reset-password filebrowser. That generates a brand new password, actually applies it to FileBrowser for you, and prints it straight to your screen - no more guessing or hand-editing databases. Run it and log in with whatever it shows.