I have a client running the Nextcloud client software under Windows 10, which has miserable upload performance, about 540kBit/s - yes: kilo-bit/s!
server side:
running under Linux as a snap (of course up to date version)
server is in the same LAN
CPU / network / IO load on the server side is near to zero, 99% idle
with another client (Linux) I get perfect upload speeds ~800MBit/s
played with upload chunk size in the PHP setting - no effect
virus scanner is disabled
ransomware protection is disabled
nothing suspicious in the logs
client side (notebook):
Client version is 3.16.2 (updated today, didn’t change anything)
connected via WiFi, also tried via ethernet cable (no change)
power management of the network adapters is off
QoS is also OFF
Bandwith limit settings in the NC client is OFF (also played with different settings/values → no change)
Windows Defender: firewall is OFF, realtime protection is OFF, ransomware protection is OFF
CPU load is ~36%
memory is ~50% free, no swapping activity
disk (SSD) I/O load is nearly zero
iperf from notebook to server gives rates above 500MBit/s → cannot be a network problem.
Looking at the incoming packets on the server side with tcpdump shows nothing suspicious.
My conclusion is that this must be a problem of the client software. The sever is practically completely idle and the rate limit is so “perfect” at 540kBit/s (monitored via task manager) that it looks like some kind of “rate limiting” feature which does that “intentionally”. But where?
Does anyone have an idea what goes wrong here, why uploads are factor 1000 slower than expected, or how else I could do diagnostics?
With Win 11 there was a problem with Client version is 3.16.1. I switched back to version 3.16.0 to solve it for the moment. Older Versions you will find here: nextcloud-releases / desktop. Not perfect but might be a solution for now.
sorry, I downgraded to v3.16.0, rebooted, but I cannot see any change, still ~500kBit/s…
When I try to set the upload bandwidth limit to something very low, e.g. 20 KByte/s, I get a transfer with ~200kBit/s, which is ok.
Then I increased the value to 200 kByte/s but nothing changes, it stays at 200kBit/s. Then I stopped and restarted the synchronization and I am back at 500kBit/s.
My impression is that something internally does not accept my bandwidth settings and then continues to apply some other limitation, maybe the last one that has worked or whatever…
Unfortunately that makes a difference in the area of some single-digit percentage, not factor 1000.
I also stopped the Nextcloud process, opened the config file, removed everything that has to do with rate limits, but that did also not change anything.
@dg6nee here ist another post (Endless syncing on Linux 3.15.2 and 3.15.3, 3.14.3 was fine) reporting problems with the Linux-Client 3.15.3. The essence of it is that any Client after 3.14.3 constantly detects changes in seemingly all files and writes one log file after the other full of entries. Thats slows down the client until stopping.
Maybe the Windows Client also noiticed permanent changes like on Linux OS and that will slow it down so much?
What I see is different. It syncs one jpg file after the other, one by one, each one has some megabytes, but with a speed that I cannot explain. It advances to the next file in the list, there is some “progress”, but factor 1000 too slow.
Now I found some logfiles from today, in a temporary folder, with thousands of messages like these:
2025-03-24 15:21:37:475 [ warning nextcloud.sync.propagator C:\Users\User\AppData\Local\Temp\windows-29045\client-building\desktop\src\libsync\owncloudpropagator.cpp:583 ]: WARNING: Job within a removed directory? This should not happen! “Urlaub/P1050699.jpg” CSyncEnums::CSYNC_INSTRUCTION_NEW
I did a speed-Contest with some mp4-Files (Videos from Smartphone)
I used a Notebook, Dual-Boot, Windows 11 Pro and Xubuntu 24.04. So all used Hardware is the same. First uploaded those files from WIndows to Useraccont A on my Nextcloud in my LAN. Then reboot the Notebool to Xubuntu and uploaded those files from NTFS-Partition to Useraccont B on my Nextcloud.
Windows need 1m 13s for upload. Xubuntu 0m 15s. Thats factor 5 faster with Linux-Client. But nothing to compare with what you report. Windows Client was 3.16.1 Linux Client from Ubuntu-deb-Installation was 3.11
The time for upload with Linux client is nearly same as if i do a upload with scp to nextcloud device.
So is supect your problem is related to Windows 10, that will not occur on Windows 11
Well its not realy helpfull in your current situation. I did it merely to find out i have similar problems and check on my end for a solution. But thats not given.
So to your question: since End of Support of Windows 10 is October 2025 you may give anyway Windows 11 a chance in near future.
I uninstalled NC, wiped all directories with the name “Nextcloud” from the hard disk, removed all traces I was able to find from the registry, rebooted, re-installed NC and configured all synchronisations again.
Then it started to download some things, with about 800 MBit/s, up to a point where it should upload some pictures, and now the upload direction is active and even slower as before, ~280 kBit/s. All this while the server side shows CPU load, network load and I/O load of practically zero. The client side has CPU load of ~40% which I think is ok, and hard disk load zero.
I used the windows task manager, analyzed the “Details” of the nextcloud task, and found a menu entry called “Wait queue”. That shows that NC is waiting for “Explorer” most of the time and that “Explorer” uses a notable amount of CPU time (~26% CPU load).
Then I terminated the “explorer” task (just because I was curious), and then came the big “wow” effect => suddenly the upload was running with fullspeed, about 100MByte/sec!!!
Of course this is no “solution”, as terminating explorer.exe also makes the whole desktop and so on go away, but this may point to the root cause of the trouble…
=> is there a (config) option to cut off the connection from NC to explorer ?
I had similar problem with nc client for windows. I could not find out the reason but after rebooting my switch in my lan the problem went away. Before - like in your case - nc client was idle but windows explorer was using about 50% of cpu.
OK, as I wrote in my first post: it made no difference which physical network layer I use. I tried first: WiFi with builtin adapter, WiFi with 2 different USB adapters, direct LAN connection - made no difference. Also rebooting the router (I did this as well) has no effect.
IMHO this is an effect that has to do with the communication between the NC client process and the “explorer” process. No idea what this is good for or if this is the root cause, it’s just an observation…
There is a bug report with the same error message:
I wanted to suggest to create a new account and start with new data. But this already shows that the client, network and server can handle higher speeds. These pictures, is there anything special, no hardlinks, no “strange” file names, extremely deep directory structure, network storage, no disk problems, …?
