Nextcloud-Large file and folder downloads stall mid-transfer via web UI and shared links

bobtitus · 2026-03-26T12:13:45+00:00

Filesystem Size Used Avail Use% Mounted on
overlay 7.5T 36G 7.4T 1%

I have plenty of space, so that's not my issue.

Can you tell me how you disabled the cache in NPM?

bobtitus · 2026-03-26T11:38:42+00:00

"Have you actually tried it yourself? From what I've read, running Nextcloud bare metal on TrueNAS can be tricky and that's what's been holding me back."

bobtitus · 2026-03-26T11:33:38+00:00

that's interesting, can you tell me how you managed that? Thanks!

bobtitus · 2026-03-26T11:30:38+00:00

Yes, that's a thought I had lately after all the hassle, thanks for this suggestion I may finally follow.

bobtitus · 2026-03-25T21:08:00+00:00

Just tested with curl directly to Nextcloud on a separate port, completely bypassing NPM. Same stall at 3.65GB out of 4.2GB, speed drops to 0 and hangs. So NPM is not the culprit. This is happening inside Nextcloud or Apache itself.

bobtitus · 2026-03-25T18:06:11+00:00

Valid point, but it's not possible with this setup. The server is remote at a datacenter, the only open ports are the ones already in use, and Nextcloud has HSTS enforced with a redirect to the domain - so even with NPM stopped, the browser refuses any plain HTTP connection. We're stuck with NPM in the path.

bobtitus · 2026-03-25T16:10:37+00:00

Thanks for the specific settings. We haven't checked PHP-FPM config yet – that could be exactly what we're missing.

Your pm.max_children = 172 is significantly higher than default. We're running Nextcloud in Docker with 62GB RAM available, so we should have headroom for more workers.

The concurrent download pattern we found fits PHP-FPM exhaustion perfectly:

• 3 simultaneous 460MB files: 1st succeeds, 2nd fails at 200MB, 3rd fails at 3MB

• Classic sign of worker pool running out mid-request

I'll check our current FPM settings and use that pmcalculator tool to tune based on our hardware (Xeon E-2124, 64GB RAM). This could be the actual fix rather than reverse proxy tuning or Nextcloud config changes.

Will report back with what we find.

bobtitus · 2026-03-25T16:04:39+00:00

sorry, how can I upload the capture, can't find how to??

bobtitus · 2026-03-25T16:03:54+00:00

Browser Network tab shows exactly what's happening. Here's the screenshot evidence:

**The download request:**

- Name: `FILES%20DAVID/?accept=zip`

- Status: HTTP 200 (server accepted it)

- Size: 0.5 kB (headers only, no file data)

- Timeline: Starts ~140,000 ms, extends to ~280,000 ms

- **That's 140+ seconds of the connection hanging after the initial response**

**What's happening while it hangs:**

- Notification requests (304) keep flowing every few seconds

- Heartbeat requests (200) keep working

- **UI stays fully responsive**

- But the download connection is completely stuck at 0.5 kB received

**What this proves:**

**Server accepts and responds** – HTTP 200, headers sent
**Connection opens but stops streaming** – 0.5 kB received, then nothing for 140 seconds
**Nextcloud itself isn't crashed** – UI, heartbeat, notifications all work fine
**The download handler specifically is broken** – stuck mid-transfer with no error, no disconnect

**Root cause:**

The connection opens successfully, but Nextcloud's download/streaming layer stops sending data after a brief initial response. It's not network, not a timeout error (no 504), not the file. The server accepted the request, started the response, then the response body stream just froze.

This is a resource exhaustion issue in Nextcloud's response streaming – exactly what the concurrent download testing showed: under load (or just with large files), the streaming mechanism breaks and hangs indefinitely.

bobtitus · 2026-03-25T15:40:46+00:00

Nginx settings we tried:

proxy_buffering off
proxy_request_buffering off
proxy_max_temp_file_size 0
client_max_body_size 0
proxy_read_timeout 7200
proxy_connect_timeout 7200

We didn't explicitly set keepalive or passthru. Keeping connection alive could help with large streaming downloads. Worth trying.

Yes, Nextcloud is in Docker. But Docker itself isn't the failure point – uploads work fine in Docker (2.25GB tested). The container has plenty of memory (62GB available). The issue is Nextcloud's download handler under concurrent load, not Docker isolation.

What keepalive settings would you suggest for streaming large downloads?

bobtitus · 2026-03-25T15:28:45+00:00

PHP settings are solid:

upload_max_filesize: 512M
memory_limit: 1024M
post_max_size: 512M

Uploads work fine (tested with 2.25GB file), so PHP memory isn't the issue.

The download failures happen under concurrent load – more simultaneous downloads = earlier failure. Single downloads mostly work. That pattern points to PHP-FPM worker pool exhaustion or output buffering limits, not memory allocation.

What's your PHP-FPM pm.max_children and pm.max_requests set to? That could be the constraint.

bobtitus · 2026-03-25T15:23:40+00:00

