Windows 11 Explorer freez with NextCloud Client 33.0.x (up to 33.0.5)

For the past few days, I’ve noticed some strange behavior in Windows 11 File Explorer. As the day goes on, it becomes increasingly sluggish and sometimes takes up to 30 seconds to display the save dialog.

The reason I’m writing this is that, at the same time, the NextCloud client (33.0.2) is generating a huge number of log entries (every minute a new gz file with 20-200KB). It seems that the following entries keep repeating themselves (Update: Contrary to my initial assumption, the number of log entries didn’t seem to have anything to do with the problem.):

2026-04-15 08:13:54:927 [ info nextcloud.sync.vfs.cfapi.wrapper C:\Users\User\AppData\Local\Temp\windows-38496\client-building\desktop\src\libsync\vfs\cfapi\cfapiwrapper.cpp:475 ]:	Desktop client process id: 2652
2026-04-15 08:13:54:927 [ info nextcloud.sync.vfs.cfapi.wrapper C:\Users\User\AppData\Local\Temp\windows-38496\client-building\desktop\src\libsync\vfs\cfapi\cfapiwrapper.cpp:477 ]:	Open file completed by process id: 15448
2026-04-15 08:13:54:927 [ info nextcloud.sync.vfs.cfapi.wrapper C:\Users\User\AppData\Local\Temp\windows-38496\client-building\desktop\src\libsync\vfs\cfapi\cfapiwrapper.cpp:478 ]:	Open file completed by application id: "UNKNOWN"
2026-04-15 08:13:54:941 [ info nextcloud.sync.vfs.cfapi.wrapper C:\Users\User\AppData\Local\Temp\windows-38496\client-building\desktop\src\libsync\vfs\cfapi\cfapiwrapper.cpp:634 ]:	Desktop client process id: 2652
2026-04-15 08:13:54:941 [ info nextcloud.sync.vfs.cfapi.wrapper C:\Users\User\AppData\Local\Temp\windows-38496\client-building\desktop\src\libsync\vfs\cfapi\cfapiwrapper.cpp:636 ]:	Close file completion by process id: 15448
2026-04-15 08:13:54:941 [ info nextcloud.sync.vfs.cfapi.wrapper C:\Users\User\AppData\Local\Temp\windows-38496\client-building\desktop\src\libsync\vfs\cfapi\cfapiwrapper.cpp:637 ]:	Close file completion by application id: "UNKNOWN"

But I’m not sure now whether this is a bug in the NexCloud client that I should report, or just a symptom of an Explorer issue.

welcome to the user-forum for Nextcloud.

sadly enough your posting is missing all relevant information about your server, setup and server-environment.

pls use the support template and fill in as much details as you can get.

and don’t forgt to search the forum for similar issues.

Thank you very much for your reply.

I had searched for relevant posts here on the forum and on GitHub, but only found very old posts that have nothing to do with the current setups.

I wasn’t aware that I could also file an official bug report here. I had initially just hoped to get some guidance from the forum on whether I should submit a full bug report here for the project on GitHub or as an Explorer issue with Microsoft.

I’ll gather the necessary information when I have a moment and fill out the bug report on GitHub.

ummm full bug reports are to be filed on GH, of course.

But sometimes it’s just a setup problem or something similar. so you could try your luck here on the forum.

but without knowing anything about your setup it’ll be very unlikely that someone on here COULD solve your problem. That’s why I asked you for more details.

I know that there is/was a thread about windows client being sluggish sometimes here on the forum. but as far as I remember it was kind of ā€œsolvedā€ with a GH-issue (meaning there’s probably nothing the forum could do about).

If a problem only appears every now and then it’s really problematic to track it down to the source of it. even less so if everyone seems to omits more infos about the problematic systems/softwarerversions…

Sorry for the delay in getting back to this. I’m now pretty sure it’s a Nextcloud client issue. More on that below. I’ll provide the basic details about the client computer in additon here. There are no relevant log entries on the server for that time period. Let me know if you’d still like me to post the server logs here.

The Basics

  • Nextcloud Server version (e.g., 29.x.x): 33.0.2

  • Nextcloud Client version: 33.0.2

  • Operating system and version (e.g., Ubuntu 24.04): Linux 6.12.74+deb13+1-amd64 x86_64

  • Client System: Windows 11 Pro 25H2

  • Web server and version (e.g, Apache 2.4.25): Apache 2.4.66

  • Reverse proxy and version _(e.g. nginx 1.27.2): No reverse proxy was configured at the time of the first occurrence

  • PHP version (e.g, 8.3): 8.4

  • Is this the first time you’ve seen this error? (Yes / No): For about two weeks

  • When did this problem seem to first start?: After update to Client 33.0.2

  • Installation method (e.g. AIO, NCP, Bare Metal/Archive, etc.): Bare Metal

  • Are you using Cloudflare, mod_security, or similar? (Yes / No) :No

