For now, I can only tell that we test the synchronization of remote and local changes in two different scenarios: when a server does have a high performance backend installed and enabled (“push notifications” for file changes) and when it does not. In our test scenarios, this works fine.
I assume the devil is in the details of your use case. Since you already mentioned a data volume of around 1 TB: How is it composed? Do you have mostly large files like videos or similar types which usually are large? Or do you have a situation with rather thousands, hundred thousands or higher orders of magnitude in terms of file quantity? A recent topic we are confronted with are folder with thousands or more files which can slow down Nextcloud servers (depends on the infrastructure used and resource available) so much that the invisible background activity of fetching the news from the server takes so long that the client appears stuck with what it has.
Regarding the data set, it is my archive of about 1 TB stored on an external Toshiba drive. It mainly contains:
Adobe Illustrator (.ai) files
Photoshop (.psd) files
PDF documents
Images / Fotos (.jpg, .png)
Music
Office documents
Fonts
Other design assets
There are many folders and subfolders, but this exact dataset synchronized correctly until I upgraded to Desktop Client 34.x.
After doing some additional testing, I noticed something that may help narrow down the issue:
Server → Client synchronization works correctly.
If I upload a file or create a folder through the Aruba Drive web interface, the Desktop Client (Nextcloud) immediately detects the change, downloads it locally, and shows it in the Activities list.
Client → Server synchronization does not work.
If I create a new file or folder inside my local synchronized folder, nothing happens:
no activity appears in the Desktop Client (Nextcloud);
the item is never uploaded to the server;
pressing “Sync now” does not trigger any visible synchronization.
I also noticed that the Finder context menu no longer shows any Nextcloud actions (such as keeping files downloaded or freeing space) inside the synchronized folder.
The synchronized folder is located on an external Toshiba drive, and this exact setup worked perfectly before upgrading to Desktop Client 34.x.
One more observation: the issue started immediately after upgrading to Desktop Client 34.x. No changes were made to the server, the folder structure, or the external drive itself.
Could this indicate a problem with detecting local filesystem events or with the macOS File Provider integration rather than the dataset size?