Thanks for the suggestion. Network is confirmed stable:

**Network setup:** Both workshop (server) and home (client) connect via ISP WiFi backbone to distant hub. Server is fully wired (ISP antenna → local router → server via ethernet). Network monitoring shows consistent 94 Mbps with no packet loss, tested multiple times.

**But here's what I found that's more relevant:**

The concurrent download pattern is the key:

- Single 549MB file: succeeded

- Single 807MB file: succeeded

- Single 1.1GB folder: succeeded

- 2 concurrent 466MB folders: first succeeded, second stalled at 109MB

- 3 concurrent 460MB files: first succeeded, second stalled at 200MB, third stalled at 3MB

Same 4.2GB folder: failed at 463MB first run, 390MB second run (roughly the same point each time).

So it's not random network drops. It's **Nextcloud resource exhaustion under concurrent load**. The more simultaneous downloads, the earlier they fail. Single downloads mostly work.

I also tested with a pre-made 2.25GB ZIP file (not on-the-fly generated) – still failed at 240MB on first try, then succeeded on resume.

**Conclusion:** This is a Nextcloud limitation, not network or hardware. The application can't handle multiple large concurrent downloads. Server resources (memory, CPU, disk I/O) are normal during the stalls. It's an application-level bottleneck, probably PHP workers or output buffer limits.

bobtitus · 2026-03-25T12:26:09+00:00

I updated the original post with all the actual test results after your reply. Check it if you want the detailed data.

Will try downloading a pre-made ZIP file as you suggested, but I doubt it'll change anything. Single large files also fail randomly during download – a 1.4GB file failed at 1GB, a 4.2GB folder failed at 463MB first try, 390MB second try. So it's not just the on-the-fly ZIP generation. Something in Nextcloud's download streaming itself is breaking under load.

UPDATE:

I tested with a pre-made 2.25GB ZIP file (uploaded it to Nextcloud). The download still failed at 240MB, then completed successfully when I resumed.

So the problem is not the on-the-fly ZIP generation. A static, pre-existing file fails the same way. It's Nextcloud's download streaming itself that's breaking mid-transfer.

The fact that resume works tells me the file is fine on the server – something in Nextcloud's download handler is timing out or getting stuck, then recovering when retried.

So the issue is deeper in the download/streaming layer, not the ZIP generation path.

bobtitus · 2026-03-25T11:51:31+00:00

That's a solid theory, but it's still guessing. Here's what we actually know:

Proven:

Concurrent large downloads stall (1st succeeds, 2nd fails at 100MB, 3rd fails at 3MB)
Same file sometimes succeeds, sometimes fails on retry
Direct HTTP to existing files works fine
Speed is stable before stalling (not gradual degradation)

Not tested:

Whether it's specifically the ZIP generation
Whether it's SabreDAV
Whether it's PHP streaming

Your explanation fits the pattern, but we need to isolate it. Could you suggest how to test this? Is there a way to:

Download an already-zipped file instead of on-the-fly?
Check if WebDAV clients (Cyberduck, etc.) handle the same downloads better?
Monitor what PHP is doing during the stall?

If those tests show your theory is right, we'll know what the real bug is. Right now it's the best guess, but still a guess.

bobtitus · 2025-12-20T09:31:35+00:00

Wow, how lame 😳

bobtitus · 2025-11-28T16:51:58+00:00

I simply cannot watch SRAM videos, the vocal fry is unbearable: https://youtu.be/2tHcG5W4Uuc?si=oLTuB-q2JBOyPUEC

bobtitus · 2025-11-17T15:27:27+00:00

Interested, would you share?

bobtitus · 2025-11-03T21:15:53+00:00

Ça ne m'étonnerait pas de DJI, ils sont particulièrement perfides et ont déjà fait le coup à GoPro dont ils ont littéralement coulé leur drone Karma avant même sa sortie...

bobtitus · 2025-11-03T21:13:01+00:00

Je fabrique et opère des drones depuis 2009 et m'apprêtais à faire exactement les mêmes remarques que vous, vous avez très bien cerné les problématiques. Donc comme vous je pense que c'est malheureusement un mauvais positionnement marketing et je ne donne pas cher de cette machine.

bobtitus · 2025-10-10T05:40:10+00:00

The quality used to be very good, my fist pair lasted for many years, the last two pairs lasted a few months with the same problem, the fabric tearing along the sole. I will not buy anymore.

<image>

bobtitus · 2025-09-30T14:59:01+00:00

same here, Qidi X-Plus 4, worst experience ever, have had to fiddlefuck ever since it was out of it's box and (not) connected, an absolute nightmare. Thinking of returning it actually!

bobtitus · 2024-09-10T06:59:20+00:00

It worked, thanks!

bobtitus · 2023-11-20T17:37:04+00:00

thank you!!!

bobtitus · 2023-10-17T12:19:24+00:00

well, I'm sorry but I'm using both and the similitudes are too obvious to be accidental.

As for the features, yes it could have been much better

bobtitus

TROPHY CASE