Strange behavior Seafile 13 CE with big files

[Gewoondemax]

Running Seafile 13 CE in Docker and NGINX as proxy. I have problems with transferring files > 1Gb and despite tweaking the NGINX no solution yet. it errors with a 504

BUT - when I create a folder to sync on my remote machine, and the using the Seafile app pointing what folder needs to be synced…. even files bigger than the problematic 1Gb are being synced.

I started back from scratch a clean NGINX proxy manager and clean sync folder to test. With clean I mean no additional things to overcome the (> 1Gb) issue. and running now this configuration for over a 2 weeks or so.

Manual upload a file > 1.Gb: applet log:
[11/19/25 08:31:43]libpng warning: iCCP: known incorrect sRGB profile
[11/19/25 08:31:43][Rpc Client] connected to daemon
[11/19/25 08:31:43][Rpc Client] connected to daemon
[11/19/25 08:32:58][FileBrowser] upload or update files: QList(“/Users/max/Downloads/playground-changinggame-nl-20251018-190626-olx6cj3zfxnq.wpress”)
[11/19/25 08:32:58][FileBrowser] upload or update file: “/Users/max/Downloads/playground-changinggame-nl-20251018-190626-olx6cj3zfxnq.wpress”
[11/19/25 08:32:58][DataManager] upload task created, repo_id = “be41a4c0-aeba-4642-8660-100a442635f8” , parent_dir = “/PROJECTS” , local_path = “/Users/max/Downloads/playground-changinggame-nl-20251018-190626-olx6cj3zfxnq.wpress” , commit_id = “” , name = “playground-changinggame-nl-20251018-190626-olx6cj3zfxnq.wpress” , overwrite = false , size = 1857833032 , mtime = QDateTime(2025-10-18 19:14:09.156 CEST Qt::LocalTime)
[11/19/25 08:38:32]request failed for https://mydomainname/seafhttp/upload-api/3cef7a20-1411-4fae-a807-8e310baeeba6: status code 504

when running the Sync.

The Event log:

[11/19/25 08:45:17] synctestmap eb37ba2a-ca8c-4c7e-b6f0-a970cf4a3ad8 d67a5d686c35e9546f5f1e3c4650e60f3ca6bf32
[event 1] create/update, playground-changinggame-nl-20251018-190626-olx6cj3zfxnq.wpress
[11/19/25 08:52:44] synctestmap eb37ba2a-ca8c-4c7e-b6f0-a970cf4a3ad8 31a87b2113f0a71bfb1e326fc7bb47a57cc6a5ae

The Seafile log:

[11/19/25 08:04:51] seaf-daemon.c(558): starting seafile client 9.0.15
[11/19/25 08:04:51] seafile-session.c(390): client id = b3265ab5f5f0f413121bd19e69bcf39bc67b836b, client_name = Laptop-van-Max.local
[11/19/25 08:04:51] socket file exists, delete it anyway
[11/19/25 08:04:51] seaf-daemon.c(587): rpc server started.
[11/19/25 08:31:41] seaf-daemon.c(558): starting seafile client 9.0.15
[11/19/25 08:31:41] seafile-session.c(390): client id = b3265ab5f5f0f413121bd19e69bcf39bc67b836b, client_name = Laptop-van-Max.local
[11/19/25 08:31:41] socket file exists, delete it anyway
[11/19/25 08:31:41] seaf-daemon.c(587): rpc server started.
[11/19/25 08:44:38] clone-mgr.c(702): Transition clone state for eb37ba2a from [init] to [check server].
[11/19/25 08:44:38] clone-mgr.c(702): Transition clone state for eb37ba2a from [check server] to [fetch].
[11/19/25 08:44:38] http-tx-mgr.c(1255): Transfer repo ‘eb37ba2a’: (‘normal’, ‘init’) → (‘normal’, ‘check’)
[11/19/25 08:44:38] http-tx-mgr.c(1255): Transfer repo ‘eb37ba2a’: (‘normal’, ‘check’) → (‘normal’, ‘commit’)
[11/19/25 08:44:38] http-tx-mgr.c(1255): Transfer repo ‘eb37ba2a’: (‘normal’, ‘commit’) → (‘normal’, ‘fs’)
[11/19/25 08:44:38] http-tx-mgr.c(1255): Transfer repo ‘eb37ba2a’: (‘normal’, ‘fs’) → (‘normal’, ‘data’)
[11/19/25 08:44:38] http-tx-mgr.c(1255): Transfer repo ‘eb37ba2a’: (‘normal’, ‘data’) → (‘finished’, ‘finished’)
[11/19/25 08:44:38] clone-mgr.c(702): Transition clone state for eb37ba2a from [fetch] to [done].
[11/19/25 08:44:38] sync-mgr.c(1680): File syncing protocol version on server https://mydomainname is 2. Client file syncing protocol version is 2. Use version 2.
[11/19/25 08:44:39] sync-mgr.c(607): Repo ‘synctestmap’ sync state transition from ‘synchronized’ to ‘committing’.
[11/19/25 08:44:39] repo-mgr.c(4449): All events are processed for repo eb37ba2a-ca8c-4c7e-b6f0-a970cf4a3ad8.
[11/19/25 08:44:39] sync-mgr.c(607): Repo ‘synctestmap’ sync state transition from ‘committing’ to ‘initializing’.
[11/19/25 08:45:12] sync-mgr.c(607): Repo ‘synctestmap’ sync state transition from ‘synchronized’ to ‘committing’.
[11/19/25 08:45:17] repo-mgr.c(3022): Creating partial commit after adding playground-changinggame-nl-20251018-190626-olx6cj3zfxnq.wpress.
[11/19/25 08:45:17] sync-mgr.c(607): Repo ‘synctestmap’ sync state transition from ‘committing’ to ‘uploading’.
[11/19/25 08:45:17] http-tx-mgr.c(1255): Transfer repo ‘eb37ba2a’: (‘normal’, ‘init’) → (‘normal’, ‘check’)
[11/19/25 08:45:17] http-tx-mgr.c(1255): Transfer repo ‘eb37ba2a’: (‘normal’, ‘check’) → (‘normal’, ‘commit’)
[11/19/25 08:45:17] http-tx-mgr.c(1255): Transfer repo ‘eb37ba2a’: (‘normal’, ‘commit’) → (‘normal’, ‘fs’)
[11/19/25 08:45:17] http-tx-mgr.c(1255): Transfer repo ‘eb37ba2a’: (‘normal’, ‘fs’) → (‘normal’, ‘data’)
[11/19/25 08:48:02] http-tx-mgr.c(1255): Transfer repo ‘eb37ba2a’: (‘normal’, ‘data’) → (‘normal’, ‘update-branch’)
[11/19/25 08:48:03] http-tx-mgr.c(1255): Transfer repo ‘eb37ba2a’: (‘normal’, ‘update-branch’) → (‘finished’, ‘finished’)
[11/19/25 08:48:03] sync-mgr.c(607): Repo ‘synctestmap’ sync state transition from ‘uploading’ to ‘initializing’.
[11/19/25 08:48:03] sync-mgr.c(908): Removing blocks for repo synctestmap(eb37ba2a).
[11/19/25 08:48:03] sync-mgr.c(607): Repo ‘synctestmap’ sync state transition from ‘synchronized’ to ‘committing’.
[11/19/25 08:48:03] repo-mgr.c(4262): All events are processed for repo eb37ba2a-ca8c-4c7e-b6f0-a970cf4a3ad8.
[11/19/25 08:48:03] sync-mgr.c(607): Repo ‘synctestmap’ sync state transition from ‘committing’ to ‘synchronized’.

So what is the caveat?

A small stupid question is where/how can I check that the files are really synced and I can trust the finished

[daniel.pan]

@Gewoondemax

A small stupid question is where/how can I check that the files are really synced and I can trust the finished

When you see the “checked” mark, and there is no obvious error in the UI, you can assume the the syncing is success.

[daniel.pan]

The syncing process break the files into small blocks. So it is not relevant to your problem.

You can focus on why large files cannot be correctly uploaded to your server via Web interface.

This points towards a potential issue with NGINX configuration or timeout settings when dealing with large file uploads.

Possible Reasons for 504 Error:

1. NGINX Timeout Settings:

• The default timeout settings in NGINX might be too low for transferring large files. Consider increasing the proxy_read_timeout, proxy_connect_timeout, and proxy_send_timeout values to accommodate larger file sizes and longer upload durations.

2. Client Maximum Upload Size:

• The client configuration client_max_body_size in NGINX should be set to 0 (unlimited) as you appear to have done, but confirm this in both the main NGINX config and within any site-specific config.

3. HTTP/2 Issues:

• If HTTP/2 is enabled, you may want to experiment with disabling it as various reports suggest that HTTP/2 can cause issues with Seafile uploads, indicated by changes in response handling.
• Check the potential need for adjustments in the NGINX HTTP/2 protocols to resolve any conflicts that arise during large transfers.

[Gewoondemax]

Thank you Daniel the HTTP/2 issue might be the catch - that is what i activated after upgrading from old to new. changing settings HTTP/2 or change to HTTP does not affect.
Let me first tell the good news - you pointed me in the right direction - and a big file upload works now …

running a 200Mb file takes starting time: [11/20/25 08:31:16] - finished time [11/20/25 08:32:19]

running a 500Mb file takes starting time: [11/20/25 08:32:36] - finished time [11/20/25 08:36:07]

running a 1 Gb file takes starting time: [11/20/25 08:37:04] - finished time [11/20/25 08:41:25]

running a 4.5 Gb takes starting time: [11/20/25 08:42:02] - finished time [11/20/25 09:00:42]

When the finished time has reached the popup window from the upload finally disappears … during the whole time you see no progress anymore only that the full data has been received.

Maybe another status message appears telling that Seafile is still busy gathering whatever but the upload data is received completely?

using the browser and adding a page the max upload for Seafile is < 1Gb otherwise you get an error “Out of Quota”. Is this to be changed? the max filesize and where can we do that?

What did i change to get this working in NGINX (thank you again for pointing me to the right direction).
In The NGINX proxy manager advanced Tab:
proxy_request_buffering off;
client_max_body_size 0;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_connect_timeout 36000s;
proxy_read_timeout 36000s;
proxy_send_timeout 36000s;
send_timeout 36000s;

Here the results with file upload:
[11/20/25 08:31:16][FileBrowser] upload or update files:
QList(“/Users/max/Downloads/seafile-client-9.0.15.dmg”)
[11/20/25 08:31:16][FileBrowser] upload or update file:
“/Users/max/Downloads/seafile-client-9.0.15.dmg”
[11/20/25 08:31:16][DataManager] upload task created, repo_id = “be41a4c0-aeba-4642-8660-100a442635f8” , parent_dir = “/PROJECTS/MYBONDZ” , local_path = “/Users/max/Downloads/seafile-client-9.0.15.dmg” , commit_id = “” , name = “seafile-client-9.0.15.dmg” , overwrite = false , size = 206907341 , mtime = QDateTime(2025-11-05 08:48:36.709 CET Qt::LocalTime)
[11/20/25 08:32:19][DataManager] upload (multiple) task finished, success = true , repo_id = “be41a4c0-aeba-4642-8660-100a442635f8” , path = “/PROJECTS/MYBONDZ”
[11/20/25 08:32:36][FileBrowser] upload or update files:
QList(“/Users/max/Downloads/mybondz-com-20250911-131649-epbeogmacc2z.wpress”)
[11/20/25 08:32:36][FileBrowser] upload or update file:
“/Users/max/Downloads/mybondz-com-20250911-131649-epbeogmacc2z.wpress”
[11/20/25 08:32:36][DataManager] upload task created, repo_id = “be41a4c0-aeba-4642-8660-100a442635f8” , parent_dir = “/PROJECTS/MYBONDZ” , local_path = “/Users/max/Downloads/mybondz-com-20250911-131649-epbeogmacc2z.wpress” , commit_id = “ ” , name = “mybondz-com-20250911-131649-epbeogmacc2z.wpress” , overwrite = false , size = 493653529 , mtime = QDateTime(2025-09-24 13:57:21.944 CEST Qt::LocalTime)
[11/20/25 08:36:07][DataManager] upload (multiple) task finished, success = true , repo_id = “be41a4c0-aeba-4642-8660-100a442635f8” , path = “/PROJECTS/MYBONDZ”
[11/20/25 08:37:04][FileBrowser] upload or update files:
QList(“/Users/max/Downloads/Affinity.dmg”)
[11/20/25 08:37:04][FileBrowser] upload or update file: “/Users/max/Downloads/Affinity.dmg”
[11/20/25 08:37:04][DataManager] upload task created, repo_id = “be41a4c0-aeba-4642-8660-100a442635f8” , parent_dir = “/PROJECTS/MYBONDZ” , local_path = “/Users/max/Downloads/Affinity.dmg” , commit_id = “ ” , name = “Affinity.dmg” , overwrite = false , size = 981361373 , mtime = QDateTime(2025-10-31 09:53:46.677 CET Qt::LocalTime)
[11/20/25 08:41:25][DataManager] upload (multiple) task finished, success = true , repo_id = “be41a4c0-aeba-4642-8660-100a442635f8” , path = “/PROJECTS/MYBONDZ”
[11/20/25 08:42:02][FileBrowser] upload or update files:
QList(“/Users/max/Downloads/backup_changinggame.nl_2509150203_2509170043.tar”)
[11/20/25 08:42:02][FileBrowser] upload or update file:
“/Users/max/Downloads/backup_changinggame.nl_2509150203_2509170043.tar”
[11/20/25 08:42:02][DataManager] upload task created, repo_id = “be41a4c0-aeba-4642-8660-100a442635f8” , parent_dir = “/PROJECTS/MYBONDZ” , local_path =
“/Users/max/Downloads/backup_changinggame.nl_2509150203_2509170043.tar” , commit_id = “ ” , name = “backup_changinggame.nl_2509150203_2509170043.tar” , overwrite = false , size = 4471243620 , mtime = QDateTime(2025-09-19 14:31:55.941 CEST Qt::LocalTime)
[11/20/25 09:00:42][DataManager] upload (multiple) task finished, success = true , repo_id = “be41a4c0-aeba-4642-8660-100a442635f8” , path = “/PROJECTS/MYBONDZ”

