Large file upload fails (>10GB) with HTTP 500 - no error in logs

Seafile Server
1

Hi,

I’m running Seafile CE 13.0-latest via Docker behind an external nginx reverse proxy (on a separate VPS, connected via Tailscale). Smaller uploads (4GB) work fine, but uploads >10GB consistently fail with “Internal Server Error”.

What happens:

  • Upload runs completely (all data transferred, confirmed via network monitoring)

  • Multiple chunks succeed with HTTP 200

  • Final chunk/commit fails with HTTP 500 after ~0.06s

  • No errors in seafile.log, seahub.log, or seafhttp.error.log

seafhttp.access.log:

[19/Jan/2026:14:48:45 +0100] "POST /seafhttp/upload-aj/..." 200 17 ... 0.026
[19/Jan/2026:14:48:47 +0100] "POST /seafhttp/upload-aj/..." 500 28 ... 0.065

The instant 500 response suggests rejection, not a timeout.

Tested with:

  • Firefox web upload → HTTP 500

  • Android app 3.0 → same result

seafile.conf:

ini

[fileserver]
port=8082
web_token_expire_time=36000

External nginx (VPS):

nginx

location / {
    proxy_pass http://TAILSCALE_IP:8086;
    proxy_connect_timeout 36000s;
    proxy_read_timeout 36000s;
    proxy_send_timeout 36000s;
    send_timeout 36000s;
    proxy_request_buffering off;
    client_max_body_size 0;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_http_version 1.1;
}

Internal nginx (container) /seafhttp block:

nginx

location /seafhttp {
    rewrite ^/seafhttp(.*)$ $1 break;
    proxy_pass http://127.0.0.1:8082;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    client_max_body_size 0;
    proxy_connect_timeout 36000s;
    proxy_read_timeout 36000s;
    proxy_send_timeout 36000s;
    send_timeout 36000s;
}

Environment:

  • Seafile CE 13.0-latest (Docker)

  • MariaDB 10.11

  • Redis 7

  • External reverse proxy on separate server

I found a similar issue here: Seafile 13 docker syncing big file using Android app fails - same symptoms, no solution yet.

Any ideas what could cause the silent HTTP 500?

2

Thank you for the clarification. It’s crucial to understand that the 500 error from seafhttp.access.log indeed points to the seaf-server component as the source of the issue. This means the problem likely lies within Seafile’s core file handling logic. Therefore, in addition to seafile.log, the fileserver.log should be thoroughly examined for any corresponding error messages or warnings during the large file upload attempt.

This log file is specifically relevant for issues occurring within the file serving and processing components of Seafile, which would include the final commit phase of a large upload.

If you don’t have corresponding error in the log file, Look for errors related to file processing, storage, memory allocation, or any specific exceptions thrown by the seaf-server that were not previously apparent. It may be caused by seaf-server component crash.

3

Thanks for the hint. I checked fileserver.log - nothing there either.

But I found the actual cause: The problem only occurs with encrypted libraries. Unencrypted libraries work fine, even with 10GB+ files.

This makes sense now: When using encrypted libraries via web/app, the server caches the decryption password for 1 hour. My 10GB upload takes longer than that, so by the time the final commit happens, the password cache has expired → instant HTTP 500 rejection.

This explains:

  • Why the error happens in ~0.06s (server checks cache, finds nothing, rejects)

  • Why 4GB works (upload < 1 hour)

  • Why 10GB fails (upload > 1 hour)

  • Why there are no logs (it’s not a crash, just an expired session)

According to an older thread, this 1-hour limit is hardcoded and not configurable. Is there any way to increase REPO_PASSWORD_SET_TTL or similar? This would be a useful feature for users with slow connections uploading large files to encrypted libraries.

4

There is no such settings yet.

5

Thanks for confirming.

Would it be possible to add a configurable setting for the encrypted library password cache timeout in a future version?