Large file/directory downloads fail with timeout or network error

OnDemand version: 4.2.3

Hi,

I’m experiencing issues when downloading large files or directories through Open OnDemand.

Environment

  • Small files download successfully without any issue.
  • Problem occurs with:
    • A directory of approximately 1.5 GB
    • A large tar archive containing this directory

Case 1: Large file (.tar)

The download starts normally:

  • Browser shows the transfer progress and throughput.
  • Data appears to be transferred correctly.
  • However, once the download reaches 100%, the browser cancels it and reports:
Network Error ('Erreur' réseau in French)

image

So the failure happens at the very end of the transfer.

Case 2: Large directory download

Initially, attempting to download the directory resulted in a proxy timeout error.

I increased:

OOD_DOWNLOAD_DIR_TIMEOUT_SECONDS=15

which resolved the proxy error during archive creation.

The directory can now be prepared successfully, and I get:

can_download = true

However, the process then seems to hit another timeout after approximately 30 seconds, preventing the download from completing.


Question

Does anyone know:

  • Which timeout controls the actual file transfer/download phase after can_download = true?
  • Whether there is another Open OnDemand, Passenger, NGINX, Apache, or proxy setting that needs to be increased for downloads larger than ~1.5 GB?
  • Has anyone encountered a browser-side “Network Error” occurring only after the download reaches 100%?

Any pointers on where to investigate next would be greatly appreciated.

Thanks you for your help :folded_hands:

I have seen very similar behavior, and never resolved it but mentioned what I’d found here:

Frustratingly, the cutoff for what filesize was too big was never written in stone – sometimes a given ~1.5gb file would upload with success, other times it would (appear to) fail.

I had a theory that it had something to do with my /tmp or /var (lvm-)filesystem filling up since I discovered a given upload will eat up space on both. This didn’t seem to be the root issue for me (at least with the brief investigation I did) but maybe worth checking if it’s the case for you: PSA: File Manager uploads use both /var and /tmp space

My example watch-script is admittedly hard to read but the gist of it is a single upload temporarily stores three copies, like:

  • /proc/1386416/fd/8 => /var/tmp/ondemand-nginx/USERID/client_body/0000000001 (deleted)
  • /proc/1795862/fd/10 => /tmp/PassengerTeeInput-1l86ohu (deleted)
  • /tmp/RackMultipart20260219-1795862-wimnh4.zip