Summary of the issue you are facing:

Windows Explorer seems to freeze regularly for extended periods (up to 30 seconds) of time when saving or moving files, with Client 33.0.x (with support for virtual files).

The freezing doesn’t happen every time, but only once every 5 minutes, up to a maximum of about once per minute.

Since my first post, I’ve been testing a few changes to try to narrow down the problem a bit more. At the same time, there appears to be a correlation with the creation of client log files larger than 200 KB, when the Explorer freeze. I downgraded the client to 4.0.8 as a test. Everything is running more smoothly again (at least as expected from Windows 11). Large log files have also become much less common. In fact, they only appear when the client starts up.

At the same time, there’s a PC running Windows 10 with Client 33.0.2 right next to me. So far, I haven’t noticed any large log files or freezes in Windows Explorer on this machine (same folder, without support for virtual files). The folder structure is quite large (850 GB) and contains a large number of files.

Steps to replicate it (hint: details matter!):

  1. Frequently saving files (Word, Firefox) or moving files in Windows 11 Explorer

Log entries

Nextcloud Client

There are no relevant log entries on the server for that time period. Let me know if you’d still like me to post the server logs here. In particular, the large client log files are full of the following entries.

2026-04-24 14:49:21:429 [ info nextcloud.sync.account C:\Users\User\AppData\Local\Temp\windows-38496\client-building\desktop\src\libsync\account.cpp:1269 ]:	ls col job "FOLDER" new file "/nextcloud/remote.php/dav/files/USER/FOLDER/FILENAME1" 13
2026-04-24 14:49:21:429 [ warning nextcloud.sync.account C:\Users\User\AppData\Local\Temp\windows-38496\client-building\desktop\src\libsync\account.cpp:1277 ]:	skip existing item "FOLDER/FILENAME1"
2026-04-24 14:49:21:429 [ info nextcloud.sync.account C:\Users\User\AppData\Local\Temp\windows-38496\client-building\desktop\src\libsync\account.cpp:1269 ]:	ls col job "FOLDER" new file "/nextcloud/remote.php/dav/files/USER/FOLDER/FILENAME2" 13
2026-04-24 14:49:21:429 [ warning nextcloud.sync.account C:\Users\User\AppData\Local\Temp\windows-38496\client-building\desktop\src\libsync\account.cpp:1277 ]:	skip existing item "FOLDER/FILENAME2"
2026-04-24 14:49:21:429 [ info nextcloud.sync.account C:\Users\User\AppData\Local\Temp\windows-38496\client-building\desktop\src\libsync\account.cpp:1269 ]:	ls col job "FOLDER" new file "/nextcloud/remote.php/dav/files/USER/FOLDER/FILENAME3" 13
2026-04-24 14:49:21:429 [ warning nextcloud.sync.account C:\Users\User\AppData\Local\Temp\windows-38496\client-building\desktop\src\libsync\account.cpp:1277 ]:	skip existing item "FOLDER/FILENAME3"
...

Quick update:
I’m now pretty sure this is an issue with the 33.0.x client. I’ve tested versions 33.0.2, 33.0.3, and 33.0.4. In between, I always downgraded to 4.0.8. With the 33.0.x version, these massive lags occur, and they disappear again after the downgrade.

The logs don’t really reveal the cause of the problem. I have the feeling that the lags often coincide with the log file change, based on the timestamps.

I’d actually like to share the log files, but unfortunately, I’m bound by confidentiality regarding most of the paths and other details.

The 33.x client has been a disaster for me (and I don’t even mean the terrible GUI), even 4.x is bad in terms of performance. They’re about 30-50% as fast, and generate errors at a drop of hat, compared to an older 3.17.4 client and they probably have many other issues too.

Go back to an older client, maybe on a test machine, and see if the problem goes away. If so, then downgrade the clients and stay on that version.

It’s all too common for Nextcloud to release buggy updates, it’s been an ongoing issue for years for both server and clients. The iOS client was broken literally most of 2025 and even now it has random issues syncing photos.

I’m still on 3.17.4 (Windows) and an older server until I either find an alternative to Nextcloud or they improve the quality. I’m honestly not sure what to do, I like Nextcloud, when it works Nextcloud is great but the constant problems with updates wear me out and client 33 may be the straw that broke the camel’s back. Running a server and client that are few versions back and not updating for a year are the only ways I know to get some stability and performance out of Nextcloud.

Good luck.

The problem persists even with Client 33.0.5. Unfortunately, the logs do not show the exact time at which file accesses start to hang.

However, the freeze ends at the point where the client log shows

