[Bug]: Syncing of files bigger than about 20M stalls and ends in a timeout. #5932
Comments
Volker-K
changed the title
|
Additional Info: |
|
Meanwhile we've tried:
Windows errorcode = 0x80070185 Seems to be an old problem with Windows settings?!? |
|
Possibly a new occurence of #3495? |
|
Still there, no changes after several Win 11 fixpacks. Error while using virtual files: |
|
Test with client 3.11.0 No changes on a freshly installed Windows 11. On a Win11 that was migrated from Win10, there are still inexplicable waiting times, but at first glance they are much less serious than before (no synchronization of new files lasting several hours due to pauses). So this seems to be a different problem. This leaves us with the error situation that occurs on a freshly installed Windows 11. Another error code can be generated by repeated retries: 0x80070185 The problem solutions for this error also appear similarly helpless and desperate as those for the first error code. A hint "Dance around a campfire at night and sing to fix the error" would no longer stand out in this collection. |
|
No change with Win11-Update KB5033375 |
|
And still no change with Windows 11 updates KB5033920 and KB5034123. |
|
After freshly installing my machine and Update KB5034123 the filesize changes in each synchonization-try between 50M and 11G. For most users it will be ok as long as they ignore the error message. But no solution. |
|
client 3.12.2 also affected with files 2MB+ |
|
Last week we apparently managed to fix the problem at least at our site. To access the cloud from the company intranet, you had to use a proxy and the load balancer. The IP address of the cloud server did not resolve to the private network 10.x.x.x but was the same IP that was also accessed from the Internet. To keep the growing load away from the proxy, especially for the sync clients, we switched to a split DNS solution last week. The cloud will now also be accessed from our private network via an address in the private network with 10.x.x.x. At the beginning, the proxy configuration settings on the desktops still forced access via the proxy and the external address; only the IP of the cloud resolved locally to an address on the intranet. But the moment the DNS delivered the internal address, the problem was solved, even if the actual access path was unchanged. As soon as the desktop and cloud work with a 10.x.x.x address, Windows seems to consider this to be access in the LAN (which it ultimately is) and the error no longer occurs. |
|
I our case, we use external IP for self-hosted cloud. If people are inside network the firewall redirect them to internal IP, if they are outside, the Firewall use NAT. Currently the only workaround I found is marking file that is not open to be storage always on this machine, the client is stuck on "preparing to sync" so you need to shutdown client, open client, it will sync file without issue, and I'm able to open that file. |
|
It's also on files that are smaller than 100KB |
joshtrichards
added
stable-3.9
|
So this sounds like some sort of local matter? I'm not sure really sure there's much we could do about any of that within the client itself. Put another way: what would you have us do within the client itself to make this better (if anything)? :-) |
If you are asking me, if I knew what should be fix I would PR that already. We used to have OneDrive and it wouldn't throw that error, syncthing (which is something else) also nothing, from my end it looks like server/client has some issues - can't tell if its only for special characters ( #5695 ) because from I remembered there where few that didn't had those, but I don't beat my life on that. Currently I know that if person is affected he need to set that files as "always local", shutdown nextcloud client, start nextcloud client and now you can access that file that other way for some strange reason he couldn't, which is something unwanted. If I can provide you with any logs, time frames or anything that could help resolve this issue just tell. |
|
Hi, We see the same issue with a customer. In the log I think there is something weird when this happens, I don't know how to explain, so here is some logs if this can help you (and we have HAproxy as reverse proxy in front) : Note : in web browser (through the haproxy like the client on the computer) the header oc-etag match the etag return from occ command. Best regards, |
|
|
Some years ago we had at Win 9 a similar problem with PDF and ZIP files only. At that time we had a look via Wireshark and found timeouts in the TCP stack of te client. Windows Defender was switched off by a rule and our malware suite was deinstalled. Nevertheless it worked without those timeouts the moment we added the address of our cloud to the list of "trusted sites" in the settings. We found it on MSIE in those days. It's hidden somewere else now. Seems that not trusted sites were scanned by the disabled Defender. Similar to the solution we found this time: Put server IP and client IP in the same network and it works." It's both the same LAN so it simply must be trustable." |
|
This one is without any PL characters in its path: This one is on different server also. |
Bug description
After installing Desktop Client 3.9.1 freshly on Windows 11, sync of locally stored files as well as download of virtual files with a size larger than approximately 20M stalls and ends in a timeout that stops the whole client to work for a while.
Downloading the respective file from the cloud using any browser works. Copying the file when the cloud account is mounted via WebDAV works.
Similar problems found:
#5028 (Win 11, Client 3.6)
#5779 (Problem found with file datetime, checked it, no problem here)
#5394 (Win 10, Client 3.6.6)
With earlier versions we encountered a similar problem that was obviously caused by some unidentified windows routine that possibly tried to scan files. Windows Defender was deactivated as well as we reproduced it w/o our own malware protection bein installed. After adding the URL of the Nextcloud server to the list of trusted zones in Window's internet settings the problem disappeared. The URL is currently included in this list.
Steps to reproduce
Install Sync Client on Windows 11, connect to a NC Instance.
When using local storage the syncing will stall at the first file > 20M and continue with an error message concerning the timeout after a long timeout period (several minutes), and stall again at the next bigger file.
When using virtual files, the progress bar while downloading the file will stall and end in a timeout. In this case it takes a long time for the client to be able to sync again oder even download files of 100k.
Expected behavior
Syncing and downloading should work with files of any size (that Windows can handle...)
Which files are affected by this bug
IT.NRW - Zwei-Faktor-Authentisierung-Setup (x64).msi, Nextcloud-3.9.1-x64.msi
Operating system
Windows
Which version of the operating system you are running.
Windows 11
Package
Appimage/MSI file
Nextcloud Server version
26.0.2.1
Nextcloud Desktop Client version
3.9.1
Is this bug present after an update or on a fresh install?
Fresh desktop client install
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
Are you using an external user-backend?
Nextcloud Server logs
Nothing found in the server logs.Client Debug-Log:
debug.zip
Additional info
No response
The text was updated successfully, but these errors were encountered: