[BUG] Web UI uploads larger than tus.chunkSize freeze after the first chunk; same tus flow via curl succeeds #5987

Checklist

• This is a bug report, not a question.
• I have searched on the issue tracker for my bug.
• I am running the latest FileBrowser version or have an issue updating.

Version

2.63.14

Description

Uploading any file larger than tus.chunkSize through the web UI freezes after exactly the first chunk. The progress bar stops at (chunkSize / total) and never advances, and a partial file of exactly chunkSize bytes is left in the destination. Nothing is logged server side.

Environment: official darwin-arm64 release binary on macOS 26.5 (Apple Silicon), run as a launchd agent. Plain HTTP on a LAN, no reverse proxy, no TLS, auth.method=noauth. Client: Safari on macOS 26.x (other browsers not tested here).

With the default 10 MiB chunk size and a 76 MB file, the progress bar freezes at 13.8% (10.49 MB / 75.97 MB) every time. 100% reproducible: fresh upload sessions, different files, after deleting the partial file, and after server restarts all behave the same.

What did you expect to happen?

The upload completes.

What actually happened?

The first chunk uploads at full speed, then the transfer never progresses. The destination directory holds a partial file of exactly 10485760 bytes (precisely one chunk). No errors in server output.

Server-side triage (backend appears fine)

Driving the same tus flow with curl against the same running server succeeds in every variant I tried:

• POST /api/tus/<file>?override=true (create) followed by sequential PATCH chunks, new connection per request: every chunk returns 204, file completes
• Same chunk sequence over a single reused keep-alive connection (curl --next): 204 / 204 / 204, file completes
• 8 x 10 MiB chunks for a 76 MiB file: completes, sha256 identical to the source
• A single 2 GiB chunk (with tus.chunkSize raised): completes in ~31s, sha256 identical to the source

So the server handles multi-chunk and single-chunk tus correctly, including connection reuse. The failure is isolated to the web frontend's chunk loop: from the browser, chunk 1 always succeeds and chunk 2 never completes.

Workaround

Set tus.chunkSize larger than any file you expect to upload, e.g.:

filebrowser config set --tus.chunkSize 17179869184

Single-chunk uploads from the same browser then succeed reliably (verified byte-identical via sha256, and a dmg passes hdiutil verify).

Reproduction Steps

1. filebrowser config init with defaults (10 MiB tus chunk), --auth.method=noauth, plain HTTP
2. Open the UI in Safari on macOS and upload any file larger than 10 MiB
3. Progress freezes at the first-chunk percentage; the destination holds an exactly-10485760-byte partial file

Additional context

Possibly related: #3549 (closed; similar symptom reported on 2.31.x in Docker) and #5664 (corruption with chunked uploads). If the maintainers can point me at the frontend chunk loop, I am happy to test patches against this setup.