ā€œSync state changed for folder ā€˜https://SERVERNAME/’: ā€˜Success’.ā€

Would it make sense to file a bug report without being able to pinpoint the issue in the logs?

With VFS enabled, I tried with the 33.0.5 client, I copied a larger number of files (~1500 in total, split manually over different subfolders, size of files mostly hundreds of kB) into a larger folder structure (folder with 1000 subfolder).

After placing a batch of files I was able to navigate through the subfolders while the client was uploading. Also I tried to save a file there from Notepad++ without problems. Server is a test setup with still 33.0.5 RC1.

Would a procedure like that trigger a problem for you? Or are these rather large files or many to sync?

Just thinking, if your disk has a problem on your Win11 machine that is responsible for the freeze? But that should also show on other heavy file operations independently from Nextcloud.

Thank you very much for your constructive feedback and for running the tests.

I experience the freeze even when I’m just interacting with a single file or folder in the cloud structure—or, to be more precise, that’s naturally when I notice the freeze.

What is large, however, is the existing folder and file structure. Here is the Explorer information for the NextCloud folder:

Size: 860 GB
Size on disk: 425 GB
Contents: 360,000 files, 12,000 folders

The freeze isn’t related to the file size. However, it actually happens in any program that tries to make a change to the file system; the program freezes, and Windows Explorer freezes as well. All other programs continue to work normally, though, as long as I don’t click ā€œSaveā€ or something like that.

Some scenarios:

Word saves in the background and freezes for about 30 seconds
or
I save 3 files in Firefox; the 4th one then gets stuck in the save dialog for 20–40 seconds. After that, it works again for about a minute, and I can save several files, but then another file gets stuck.

Of course, a hardware defect could also be an explanation. But I think the fact that it only ever occurs when NextCloud client version 33.0.x is installed and disappears immediately after downgrading to 4.0.8 argues against that.

I tested every client version from 33.0.1 to 33.0.5 for at least 3 days. It’s noticeable immediately after installation.

Client 33.0.5 Log entry: Sync run took 42409 ms

Client 4.0.8 Log entry: Sync run took 178682 ms

It can’t be due to the length of the sync run alone. Here, 4.0.8 seems to be slower than 33.0.x, but at least it doesn’t freeze.

I’ve marked the approximate times in the copied logs when I noticed the freeze. Unfortunately, the file structure also contains information for which I had to sign non-disclosure agreements, so it’s difficult to share the log files.:face_with_peeking_eye:

However, the freeze always ends at the exact same moment that the end of the sync run is logged in the client logs.

For my test environment, I use much less data. So, the size of the index might have an impact.

I don’t know if it is feasible to clean the file names. Even with cleaning, it is perhaps better to just send them upon request to the involved Nextcloud developers and not sharing them publicly (in case your cleaning missed something).

I don’t know if there are others here, or perhaps existing reports situations, that you can join and perhaps some can share logs more easily.

Hello, I’m experiencing the same issue. We have two Nextcloud platforms, one with 1TB and the other with 30TB, and the same problem persists, but only on Windows 11 clients (VFS). On macOS, this issue does not occur.

On my side as well, there are no logs highlighting the problem. In addition to freezing Explorer, my client disconnects on its own and then reconnects automatically.

I hope Nextcloud resolves this issue, as it is really blocking.

If you are several, then it might be a good idea for a github-report. It is however important to figure out a scenario to reproduce your issues. Except for the VFS and Windows 11, is it just the number of files, or other things as well (use of high-performance backend, server config etc.). Along with all the other findings you already have. Please leave a link here to follow up.

Hi, thanks I opened the issue on git-hub, here is the link to reach it

Thanks for opening the bug report. Since the issues might not be exactly the same (my Explorer doesn’t freeze completely, just for 30–40 seconds), I’m not sure if I should add my information to your report.

It would be interesting to know if your computers eventually respond again once the sync process is complete—which, with 30 TB, naturally takes much longer than it does for me with just under 1 TB.

However, I’ve just created a cleaned-up client log that I could contribute to the bug report.

Hi, in both cases the synchronization after the block completes successfully. The issue on my side is that Nextcloud goes offline on its own, so it stops syncing. In addition, this causes data loss and the synchronization then has to start again from scratch.

If you find the symptoms to be a bit different, a separate report is probably better. If the underlying issue is the same, the developers still can mark it as duplicate. You can mention the other report, and say in which way there are the same and in which way they differ. There is more often topics, where people just keep large threads with similar symptoms. And then to debug in parallel 5 different issues in the same topic is not helpful.

Okay. Thanks for the tip. I’ve created a second report. Actually, there’s a third one as well, which also describes similar issues with a large folder in Windows 11 VFS, but with slightly different symptoms.