Next project = I have to get the Seadoc to work - ….

[daniel.pan]

@Gewoondemax

Maybe another status message appears telling that Seafile is still busy gathering whatever but the upload data is received completely?

I cannot reproduce the issue. When I upload a large file via cloud file browser in the desktop client, there is a progress shown.

Maybe I misunderstand your problem. Do you have a screenshot?

@Gewoondemax

using the browser and adding a page the max upload for Seafile is < 1Gb otherwise you get an error “Out of Quota”. Is this to be changed? the max filesize and where can we do that?

This depends on the quota setting of your server. In plus.seafile.com, the default quota for trial account is 1GB.

[Gewoondemax]

Hello Daniel,

sorry for the late response, but had to serve my customers first i also created a screen movie, but this is not accepted by the community so i had do make some screenshots. Hope you have a good weekend!

I indeed did not explain correctly. The incremental filesize works that is not the issue.

The problem is when the upload has finished, the Upload window stays forever (it looks like) in the status upload. While Seafile is doing something in the background?? The user is not warned …

See my example I upload a file with 933Mb, in the ‘Seafile Cloud file browser window’ looks identical, but as you closely look the filesize is different 943,7Mb.
The Upload window has no status change, and the file 933Mb is not yet available in the ‘Seafile Cloud file browser window’. This image you will see “as long as it is needed for Seafile to do it’s stuff”.

The ONLY way to see if Seafile is working is in the applog window. When finished you see in the applog window the upload is finished. And after this line the name of the uploaded file appears in the ‘Seafile Cloud file browser window’. …. But as you can see (screenshot below) the Modifier is not mentioned .. and will only shown after a screen refresh or stop and start from Seafile Client.

My experience is when the file is bigger that 4.x Gb the waiting time is between 11-15 minutes before the Upload Status window disappears and the file is named in the ‘Seafile Cloud file browser window’.

Hope this clarifies? I test with MacOS Ventura MB-Pro i7 - 16/512 and MacOS 26 MBAir 15” - M3 16/512 and MacOS Sonoma Mac mini - M1 32/1T … where Seafile Client result are almost identical with the machines.

greetings Max