Repository: nextcloud/desktop (C++)

Issue:
Sync fails: "too many open files" (original matter addressed but bulk upload introduced another w/ similar symptoms)
Hi, sync seems broken on my laptop. It fails with a series of "Too many open files" messages in the client. It stops for a moment and then restarts the whole process from beginning.

![screenshot](https://i.imgur.com/e6SdH8u.png)

I don't know if this error is related to desktop client or machine where it runs.

Any idea? Thanks

### Client configuration
Client version: 2.5.1 git (rev. b37cbe)

Operating system: Arch Linux

OS language: Italian

Qt version used by client package (Linux only, see also Settings dialog): 5.12.0

Client package (From Nextcloud or distro) (Linux only): community/nextcloud-client 2.5.1-2

### Server configuration
Operating system: Arch Linux

Web server: apache 2.4.37

Database: mariadb 10.1.37

PHP version: 7.3.0

Nextcloud version: 15.0.2

### Logs

1. Client logfile: https://cuteworks.it/nextcloud/s/KzWbigWWwNjRk2n

2. Web server error log: no errors

3. Server logfile: no errors


[Bug]: Windows Desktop Client UI completely unresponsive during preparation for sync
### ⚠️ Before submitting, please verify the following: ⚠️

- [X] This is a **bug**, not a question or a configuration issue.
- [X] This issue is **not** already reported on Github (I've searched it).
- [X] Nextcloud Server and Desktop Client are **up to date**. See [Server Maintenance and Release Schedule](https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule) and [Desktop Releases](https://nextcloud.com/install/#install-clients) for supported versions.
- [X] I agree to follow Nextcloud's [Code of Conduct](https://nextcloud.com/contribute/code-of-conduct/)

### Bug description

The UI of the client is unresponsive (see screenshots).
Sometimes, when the connection times out (indicated by a grey symbol and a timeout error message), the UI is normally responsive again.
I have to wait for several minutes until the UI pops up after I once click on the nextcloud icon when it is in either state "preparing for sync" or "Waiting to start syncing".

I even tried to delete all nextcloud database files from the folder to be synced, i.e. `.sync_2e9e607b5567.db` and `*.db-wal` and so on PLUS deleted the nextcloud cache in AppData, restarted the app and it freezes again.
Interestingly, a TestFolder with just one very small txt file (containing only "test" as text and the file itself called "test.txt") worked immediately and was successfully synced to the server. The Folder I actually want to sync contains `1.477.544 Files` in `232.580 Folders`, and is only `84,3 GB (90 590 769 152 bytes)` in size. This should not be an issue, especially because 9/10 from that should be ignored by the ignore list of the nextcloud client. I had this folder already completely synced in my old nextcloud server instance but wanted to migrate to a new one, therefore a wanted to freshly sync the folder and uninstalled and reinstalled the client completely.

Also I observed, that the Windows explorer itself is frozen by nextcloud when it tries to prepare for sync. As soon as I kill nextcloud, the Windows Explorer is responsive again.

EDIT: I deleted half of the files, in the hope to speed up the process a little bit, and it now worked after 1h of preparation for sync the files are now indeed syncing and the UI is responsive again. Therefore: The UI seems to be responsive while syncing, but the initial process when a new Folder is added to the list ("preparation for sync") seems to be implemented very inefficiently.

### Steps to reproduce

1. Installed nextcloud client on my Windows 10 PC
2. Added connection to my server with https and login credentials
3. Skip folder sync to add individual folders later
4. Added folder sync for one specific folder on the Windows host and one specific folder on the nextcloud server
5. The UI freezes, but the Task Manager indicates that the client is working in the background (see screenshots), due to high CPU usage and Disk operations.
6. Clicking (either right or left click) on the nextcloud icon in the hidden icons menu of the Windows Search Bar does not respond in any way, but after several minutes, the window pops up. The window itself does not respond either.
7. Sometimes a server timeout happens. Then the UI is responsive again until a re-login freezes the UI again.

### Expected behavior

UI should be always responsive, no matter how busy the thread in the background currently is.
UI should be implemented in a separate thread than other tasks.

### Which files are affected by this bug

no files

### Operating system

Windows

### Which version of the operating system you are running.

Windows 10, windows-10.0.19044

### Package

Other

### Nextcloud Server version

24.0.6

### Nextcloud Desktop Client version

3.6.0

### 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?

- [X] Default internal user-backend
- [ ] LDAP/ Active Directory
- [ ] SSO - SAML
- [ ] Other

### Nextcloud Server logs

```shell
No errors related to the syncing process (only login token errors when I manually logged in to the webservice).
```


### Additional info

![nextcloud_ui_freeze_1](https://user-images.githubusercontent.com/13003800/195073677-91a9c569-9b1e-4b7e-ad62-1ff5d72a4691.png)
![nextcloud_ui_freeze_2](https://user-images.githubusercontent.com/13003800/195073680-4985e02d-476f-454d-ade6-6b8f4b5c21e9.png)
![nextcloud_ui_freeze_3](https://user-images.githubusercontent.com/13003800/195073682-19170bd7-e6cd-4364-92fd-cd4e30ba5450.png)
![nextcloud_ui_freeze_responsive](https://user-images.githubusercontent.com/13003800/195073684-231de18c-88b4-47b9-9a86-4d2de978482a.png)
![nextcloud_ui_freeze_responsive_2](https://user-images.githubusercontent.com/13003800/195073686-a9c1f856-119f-4d28-8502-2e0f89e4f1aa.png)


Download debug-archive.zip: https://www.file-upload.net/download-15019081/nextcloud_client_debug-archive.zip.html
[Bug]: Unknown error and network error 99 when syncing .vscode extensions
### ⚠️ Before submitting, please verify the following: ⚠️

- [X] This is a **bug**, not a question or a configuration issue.
- [X] This issue is **not** already reported on Github (I've searched it).
- [X] Nextcloud Server and Desktop Client are **up to date**. See [Server Maintenance and Release Schedule](https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule) and [Desktop Releases](https://nextcloud.com/install/#install-clients) for supported versions.
- [X] I agree to follow Nextcloud's [Code of Conduct](https://nextcloud.com/contribute/code-of-conduct/)

### Bug description

When I try to sync the `.vscode` extension folder with the Nextcloud Client 3.6.4 (previous versions had the same problems) I get the messages `unknown error` and `network error: 99`. Then the Nextcloud Client is freezing and then crashing.

### Steps to reproduce

1. Install VS Code on Windows
2. Install some extensions
3. Try to sync the folder under C:\Users\%username%\.vscode


### Expected behavior

The sync should not fail.

### Which files are affected by this bug

nearly all files

### Operating system

Windows

### Which version of the operating system you are running.

Windows 11 21H2

### Package

Appimage

### Nextcloud Server version

25.0.3

### Nextcloud Desktop Client version

3.6.4

### 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?

- [ ] Default internal user-backend
- [ ] LDAP/ Active Directory
- [ ] SSO - SAML
- [ ] Other

### Nextcloud Server logs

```shell
The logs are in the `debug.zip`, else I get this error when submitting this issue `There was an error creating your issue: body is too long (maximum is 65536 characters). `
```


### Additional info

I'm using this Docker Compose file: 
[docker-compose.yml.txt](https://github.com/nextcloud/desktop/files/10464546/docker-compose.yml.txt)

Here the client logs:
[debug.zip](https://github.com/nextcloud/desktop/files/10464550/debug.zip)

Nextcloud is behind a Haproxy, but I tried also with a direct connection to the Docker container. Same result.

Here some screenshots:

![nextcloud-1](https://user-images.githubusercontent.com/12592765/213655255-c1a1ae91-dfde-4d4b-b27d-22610e03eda8.jpg)

![nextcloud-2](https://user-images.githubusercontent.com/12592765/213655340-0fbb3968-0cce-4b6f-b019-cad0b9083624.jpg)

[Bug]: Computed md5 hash is incorrect
### ⚠️ Before submitting, please verify the following: ⚠️

- [X] This is a **bug**, not a question or a configuration issue.
- [X] This issue is **not** already reported on Github (I've searched it).
- [X] Nextcloud Server and Desktop Client are **up to date**. See [Server Maintenance and Release Schedule](https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule) and [Desktop Releases](https://nextcloud.com/install/#install-clients) for supported versions.
- [X] I agree to follow Nextcloud's [Code of Conduct](https://nextcloud.com/contribute/code-of-conduct/)

### Bug description

Error "Computed md5 hash is incorrect" thrown in Log, while sync files with Nextcloud Desktop App.

### Steps to reproduce

1. Sync files with Nextcloud Desktop App
2. Error happened

### Expected behavior

All files synced successfully without any error.

### Which files are affected by this bug

No Info

### Operating system

Windows

### Which version of the operating system you are running.

Windows 10

### Package

Appimage

### Nextcloud Server version

28.0.3

### Nextcloud Desktop Client version

3.9.2

### 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?

- [ ] Default internal user-backend
- [X] LDAP/ Active Directory
- [ ] SSO - SAML
- [ ] Other

### Nextcloud Server logs

```shell
{
  "reqId": "besBygdQGUBcpR9EWcvo",
  "level": 3,
  "time": "2024-03-05T14:22:44+07:00",
  "remoteAddr": "x.x.x.x",
  "user": "e2d350ce-6ebf-103d-84cd-addc165358a8",
  "app": "no app in context",
  "method": "POST",
  "url": "/remote.php/dav/bulk",
  "message": "Computed md5 hash is incorrect.",
  "userAgent": "Mozilla/5.0 (Windows) mirall/3.9.2stable-Win64 (build 20230808) (Nextcloud, windows-10.0.19045 ClientArchitecture: x86_64 OsArchitecture: x86_64)",
  "version": "28.0.3.2",
  "data": [],
  "id": "65e7e7f79d32c"
}
```


### Additional info

_No response_
[Bug]: Nextcloud Client makes Windows Explorer non-responsive when numerous sync errors occur
### ⚠️ Before submitting, please verify the following: ⚠️

- [x] This is a **bug**, not a question or a configuration issue.
- [x] This issue is **not** already reported on Github (I've searched it).
- [x] Nextcloud Server and Desktop Client are **up to date**. See [Server Maintenance and Release Schedule](https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule) and [Desktop Releases](https://nextcloud.com/install/#install-clients) for supported versions.
- [x] I agree to follow Nextcloud's [Code of Conduct](https://nextcloud.com/contribute/code-of-conduct/)

### Bug description

The immediate issue is that the Nextcloud Client is causing Windows Explorer to be non-responsive (freeze) that then crashes. This only occurs when there are numerous sync errors. By Windows Explorer, I really mean the taskbar, since the desktop, taskbar, and actual Windows Explorer are all connected.

When this freezing behavior occurs, a noticeable side-effect is that the Nextcloud notification icon becomes invisible (see image below). _Please don't tell me the tray is re-rendering infinitely (tell me)._ As you see below, that invisible slot is actually for Nextcloud.

![Image](https://github.com/user-attachments/assets/68c336c1-4198-43ec-a378-34bc1f5213de)

Another side-effect is that the Nextcloud UI is extremely slow, unresponsive, and has a very slow UI feedback (~3-5 sec feedback time). 

This seems to only happen when there are a lot of errors and the server is still trying to provide sync updates. For some reason, I am getting weird 401 or 499 errors but that's not the problem. 
![Image](https://github.com/user-attachments/assets/8091babb-b05b-4d2b-9986-5026889b661a)

_I guess_ once Nextcloud stops adding error elements or whatever, it goes back to its usual refreshing flickering madness. If even more errors occur, well. We're back to square one. _Fun fact: It also crashes Windows Snippet Tool when trying to record it_ 😂

https://github.com/user-attachments/assets/12eae881-18bc-4d13-b7d6-b121d5bc9f6e

Pausing the sync immediately stops this madness as you will see in the logs.

LOGS:
[logs.txt](https://github.com/user-attachments/files/18161288/anonymized_logs.txt)
[logs1.txt](https://github.com/user-attachments/files/18161289/anonymized_logs_1.txt)

(I am going to double check if this still exists with the latest Desktop Client update 3.15.1 momentarily)


### Steps to reproduce

1. Bulk upload files (let's say 100+).
2. After a few moments, observe state of the taskbar.


### Expected behavior

Desktop client does not cause Windows Explorer to freeze, ultimately leading to a crash.

### Which files are affected by this bug

NA

### Operating system

Windows

### Which version of the operating system you are running.

Windows 11 23H2 Build 22631.4317

### Package

Official Windows MSI

### Nextcloud Server version

30.0.2

### Nextcloud Desktop Client version

3.15.0

### Is this bug present after an update or on a fresh install?

Updated from a minor version (ex. 3.4.2 to 3.4.4)

### Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

### Are you using an external user-backend?

- [x] Default internal user-backend
- [ ] LDAP/ Active Directory
- [ ] SSO - SAML
- [ ] Other

### Nextcloud Server logs

```shell

```

### Additional info

Using virtual files in a local folder, total file upload was around 10 GB.

This may be related to #6749.
[Bug]: client counting wrong
### ⚠️ Before submitting, please verify the following: ⚠️

- [x] This is a **bug**, not a question or a configuration issue.
- [x] This issue is **not** already reported on Github (I've searched it).
- [x] Nextcloud Server and Desktop Client are **up to date**. See [Server Maintenance and Release Schedule](https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule) and [Desktop Releases](https://nextcloud.com/install/#install-clients) for supported versions.
- [x] I agree to follow Nextcloud's [Code of Conduct](https://nextcloud.com/contribute/code-of-conduct/)

### Bug description

whilst syncing a folder structure with many smaller files the status display looks awkward:

![Image](https://github.com/user-attachments/assets/dac46f2b-9817-44f5-9303-8eb74775ec57)

initially the display makes sense, e.g. saying "140MB von 248MB" in my case using German UI but after a while it changes to what's in the screenshot attached.
when the screen is refreshed, e.g. by clicking on settings screen and back the count is back to normal
Please note: 
- the structure was moved in one go into the sync'd folder on the Win PC. sync client picked up the change and started syncing as expected.
- folder structure/files might change during the sync, which usually doesn't cause issues, changes are picked up straight after the sync is done, causing a new sync.

### Steps to reproduce

- set up an empty sync folder
- let it sync
- move a directory structure in with many sub-directories and small files (in my example that almost 9k files structured in 1027 (sub-)directories

### Expected behavior

counts displayed should be accurate

### Which files are affected by this bug

.

### Operating system

Windows

### Which version of the operating system you are running.

WIndows 10

### Package

Official Windows MSI

### Nextcloud Server version

29.0.9

### Nextcloud Desktop Client version

3.15.1

### Is this bug present after an update or on a fresh install?

Updated from a minor version (ex. 3.4.2 to 3.4.4)

### Are you using the Nextcloud Server Encryption module?

Encryption is Enabled

### Are you using an external user-backend?

- [ ] Default internal user-backend
- [ ] LDAP/ Active Directory
- [ ] SSO - SAML
- [ ] Other

### Nextcloud Server logs

```shell

```

### Additional info

_No response_
[Bug]: NC Desktop-Client 3.16.2 (Windows) Upload hangs during synchronization, freezes......
### ⚠️ Before submitting, please verify the following: ⚠️

- [x] This is a **bug**, not a question or a configuration issue.
- [x] This issue is **not** already reported on Github (I've searched it).
- [x] Nextcloud Server and Desktop Client are **up to date**. See [Server Maintenance and Release Schedule](https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule) and [Desktop Releases](https://nextcloud.com/install/#install-clients) for supported versions.
- [x] I agree to follow Nextcloud's [Code of Conduct](https://nextcloud.com/contribute/code-of-conduct/)

### Bug description

The Windows client should synchronize a directory with subdirectories containing small and large files, in total approx. 200GB with the cloud.

If only a few files need to be synchronized, this works. However, if there are larger differences that need to be synchronized, the upload (always only the upload) stops.
In the "Settings" window, I see how the data transfer rate is continuously decreasing, close to zero.

I have seen that there are many such issues, most of them should be fixed with newer versions.

Upload and download bandwidths are not limited. If I set this to “Limit automatically”, the client crashes completely
I have seen that there are many such issues, most of them should be fixed with newer versions.

It is possible that there are file names with more than 256 characters including the path - but this problem is supposed to be fixed too....

Upload and download bandwidths are not limited. If I set this to “Limit automatically”, the client crashes completely
...

I have been observing this error for several versions now, and it seems to occur only on this one device.

Since the other devices sync an internal hard drive with the cloud and this client uses a network drive, I also installed a hard drive for it - and reinstalled the Nextcloud client (including deleting files in AppData and the indexes) without any improvement in behavior.


### Steps to reproduce

1. Start the Nextcloud client.
2. The client apparently begins the synchronization.
3. The synchronization stops.
4. I press "Restart synchronization."
5. I'm back to step 2, then 3... and so on.

### Expected behavior

The client should synchronize all files.
...


### Which files are affected by this bug

*.jpg / *mp3 / 

### Operating system

Windows

### Which version of the operating system you are running.

Windows 10 22H2

### Package

Official Windows MSI

### Nextcloud Server version

31.0.2

### Nextcloud Desktop Client version

3.16.2

### Is this bug present after an update or on a fresh install?

Updated from a minor version (ex. 3.4.2 to 3.4.4)

### Are you using the Nextcloud Server Encryption module?

Encryption is Enabled

### Are you using an external user-backend?

- [ ] Default internal user-backend
- [ ] LDAP/ Active Directory
- [ ] SSO - SAML
- [ ] Other

### Nextcloud Server logs

```shell
An excerpt from the client log:

2025-03-26 17:56:08:290 [ warning nextcloud.sync.propagator C:\Users\User\AppData\Local\Temp\windows-29332\client-building\desktop\src\libsync\owncloudpropagator.cpp:583 ]:	WARNING:  Job within a removed directory?  This should not happen! "02 Clientseite/66 hbc66/01 SofortUpload/Download/2025/03/1016094002.jpg" CSyncEnums::CSYNC_INSTRUCTION_NEW
2025-03-26 17:56:08:290 [ warning nextcloud.sync.propagator C:\Users\User\AppData\Local\Temp\windows-29332\client-building\desktop\src\libsync\owncloudpropagator.cpp:583 ]:	WARNING:  Job within a removed directory?  This should not happen! "02 Clientseite/66 hbc66/01 SofortUpload/Download/2025/03/1144460559.jpg" CSyncEnums::CSYNC_INSTRUCTION_NEW
2025-03-26 17:56:08:290 [ warning nextcloud.sync.propagator C:\Users\User\AppData\Local\Temp\windows-29332\client-building\desktop\src\libsync\owncloudpropagator.cpp:583 ]:	WARNING:  Job within a removed directory?  This should not happen! "02 Clientseite/66 hbc66/01 SofortUpload/Download/2025/03/1157705011.jpg" CSyncEnums::CSYNC_INSTRUCTION_NEW


---
2025-03-26 17:56:08:308 [ warning nextcloud.sync.propagator.directory C:\Users\User\AppData\Local\Temp\windows-29332\client-building\desktop\src\libsync\owncloudpropagator.cpp:1272 ]:	Useless task found for file ".sync-exclude.lst" instruction CSyncEnums::CSYNC_INSTRUCTION_NEW
2025-03-26 17:56:08:311 [ warning nextcloud.sync.propagator.directory C:\Users\User\AppData\Local\Temp\windows-29332\client-building\desktop\src\libsync\owncloudpropagator.cpp:1272 ]:	Useless task found for file "02 Clientseite/66 hbc66/01 SofortUpload/Camera/2025/03/PXL_20250301_101132417.jpg" instruction CSyncEnums::CSYNC_INSTRUCTION_NEW
2025-03-26 17:56:08:311 [ warning nextcloud.sync.propagator.directory C:\Users\User\AppData\Local\Temp\windows-29332\client-building\desktop\src\libsync\owncloudpropagator.cpp:1272 ]:	Useless task found for file "02 Clientseite/66 hbc66/01 SofortUpload/Camera/2025/03/PXL_20250301_101135693.jpg" instruction CSyncEnums::CSYNC_INSTRUCTION_NEW
2025-03-26 17:56:08:311 [ warning nextcloud.sync.propagator.directory C:\Users\User\AppData\Local\Temp\windows-29332\client-building\desktop\src\libsync\owncloudpropagator.cpp:1272 ]:	Useless task found for file "02 Clientseite/66 hbc66/01 SofortUpload/Camera/2025/03/PXL_20250301_101138465.jpg" instruction CSyncEnums::CSYNC_INSTRUCTION_NEW

---

2025-03-26 17:56:08:351 [ info nextcloud.sync.propagator.bulkupload C:\Users\User\AppData\Local\Temp\windows-29332\client-building\desktop\src\libsync\bulkpropagatorjob.cpp:189 ]:	"/02 Clientseite/66 hbc66/03 Transport_hb/21 Bilder Profil/00079.png" transmission checksum "1b8c957b563e7a7c6e4ce05773e6e5aa" "E:/Nextcloud-Lokalverzeichnis/MyCloud/02 Clientseite/66 hbc66/03 Transport_hb/21 Bilder Profil/00079.png"
2025-03-26 17:56:08:353 [ info nextcloud.sync.propagator.bulkupload C:\Users\User\AppData\Local\Temp\windows-29332\client-building\desktop\src\libsync\bulkpropagatorjob.cpp:189 ]:	"/02 Clientseite/66 hbc66/01 SofortUpload/Pictures/2025/03/Screenshots/Screenshot_20250312-072322.png" transmission checksum "d7798b97a2a897564fcb25f9d5b31636" "E:/Nextcloud-Lokalverzeichnis/Mycloud/02 Clientseite/66 hbc66/01 SofortUpload/Pictures/2025/03/Screenshots/Screenshot_20250312-072322.png"
2025-03-26 17:56:08:353 [ info nextcloud.sync.propagator.bulkupload C:\Users\User\AppData\Local\Temp\windows-29332\client-building\desktop\src\libsync\bulkpropagatorjob.cpp:189 ]:	"/02 Clientseite/66 hbc66/03 Transport_hb/21 Bilder Profil/00066.jpeg" transmission checksum "7644dbe342c37c9c07c31bf41ea725ac" "E:/Nextcloud-Lokalverzeichnis/Mycloud/02 Clientseite/66 hbc66/03 Transport_hb/21 Bilder Profil/00066.jpeg"
2025-03-26 17:56:08:353 [ info nextcloud.sync.propagator.bulkupload C:\Users\User\AppData\Local\Temp\windows-29332\client-building\desktop\src\libsync\bulkpropagatorjob.cpp:189 ]:	"/02 Clientseite/66 hbc66/03 Transport_hb/21 Bilder Profil/00072.jpeg" transmission checksum "a4c542fa363c62dda29b19c45b2eb827" "E:/Nextcloud-Lokalverzeichnis/Mycloud/02 Clientseite/66 hbc66/03 Transport_hb/21 Bilder Profil/00072.jpeg"
2025-03-26 17:56:08:353 [ info nextcloud.sync.propagator.bulkupload C:\Users\User\AppData\Local\Temp\windows-29332\client-building\desktop\src\libsync\bulkpropagatorjob.cpp:189 ]:	"/02 Clientseite/66 hbc66/03 Transport_hb/21 Bilder Profil/00086.jpg" transmission checksum "bbf2c6f25e29e4462de49b965baf5f85" "E:/Nextcloud-Lokalverzeichnis/Mycloud/02 Clientseite/66 hbc66/03 Transport_hb/21 Bilder Profil/00086.jpg"
2025-03-26 17:56:08:353 [ info nextcloud.sync.propagator.bulkupload C:\Users\User\AppData\Local\Temp\windows-29332\client-building\desktop\src\libsync\bulkpropagatorjob.cpp:189 ]:	"/02 Clientseite/66 hbc66/03 Transport_hb/21 Bilder Profil/00088.png" transmission checksum "dec5648199add6b773d80d0790af309a" "E:/Nextcloud-Lokalverzeichnis/Mycloud/02 Clientseite/66 hbc66/03 Transport_hb/21 Bilder Profil/00088.png"
2025-03-26 17:56:08:353 [ info nextcloud.sync.propagator.bulkupload C:\Users\User\AppData\Local\Temp\windows-29332\client-building\desktop\src\libsync\bulkpropagatorjob.cpp:189 ]:	"/02 Clientseite/66 hbc66/03 Transport_hb/21 Bilder Profil/00077.png" transmission checksum "b4493dc19c9b9d9936b65508749c08ac" "E:/Nextcloud-Lokalverzeichnis/Mycloud/02 Clientseite/66 hbc66/03 Transport_hb/21 Bilder Profil/00077.png"
2025-03-26 17:56:08:359 [ info nextcloud.sync.accessmanager C:\Users\User\AppData\Local\Temp\windows-29332\client-building\desktop\src\libsync\accessmanager.cpp:75 ]:	4 "" "https://Mycloud/remote.php/dav/bulk" has X-Request-ID "72726c6a-f910-4025-a52b-efb54e415cc9"
2025-03-26 17:56:08:359 [ info nextcloud.sync.networkjob C:\Users\User\AppData\Local\Temp\windows-29332\client-building\desktop\src\libsync\abstractnetworkjob.cpp:364 ]:	OCC::PutMultiFileJob created for "https://Mycloud" + "" "OCC::BulkPropagatorJob"
```

### Additional info

_No response_


Discussion: I have the same issue on my Linux system and it seems to be only triggered when I process larger numbers of very small files, e.g., small pictures or git-repositories. Client 2.3.3 works, so it has to be a problem that was introduced with version 2.5.x. I also tried the dev-branch for the nextcloud-client -> same issue.

![20190109_too-many-files-open---2](https://user-images.githubusercontent.com/32929969/51800029-d095ea00-2229-11e9-8a63-69fb8bb36d9e.png)


**Client configuration**

Client version: 2.5.1
Operating system: Xubuntu 18.04 LTS
OS language: English

**Server configuration**
Managed Nextcloud (Owncube.com) - Version: 15.0.0

**Logs**
Web server error log: to my knowledge -> no errors
Server logfile: to my knowledge -> no errors
Client logfile:
[20190109_1148_owncloud.log.0.gz](https://github.com/nextcloud/desktop/files/2799961/20190109_1148_owncloud.log.0.gz)
[20190109_1200_owncloud.log.0.gz](https://github.com/nextcloud/desktop/files/2799963/20190109_1200_owncloud.log.0.gz)
[20190109_1200_owncloud.log.1.gz](https://github.com/nextcloud/desktop/files/2799964/20190109_1200_owncloud.log.1.gz)
[20190109_1212_owncloud.log.0.gz](https://github.com/nextcloud/desktop/files/2799965/20190109_1212_owncloud.log.0.gz)
[20190109_1213_owncloud.log.0.gz](https://github.com/nextcloud/desktop/files/2799966/20190109_1213_owncloud.log.0.gz)


Let me know whether you need more info for debugging purposes!

Could it be this crashes on Windows machines? When we try to sync large numbers of new files (2k+) it just crashes after a while.
Yes, I was also able to reproduce the same results on a virtual machine with Win 7 and the 2.5.1 client for Windows. Unfortunately, I cannot provide logs at the moment. But the Linux logs should already help the dev team once they take care of this issue.

@GieltjE Could you maybe also upload logfiles to make it easier for the dev team to fix our issue?
The client log just logs sync complete, a friend of mine will hopefully post the windows logs soon.

We also noticed that it happens on lots of small files, when the files get bigger it doesn't crash every time.

@bleidingGOE, the windows logbook should provide the most information
Confirming the "too many files" error on Linux Mint. However the client does not restart but instead either dies without notification or causes the operating system to freeze.
As a workaround one can disable sync for the causing folders, so that at least all others get synced.
It has been 2 month since @gcala  opened the issue - the dev team did not even respond despite us providing several logs and precise descriptions. Is nextcloud still actively developed?
According to github there are enough commits in the server code, but the desktop client just seems to be getting updated translations....
We can't even force the clients to update to new versions resulting in major parts of the userbase running outdated crap....
Hi All,

Note that Github isn't a support portal. We provide support to customers only. Github is our developer platform. If you're not a customer you can ask the community for help on help.nextcloud.com.

We of course try to deal with bugs as quick as we can, but it can take time as we have lots of other things on our plate. You are welcome to contribute to this free and open source product, to submit patches that fix bugs for example. We try to respond quickly to pull request from contributors.

Have a great day!
Camila
I ran into this issue today after a distro upgrade. The version I was running prior to the upgrade was https://github.com/nextcloud/desktop/commit/57bc7918d7b0650c116f3512787f7677d4e5ab17 . I am running that version again, and it is not affected by this REGRESSION.

If anybody cares enough about this problem to work on it, I'd suggest bisecting with that commit as a starting point.

@camilasan : your response comes off as hostile and rude. Not a particularly good way to encourage people to help in this project. I mean after all, how dare people want to ASSIST the project by reporting and discussing bugs in lieu of supporting it financially.
Hello!

I also encountered the problem. It's not a bug within nextcloud, rather a system feature limiting the number of open files. E.g. see [https://easyengine.io/tutorials/linux/increase-open-files-limit/](https://easyengine.io/tutorials/linux/increase-open-files-limit/) for a fix. 

The issue can be closed.
It's not a Linux only problem, we only use Windows clients.
I already tried this on my ubuntu 18.04 LTS - did not work. Moreover, the problem also occurs on Windows.

On 27 June 2019 10:00:14 CEST, JM Joseph <notifications@github.com> wrote:
>Hello!
>
>I also encountered the problem. It's not a bug within nextcloud, rather
>a system feature limiting the number of open files. E.g. see
>[https://easyengine.io/tutorials/linux/increase-open-files-limit/](https://easyengine.io/tutorials/linux/increase-open-files-limit/)
>for a fix. 
>
>The issue can be closed.
>
>-- 
>You are receiving this because you were mentioned.
>Reply to this email directly or view it on GitHub:
>https://github.com/nextcloud/desktop/issues/1035#issuecomment-506237981

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Experiencing the same problem with 2.6.1 on the following distros:

Ubuntu 18.04, 19.10
Ubuntu Budgie 18.04, 19.10
Trisquel 8, 9
Debian 9, 10
Parabola
Windows 8, 8.1, 10
Linux Mint 18, 19
OpenSuSE Tumbleweed


sadly, changing ulimit does not work.

The problem does not occur on 2.3.1

Photo and videofolder is 900 GB
+1 on Ubuntu 19.10. 

I'm trying to sync a 25GB photo folder. 'Too many open files', 100% CPU and application freeze. I tried it with or without hidden files.

Seems like a huge issue and I'm perplexed that this is not taken seriously and still not fixed.
> Seems like a huge issue and I'm perplexed that this is not taken seriously and still not fixed.

I agree, I've asked in the official Nextcloud channels but I have not even gotten a reply there. 
Still no attention from the developers?
I am strongly considering stop using Nextcloud both for private use and corporate, this issue is starting to become a plague for both usecases.
I added some appropriate labels. Hopefully some developer can take a look at this, soon.

Just to get the impact correctly: This is completely preventing the concerning files to be ever synced and does not slowly disappear after more and more files got synced, correct?
Thanks for adding the labels! 
Regarding your question: No, it does not slowly disappear - I left it running for several days without any progress.
Thanks for clarifying @bleidingGOE. That make the issue rather severe in cases where it appears.
It's a bit embarrassing that Nextcloud is more focused on developing sub-standard apps that there already exist viable open source solutions for instead of making sure that foundational pieces such as folder synchronization is working properly. This bug has been open for over a year. I won't be recommending this software in the future to corporate clients.
@mpass3 : in all fairness (and I have no ties to nextcloud from a development perspective, just as a user), desktop synchronization really isn't a primary feature of nextcloud, and in many/most cases, the concept of synchronization is too confusing to actually use safely/reliably. I.e., change a file in both local and remote filesystem... Which version wins? The fact that there is no INTUITIVE answer to this means that the concept is flawed. In fact, this very problem is the reason why tools like git exist, and you would never hand that tool to a corporate paper pusher.

For corporate use, what you really want is to mount the nextcloud data into the local filesystem. You can use WebDAV for that. Let the end user decide on what files to overwrite.
@lbdroid : I absolutely disagree. Even for large corporations, a client synchronization feature is essential. The issue of "which file should I keep" has been solved by Dropbox, GDrive, Syncthing, and so many other projects.

Moreover, based on your suggestion I tried to use my Nextcloud on Ubuntu 18.04 LTS with different WebDAV approaches -> They are horribly slow. No way to use this productively. Once you start googling the "slow WebDAV" issue they recommend using the client, which leads us back to this issue here.
Can we please keep the discussion here on topic? Feel free to continue in the forum, you may post a link to a that here, so the others know where to continue. The topic you are talking about is definately worth disputing. But this is the issue tracker of nextcloud and this is a specific issue, so your comments are rather unrelated.
Again, I disagree. The relevance of an issue is determined by how many users it affects and whether it can easily be solved by using a different approach. Not clarifying the gravity of the issue is why it has not been addressed in more than a year.
Users affected may either use the emojis on the top to vote or if relevant add additional information in the comments. Also workarounds can of course be mentioned.

However, the last comments were discussing the relevance of having a working client. This is a meta discussion and could be applied to just any bug that is open here. So it is not specific for this issue.

> Not clarifying the gravity of the issue is why it has not been addressed in more than a year.

I guess lacking development power for the client is the main reason. If you have the skills and would like to contribute that would be very much appreciated.
Workaround for me (both changes required):
```
/etc/systemd/user.conf
DefaultLimitNOFILE=65536
```

```
/etc/security/limits.conf
*       soft    nofile  65536
*       hard    nofile  65536
```

And reboot.

Seems like the sync client isn't closing files as it's done with them. Normally fine, but after 1024 items it's this error. Is some code closing the FDs outside of a loop rather than inside?
> /etc/systemd/user.conf
> DefaultLimitNOFILE=65536
> /etc/security/limits.conf
> *       soft    nofile  65536
> *       hard    nofile  65536

Awesome for *nix variants but Windows doesn't have these settings.

Already tried that on Ubuntu 18.04 LTS - did not work for me.

On 23 April 2020 16:40:07 CEST, Michiel Hazelhof <notifications@github.com> wrote:
>> /etc/systemd/user.conf
>> DefaultLimitNOFILE=65536
>> /etc/security/limits.conf
>> *       soft    nofile  65536
>> *       hard    nofile  65536
>
>Awesome for *nix variants but Windows doesn't have these settings.
>
>
>-- 
>You are receiving this because you were mentioned.
>Reply to this email directly or view it on GitHub:
>https://github.com/nextcloud/desktop/issues/1035#issuecomment-618433696

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
> Workaround for me (both changes required):
> 
> ```
> /etc/systemd/user.conf
> DefaultLimitNOFILE=65536
> ```
> 
> ```
> /etc/security/limits.conf
> *       soft    nofile  65536
> *       hard    nofile  65536
> ```
> 
> And reboot.
> 
> Seems like the sync client isn't closing files as it's done with them. Normally fine, but after 1024 items it's this error. Is some code closing the FDs outside of a loop rather than inside?

Does not work as I wrote here: https://github.com/nextcloud/desktop/issues/1035#issuecomment-546673468


And I agree with the previous poster - bleidingGOE - that the sync feature is a essential part of Nextcloud and has always been. Defending the developers in this case does not make any sense at all, it is a bug and should be treated as such.


I got this bugs too,
I get back to v.2.3.3 and no more issue. 
@camilasan don’t want to open her eyes and see that since v.2.5 things went wrong with the sync engine on Linux / Windows and OS X. 
The v.2.6.4 get better results in many cases i use it on my linux but not on my windows. Impossible to get logs because the software hangs and is irresponsible. 

One year waiting bug
> Impossible to get logs because the software hangs and is irresponsible.

You should be able to write a log directly to a file, that will probably circumvent this problem.
This might be the same as #1769. It should have been fixed in #1899. Please read through #1769 whether it is the same issue and there is also a link to a daily AppImage build where that issue seems to be fixed. Maybe you also want to test that out, whether it fixes your problems as well.
Removing the increased fd limits and then using the AppImage to fetch a fresh Nextcloud mount succeeds. The problem appears to be fixed in the AppImage.
Nice, thanks for the feedback! I will leave this open until it lands in a stable release.
PR #1899 to fix this issue only made it into the 2.6-stable branch. I downloaded v3.0.1 yesterday and unfortunately the issue has reappeared. I'm just checking if reapplying the patch to 3.0.1 works, with then reopen PR against master
This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!
Commenting because this is not fixed.
This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!
Please provide the desktop client logs:
- Since 3.1: Under the "General" settings, you can click on "Create Debug Archive ..." to pick the location of where the desktop client will export the logs and the database to a zip file.
- On previous releases: Via the command line: nextcloud --logdebug --logwindow or nextcloud --logdebug --logfile log.txt (See also https://docs.nextcloud.com/desktop/3.1/troubleshooting.html#log-files)
Thanks!
Please at least explain how to work it around. I think this is an issue for everyone with enough files no matter the OS. 

This is what I get in OpenBSD when I start the GUI client:

```
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-ffuentes'
2021-06-20 17:47:44:789 [ critical  ]:	QNetworkInterface: could not create IPv6 socket (Too many open files)
2021-06-20 17:47:44:789 [ critical  ]:	QNetworkInterface: could not create IPv6 socket (Too many open files)
2021-06-20 17:47:44:789 [ critical  ]:	QNetworkInterface: could not create IPv6 socket (Too many open files)
2021-06-20 17:47:44:790 [ critical  ]:	QNetworkInterface: could not create IPv6 socket (Too many open files)

(nextcloud:95531): GLib-ERROR **: 17:47:46.792: Creating pipes for GWakeup: Too many open files
[1]    95531 trace trap (core dumped)  nextcloud

```

The application doesn't even stay open because it's gonna crash almost immediately so no one will be able to provide a log from the GUI. 

This is the whole log file I get https://ttm.sh/F7z.txt
This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!
I wrote this is an update on how to deal with the issue at least in OpenBSD but it might be useful for other OSs

https://ffuentes.sdf.org/unix/2021/06/23/nextcloud-client-in-openbsd.html
This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!
> I wrote this is an update on how to deal with the issue at least in OpenBSD but it might be useful for other OSs
> 
> https://ffuentes.sdf.org/unix/2021/06/23/nextcloud-client-in-openbsd.html

Thanks a lot for this.
We should really try to make good use of your blog post.
Do you mind if I try to share it ?
> Workaround for me (both changes required):
> 
> ```
> /etc/systemd/user.conf
> DefaultLimitNOFILE=65536
> ```
> 
> ```
> /etc/security/limits.conf
> *       soft    nofile  65536
> *       hard    nofile  65536
> ```
> 
> And reboot.
> 
> Seems like the sync client isn't closing files as it's done with them. Normally fine, but after 1024 items it's this error. Is some code closing the FDs outside of a loop rather than inside?

This workaround worked for me today on desktop client version 3.4.0 on Manjaro (manjaro-5.10.84-1-MANJARO).
Increasing the process max open files on Mac doesn't fully work around this issue. While the sync no longer fails early due to "too many open files", the sync slows to a crawl exponentially. By the time the client syncs files 1000+, it's taking several minutes for each 100-file chunk. The client also becomes sluggish and unresponsive. Please fix this bug and release file descriptors as files are done syncing.

Here are more details about my attempted workaround:

The default MacOS max process file open limit is `256`. I increased this to `4096` using the configuration below:

/Library/LaunchDaemons/limit.maxfiles.plist:
```
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
  <plist version="1.0">
    <dict>
      <key>Label</key>
      <string>limit.maxfiles</string>
      <key>ProgramArguments</key>
      <array>
        <string>launchctl</string>
        <string>limit</string>
        <string>maxfiles</string>
        <string>4096</string>
        <string>2147483647</string>
      </array>
      <key>RunAtLoad</key>
      <true/>
      <key>ServiceIPC</key>
      <false/>
    </dict>
  </plist>
```

```
# Secure file permissions
$ sudo chown root:wheel /Library/LaunchDaemons/limit.maxfiles.plist
# Load new settings
$ sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist
# Verify new settings
$ launchctl limit maxfiles
	maxfiles    4096           2147483647
```

You may need to restart the system for all processes to launch using the new settings.

You can monitor the open files using the Activity Monitor and see that files are never removed from the list during a sync. You can Pause/Restart sync and the open files will drop back down to the number open when you first launch the client, which is around `62`.

This is a screenshot of the client after syncing `1400` files:

![CleanShot 2022-01-01 at 13 44 50@2x](https://user-images.githubusercontent.com/430409/147857899-f892359b-c0dc-45c5-b80c-796d3a8a052e.png)

References:
https://neo4j.com/developer/kb/setting-max-open-file-limits-on-osx/
https://apple.stackexchange.com/questions/366187/why-does-setting-the-hard-limit-for-maxfiles-to-unlimited-using-launchctl-lim
I can reproduce this error on Linux and client version 3.4.1. The client is syncing against Nextcloud 23.
> > Workaround for me (both changes required):
> > ```
> > /etc/systemd/user.conf
> > DefaultLimitNOFILE=65536
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > ```
> > /etc/security/limits.conf
> > *       soft    nofile  65536
> > *       hard    nofile  65536
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > And reboot.
> > Seems like the sync client isn't closing files as it's done with them. Normally fine, but after 1024 items it's this error. Is some code closing the FDs outside of a loop rather than inside?
> 
> This workaround worked for me today on desktop client version 3.4.0 on Manjaro (manjaro-5.10.84-1-MANJARO).

I had issues moving 2.5Gb of Zotero files (research papers, pdfs htmls) becaue of the 'too many open files' error. I did the workaround above on my desktop, not on my server. All I have changed on my server are the user.ini and PHP.ini for upload size. I learned that from DBTech's videos.
Got excited because of the [Nextcloud Sync 2.0 brings 10x faster syncing](https://nextcloud.com/blog/nextcloud-sync-2-0-brings-10x-faster-syncing/) announcement. Syncing many small files has been the reason I can't use Nextcloud since I first evaluated it in 2016. So I decided to give it another try and benchmark the speed by syncing the [extracted contents of the Firefox source code](https://archive.mozilla.org/pub/firefox/releases/87.0/source/firefox-87.0.source.tar.xz).

Quite disappointed to be running into the "too many open files" issue. Seems like this issue should have been fixed before encouraging users to sync many small files: _"Users will benefit from instant availability of their files, even if they need to have large numbers of small files made available locally."_

![Screenshot 2022-01-16 at 13 30 48](https://user-images.githubusercontent.com/2871973/149660475-25122a31-51da-4c51-abc7-72b369225db3.png)
<img width="393" alt="Screenshot 2022-01-16 at 13 26 43" src="https://user-images.githubusercontent.com/2871973/149660478-96842c25-33f9-4339-a34a-a593b8b0ace3.png">

For me it happens on macOS Mojave 10.14.6. Initially syncing starts over after the "too many open files" error. But eventually syncing halts at 0B of 1,4 GB remaining with 100% CPU usage.

```
Nextcloud Desktop Client
Version 3.4.1 (macOS). For more information please click here.
Using virtual files plugin: suffix

osx-18.7.0
```

Update:

Tried syncing the same folder again on macOs 10.15.7 (osx-19.6.0) after applying the workaround suggested by @richardpeng.
```
launchctl limit maxfiles
	maxfiles    400000         400000  
```
Even with the raised limits, syncing gets stuck at `Syncing file 33056 of 305067`.

<img width="393" alt="Screenshot 2022-01-16 at 17 27 20" src="https://user-images.githubusercontent.com/2871973/149668865-f21bf0e2-8ddd-420b-a59a-4371648692e7.png">

Why does the Nextcloud Desktop client keep so many files open?
no fix yet???
@edraft My second solution was to upload everything through the browser the first time, then enable sync - works fine after that. I've been trying to switch to cron jobs instead of AJAX, maybe that is a factor here too? The first solution I used worked but it was slower than the browser I found.
> @edraft My second solution was to upload everything through the browser the first time, then enable sync - works fine after that. I've been trying to switch to cron jobs instead of AJAX, maybe that is a factor here too? The first solution I used worked but it was slower than the browser I found.

This is sadly not a solution for people with hundreds of gigabytes or terabytes of data.
I had the same issue on Pop!_OS 21.10, using NextCloud 3.4.1, but when I reverted back to NextCloud 3.3.6 I had no syncing issues.
Same Issue here on Arch, output of `nextcloud --version`:
`Nextcloud version 3.4.2git
Git revision b0791e51ceebef3295b30dc596c391c077af1924
Using Qt 5.15.2, built against Qt 5.15.2
Using Qt platform plugin 'xcb'
Using 'OpenSSL 1.1.1m  14 Dec 2021'
Running on Arch Linux, x86_64`.

I think this is an **extremely high severity** problem, just think about it, if you can't sync, the whole server, etc. is useless.
> > Workaround for me (both changes required):
> > ```
> > /etc/systemd/user.conf
> > DefaultLimitNOFILE=65536
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > ```
> > /etc/security/limits.conf
> > *       soft    nofile  65536
> > *       hard    nofile  65536
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > And reboot.
> > Seems like the sync client isn't closing files as it's done with them. Normally fine, but after 1024 items it's this error. Is some code closing the FDs outside of a loop rather than inside?
> 
> This workaround worked for me today on desktop client version 3.4.0 on Manjaro (manjaro-5.10.84-1-MANJARO).

This causes extreme unresponsiveness in my case, while sync is being stuck like this:
![image](https://user-images.githubusercontent.com/21132316/151711048-d981ea77-214c-4a3b-b16a-7f3d38c978cf.png)

The only sensible thing I can do now is that I use the Flatpak version and  [downgrade it as explained](https://docs.flatpak.org/en/latest/tips-and-tricks.html) . I downgraded it to version 3.3.6 as @bbartholdy explained.

Opening that many files will probably cause some load (depending on your system and number of files how bad it will be).

The workaround changes per system, as each system has it's own configuration.

In the end we need a proper solution (e.g. not opening so many files at one).
> Opening that many files will probably cause some load (depending on your system and number of files how bad it will be).
> 
> The workaround changes per system, as each system has it's own configuration.
> 
> In the end we need a proper solution (e.g. not opening so many files at one).

This is defenitely the way to go.
Megasync can handle a stupid amount of it this way.
I can sadly confirm that the issue still happens in version 3.4.2, syncing against Nextcloud 23. I'm on Arch Linux.
This is currently happening with Version 3.1.1 (Debian) Sync Client on NextCloud Server version 24.0.6

On Debian 11 with KDE.


Happening on Version 3.4.2 (Ubuntu) Sync Client on Nextcloud Hub 3 (25.0.1) on Ubuntu 22.04.1 LTS
Also happening with 3.6.2 app-image on Debian 11.5
3.4.2 Ubuntu 22.04.1
I did it myself - copied the files to the server and occ scan. 
It's just a semi-automatic application.
Also happening to me when reinstalling a new Nextcloud  :(
client 3.4.2 - Xubuntu 22.04 - Nextcloud 25.0.2
I solved this problem by adding the following line to the config.php file of the Nextcloud server :
`'bulkupload.enabled' => false,`
I have experienced this problem on several servers with different configuration and Nextcloud version 25.0.2.
The function is [an optimization for small files](https://docs.nextcloud.com/server/latest/developer_manual/client_apis/WebDAV/bulkupload.html), but the server still work pretty fast.
Still getting the "An exception occurred while executing a query: SQLSTATE[40001]: Serialisation failure 1213 Deadlock found when trying to get lock; try restarting transation)" when uploading thousands of tiny files at once.

But at least it functions now :)
> Still getting the "An exception occurred while executing a query: SQLSTATE[40001]: Serialisation failure 1213 Deadlock found when trying to get lock; try restarting transation)" when uploading thousands of tiny files at once.
> 
> But at least it functions now :)

I went backwards using all versions and found that 3.3.6 is the version that will work fast and without errors when you have 1000's of files to upload initially.  After seeding the initial files, you can switch back to the latest version and it will run fine.  I am convinced that the nextcloud team does not test new client versions with an initial upload of 1000's of files since there are so many reports about this problem over the last couple of years with no fix.  Using nextcloud with a steadily increasing number of files is no problem so they don't actually witness the issue in order to fix it.  For me, I had a problem with 72k text, image and pdf files until I installed the version above.
I'm also being bitten by this issue with NC client Version 3.4.2 on Pop!_OS 22.04 LTS with kernel pop-6.2.6-76060206-generic. NC Server is Hub 3 (25.0.5) running on Debian 11 via Docker. 

@suaudeau's suggestion appears to have subdued the error and permitted the files to sync, but I  also saw the  serialization failures noted by @GieltjE (mariadb is the backend).  

What seems weird to me is that the client was showing a too many files error when the open files didn't seem to come close to the limit (on both client and server).
> I solved this problem by adding the following line to the config.php file of the Nextcloud server : `'bulkupload.enabled' => false,` I have experienced this problem on several servers with different configuration and Nextcloud version 25.0.2. The function is [an optimization for small files](https://docs.nextcloud.com/server/latest/developer_manual/client_apis/WebDAV/bulkupload.html), but the server still work pretty fast.

This also solved the issue for me.
Just did a clean reinstall of NextCloud and was trying to re-upload everything back to the server via the desktop app on Linux and I ran into this error for the first time. Never had this issue before and I have done this several times.
The `bulkupload` seems to be problematic. After disabling it, not only the too-many open files issue is workarounded, nextcloud is also correctly synchronizing files that were mysteriously ignored.
```
I solved this problem by adding the following line to the config.php file of the Nextcloud server :
'bulkupload.enabled' => false,
```

I cannot find this statement in my configs. Would you @suaudeau be so kind and mention the precise location?

Thanks a lot in advance, Wolf  
> I cannot find this statement in my configs. Would you @suaudeau be so kind and mention the precise location?

You can add in in file : **<nextcloud_dir>/config/config.php** the line anywhere in the array :
```
<?php
$CONFIG = array (
...
  'bulkupload.enabled' => false,
...
);
```

Thanks for dummy-proof clarification - much required here...(;
Solution works for me.

Cheers,
Wolf
> > I cannot find this statement in my configs. Would you @suaudeau be so kind and mention the precise location?
> 
> You can add in in file : **<nextcloud_dir>/config/config.php** the line anywhere in the array :
> 
> ```
> <?php
> $CONFIG = array (
> ...
>   'bulkupload.enabled' => false,
> ...
> );
> ```

I don't see a ` <nextcloud_dir>/config/config.php` in my `nexcloud_dir` or in `~/.config/Nextcloud/`.

However, I do see a `~/.config/Nextcloud/nextcloud.cfg`.
Can we specify this option there?

If not, are we supposed to add a `config.php` file to a synchronized directory?
> I don't see a ` <nextcloud_dir>/config/config.php` in my `nexcloud_dir` or in `~/.config/Nextcloud/`.
> 
> However, I do see a `~/.config/Nextcloud/nextcloud.cfg`.
> Can we specify this option there?
> 
> If not, are we supposed to add a `config.php` file to a synchronized directory?

`~/.config/Nextcloud/nextcloud.cfg` is the configuration file of the client. 

This problem has to be solved on the server. Are you searching ` <nextcloud_dir>/config/config.php` on your server?
This issue is still persistent in NC client version 3.4.2.

Setting `bulkupload.enabled` to `false` (as described above) solves the problem.

```
Nextcloud version 3.4.2-1ubuntu1
Using Qt 5.15.12, built against Qt 5.15.2
Using Qt platform plugin 'xcb'
Using 'OpenSSL 3.0.2 15 Mar 2022'
Running on KDE neon 6.0, x86_64
```
> This issue is still persistent in NC client version 3.4.2.

@PhilippVerpoort This version is more than three years old, the recent version is 3.12.3.
> > This issue is still persistent in NC client version 3.4.2.
> 
> @PhilippVerpoort This version is more than three years old, the recent version is 3.12.3.

Thank you for pointing this out. It seems that Ubuntu Jammy (22.04 LTS) is shipping an outdated version. Ubuntu users should consider moving to the Appimage from the official website instead. It seems that the package is still maintained as mantic ships 3.10 and noble 3.11 (source https://packages.ubuntu.com/search?keywords=nextcloud-desktop). Maybe it's time to move to the next LTS...
Quick summary because unfortunately what happens with these long lived issues is that multiple *similar* but different situations end up getting collapsed together which creates confusion:

- Original issue was likely covered by #1899 (within 2.6.x branch only) and #2477 (in >=v3.1.0)
- Later, when bulk upload was introduced (in v3.4.0), it seems to have brought out an issue with similar symptoms. This is the current matter this issue seems to have grown to cover.

Ideally the original would have been closed out and later unrelated reports in their own issue, but since there's already so much history here I'll leave this open for now. I will, however, tag it to go along with our collection of bulk upload matters. 
With the upcoming release of the desktop client (version 3.16.3), the **bulk upload feature will be temporarily disabled**.

We understand that some of you may rely on this feature, and this decision wasn't made lightly. However, we've encountered ongoing technical issues involving the interaction between the client, server, and underlying systems—including network stack and Qt dependencies—that impact the stability of the feature.

In prioritizing a smoother and more reliable experience for all users, we believe it's best to disable bulk upload for now. The overall benefit of the feature does not currently outweigh the potential for disruption.

If you're unable to update to version 3.16.3 right away, we recommend manually disabling the feature on the server side to avoid any issues:
🔧 [How to disable bulk upload on the server →](https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/config_sample_php_parameters.html#bulkupload-enabled)

We appreciate your understanding and are continuing to work on improving the experience.

Hello,

I see the same problem.

The client freezes as the synchronization starts.

I stopped the sync in the short time after starting the nextcloud application.

Then I removed the Dir sync settings, deleted all local files and added it again.

but it still crashed when I change a file.

Nextcloud Server Version: Nextcloud Hub 3 (25.0.0)
Nextcloud Windows Desktop Client: 3.6.1

Commenting on this bug report, since it seems to match the symptoms the closest:

- Running nextcloud server 25.0.1
- Nextcloud Desktop Client 3.6.2 (on Windows 10)

Upon start, the desktop application completely freezes (no possibility to open it from the systray) and uses a high amount of CPU. It does not recover after several hours of leaving it. To make matters worse, it blocks opening the File Explorer until I kill the nextcloud process via task manager. And to complicate things further, running `nextcloud.exe --logwindow` opens up a log window, but immediately freezes the application with no log output.

As a workaround, disabling bulkupload on the server seems to alleviate the issue, though that's far from ideal.
I also have a possible idea for another reason of freezing (unverified): It seems that conflicts might lead to this:
It seems there could be a deadlock or something when the client tries to upload or download conflicted files again and again because: I use a Windows and a Linux client and there might always be different line endings afterwards no matter how often one of the clients uploads or downloads the conflicted duplicates.

Nextcloud should implement something like git, where line endings are normalized on the server and only updated for the OS-depending local downloads.

But as said: unverified, it might not be the case at all, it is just a possible idea. Don't know how many people use nextcloud with two different OSes.
> I use a Windows and a Linux client and there might always be different line endings afterwards no matter how often one of the clients uploads or downloads the conflicted duplicates.

nextcloud neither cares about line endings, nor should it touch them. That might have been appropriate in ancient FTP times, but not in 2022.
> Commenting on this bug report, since it seems to match the symptoms the closest:
> 
> * Running nextcloud server 25.0.1
> * Nextcloud Desktop Client 3.6.2 (on Windows 10)
> 
> Upon start, the desktop application completely freezes (no possibility to open it from the systray) and uses a high amount of CPU. It does not recover after several hours of leaving it. To make matters worse, it blocks opening the File Explorer until I kill the nextcloud process via task manager. And to complicate things further, running `nextcloud.exe --logwindow` opens up a log window, but immediately freezes the application with no log output.
> 
> As a workaround, disabling bulkupload on the server seems to alleviate the issue, though that's far from ideal.

Pretty much what I see on my laptop since a few months ago, unsure if it started "randomly" or when I upgraded to 25.0.x *and* 22H2 because I did both in 48 hours and then it started.

OwnCloud's client does work (with the same 25.0.x server and files).
Hello all,

disabling the bulkupload described in https://github.com/nextcloud/desktop/issues/4106#issuecomment-1302736545 helped on my side.

Not the best solution, but it's a workaround.


Regards
Dean
I have the same problem since I have upgraded the Nextcloud server to 25.x on different instances.

The probleme occurs with different machines on Windows 11 and 10.

It's look like it concerns the association of the client sync and the version of the server.

For example with a client in 3.4.x it was working well with a server in 25.x

For another machine with a client on 3.5 the problem came with the new version of the server.

I have solved the problem on one machine installing and desintalling the sync application but I don't know exactly what did the trick.

Update : I have solved it, uninstalling the client and reinstalling the last version it on three other machines. I don't have a clue about what exactly is happening.
Re-assessing the problem, it seems to occur for specific files only, but I do not know which ones yet.

However, it uploads and downloads several hundret MB of data until it suddenly freezes.
I closed the client for 2 weeks because of this annoyance, and hence I gathered about 200MB of data on my linux computer which got synced to the server.

I now reactivated the client on my Windows computer and it synced 200MB but froze for the last 8MB.

I have the same issue for different synced folders.

It really seems to boil down to some specific files.

I also tried to delete all conflicted local copies, but that did not resolve the problem.
I have finally found a workaround / interesting bug insight:

The error only happens during uploads but that might be because I have already synced all downloads and cannot verify the below steps for downloads as well:
It seems to be tied to the setting "Automatically Limit Upload"

When I switch to "No limit", the upload starts, BUT: The displayed amount of bytes is weird, as you can see in the video.

When I switch back to "automatically limit" the client freezes again.

https://user-images.githubusercontent.com/13003800/206772710-bbf17bc3-a513-4218-98c1-a0e571b1f4db.mp4


This has been tested with the latest update for the client.
> The error only happens during uploads but that might be because I have already synced all downloads and cannot verify the below steps for downloads as well: It seems to be tied to the setting "Automatically Limit Upload"

I confirm that removing the upload limit (and the download one too, just to be sure) fixed the problem in my case too.
I'm running Nextcloud 25.0.2 and yesterday downloaded the Windows client on my Win11 PC after successfully using the MacOS client just minutes before without issues. But on Win11 I'm seeing the same freezing issues reported here where Windows Explorer and the Nextcloud client locks up completely for 10-30 seconds at a time. All while watching the memory usage of the Nextcloud client climb at a rapid ~40MB/s. Adding or removing the limit makes no difference in my case. And I'm only trying to sync roughly 1GB of data.

![image](https://user-images.githubusercontent.com/670705/209393870-d021f092-76e9-44ac-bc8e-018f0dbb942e.png)



Same with me, 
NC 25.0.2
Nextcloud Desktop Client Version 3.6.4 (Windows)
Win 11, 22H2 build 22621.963

Yesterday for the first time played with speed limitations, and Client froze and gave response only for couple of seconds after desktop client start. Thanks to @electrocnic  comment, switched to "no limit"  both "up & down". And no freezing anymore.

_For me there was few hundred GB data to sync (upload) to server_
I have the same issue
NC 25.0.5
Nextcloud Desktop Client Version 3.6.4 (Windows)

I downgrade the desktop client to 3.3.6 and the issue just disappear. 
I don't have this issue with the MacOS client. 
Same issue here server 25.0.2
win 3.6.4 client
Disabling speed limits does not help.
Can confirm: Just updated my server from 24.0.9 to 25.0.3 and now my windows client also freezes upon start.

I tested to revoke Desktop client access - afterwards, the client would open again without freezing. Signing in again, immediatly afterwards when the sync starts, the app freezes again.

I think this is a critical issue, since a) I cannot sync anymore and b) there's no workaround.

Some observations:

- This first happened, directly, after I upgraded from 24.0.9 to 25.0.3
- After a restart, the issue seems to have disappeared. 
- It became unresponsive again, after 5 Minutes Uploading files
- After removing Network bandwidth limit, as suggested, everything worked again
- The same happened to my 2nd Windows Desktop client; the same solution (removing bandwidth limit) worked there, too
Luckily, I found this issue yesterday after having this problem for a week or so, and I can confirm that removing the network bandwidth limit allows the client to sync again.

Additionally, I want to add that if you can't even get into the settings UI (because it is immediately unresponsive), you can change the variable `paused=false` to `paused=true` in `C:\Users\USERNAME\AppData\Roaming\Nextcloud\nextcloud.cfg` before starting the client. This pauses the synchronization and the UI remains responsive until you unpause the synchronization again. 

Maybe this helps someone with less "technical" knowledge to apply the workaround without the need to revoke the client access.
I can confirm @alexjung's comment and workaround. I have exactly the same problem, probably after changing the server to version 25.0.2. After removing all upload and download limitations, the client is working again.
I can confirm that I have found this issue too. 
For my case to disable the up/down limitations was not a possibility so I tried the second option.

Disabling bulk upload like described in #4106  has worked for now.
I had a freezing issue syncing to my v25.03 Windows/WSL2 server after my desktop client upgraded to v3.7.X. Downgraded client back to v3.6.6 and the sync is now working as it was before the upgrade.
Windows client 3.7.3
Server 25.0.3
Same issue. Client is locked up in the tray. High CPU but nothing is happening.
I set it to 'paused' in the config file. That allowed it to start. I removed bandwidth limits.
Problem resolved
Changing from "Automatically Limit Upload" to "no limit" worked for me.  
Never would have thought of that.  

Windows client: 3.7.4
Server: 25.0.4
The Setting "No Limit" for upload helped to solve my issue too.
Windows Client 3.8.1
Server: 25.0.5

This is still an issue
Can't believe it still hasn't been fixed with the number of updates the app gets
Can confirm the "No Limit" Workaround.

Windows Client 3.10.1
Server: 27.1.2
I have same issue I think its a Windows problem cause I was tired of having the same problem with OneDrive so decided to migrato to NextCloud and it has the same issue so maybe the problem is not the app? 
> I have same issue I think its a Windows problem cause I was tired of having the same problem with OneDrive so decided to migrato to NextCloud and it has the same issue so maybe the problem is not the app?

I had exactly the same problem as well an freezing "explorer.exe", when right-click on files. As well, with my complete fresh installed Windows 11, as soon as I installed the Nextcloud-Client the problem was back.
The solution for me, was to deactivate the "explorer integration" from Nextcloud-Client. Found here:
![image](https://github.com/nextcloud/desktop/assets/12274612/f6e86f35-9c84-4d30-bea8-10e262ba4ebf)

If I do this how I see my files from nextcloud?
> If I do this how I see my files from nextcloud?

You could simply pin your Nextcloud folder to your Explorer favorites. -> This is how I do it :) cheers
I thought this option doesn't let you see nextcloud files from windows explorer. If I can still see them when I pin it what does this check makes?
For me both solutions did not work. The UI and Upload process were very unresponsive for most time. Configuring anything was difficult.
But what worked, was disabling virtual files, as described in this issue: https://github.com/nextcloud/desktop/issues/6357
So this is still a valid issue for Client 3.13 on the latest Windows 10.
Client get's stuck on 100% CPU usage on a single core (in my case ~8% total CPU) and it looks like it's also blocking some administrative Windows functions, e.g. opening the CMD as admin is not possible when this happens.
Might be a Windows bug or something windows specific...

@litetex Have you tried disabling virtual files?
> @litetex Have you tried disabling virtual files?

Yes the problem occured when I had virtual files disabled (didn't check if it also happens when they are enabled)
> Yes the problem occured when I had virtual files disabled (didn't check if it also happens when they are enabled)

@litetex everybody else in this issue doesn't have the problem when virtual files are disabled. Are you sure you did disable them? If you find it difficult because the system freezes, try disconnecting the network before opening the settings, that way the bug doesn't trigger and you can save the client's settings properly.

> I have finally found a workaround / interesting bug insight:
> 
> The error only happens during uploads but that might be because I have already synced all downloads and cannot verify the below steps for downloads as well: It seems to be tied to the setting "Automatically Limit Upload"
> 
> When I switch to "No limit", the upload starts, BUT: The displayed amount of bytes is weird, as you can see in the video.
> 
> When I switch back to "automatically limit" the client freezes again.
> nextbug.mp4
> 
> This has been tested with the latest update for the client.

I have the same or a similar issue and this workaround also works for me. Thanks for sharing and hopefully the underlying bug will be fixed soon.
With the upcoming release of the desktop client (version 3.16.3), the **bulk upload feature will be temporarily disabled**.

We understand that some of you may rely on this feature, and this decision wasn't made lightly. However, we've encountered ongoing technical issues involving the interaction between the client, server, and underlying systems—including network stack and Qt dependencies—that impact the stability of the feature.

In prioritizing a smoother and more reliable experience for all users, we believe it's best to disable bulk upload for now. The overall benefit of the feature does not currently outweigh the potential for disruption.

If you're unable to update to version 3.16.3 right away, we recommend manually disabling the feature on the server side to avoid any issues:
🔧 [How to disable bulk upload on the server →](https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/config_sample_php_parameters.html#bulkupload-enabled)

We appreciate your understanding and are continuing to work on improving the experience.

I updated the client to the fresh released 3.6.6 versionand the same errors are present.

I did some more testing and I noted, that, if I add a new folder to sync with more than 1.000 files and the files does not exist on the server jet, I receive this error.

If I move less than 1.000 files to the folder, wait that the files are synced, then move the next 1.000 files and so on, all get synced correctly without errors.

The folder contains totally about 15.000 files and folders.
Does your server show "Computed md5 hash is incorrect." or "Sabre\DAV\Exception: Unknown error while seeking content" in the Log? 

You can try disabling the bulk feature on the server ('bulkupload.enabled' => false,) then disable any speed limits in the desktop client settings and delete the files that wont sync.

I have the exact same issue as @mr-manuel with ~25000 files and doing what @SunnyPaprika described helped me. Thank you!
Sounds a lot like this bug https://github.com/nextcloud/desktop/issues/5094

The workaround from @SunnyPaprika also worked for me. The bug https://github.com/nextcloud/desktop/issues/5094 represents also my client behaviour.
Thanks @SunnyPaprika [comment](https://github.com/nextcloud/desktop/issues/5349#issuecomment-1399208594)
Also, for others, the place I edited this was in www/nextcloud/config/config.php
I also seemed to have to restart my windows desktop client.
I am using Unraid, and linuxServer's nextcloud version of the container. (the /www was in the defined appdata folder)
Disabling bulk upload feature ('bulkupload.enabled' => false,) fixed all errors (413 Request Entity Too Large;  99 Network error) then uploading large amount of files (~60000 files, 90GB).
Setup:
linuxserver docker images for swag and nextcloud.
Fixed the issue for me aswell, but is anyone else having much slower upload speed?
With the upcoming release of the desktop client (version 3.16.3), the **bulk upload feature will be temporarily disabled**.

We understand that some of you may rely on this feature, and this decision wasn't made lightly. However, we've encountered ongoing technical issues involving the interaction between the client, server, and underlying systems—including network stack and Qt dependencies—that impact the stability of the feature.

In prioritizing a smoother and more reliable experience for all users, we believe it's best to disable bulk upload for now. The overall benefit of the feature does not currently outweigh the potential for disruption.

If you're unable to update to version 3.16.3 right away, we recommend manually disabling the feature on the server side to avoid any issues:
🔧 [How to disable bulk upload on the server →](https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/config_sample_php_parameters.html#bulkupload-enabled)

We appreciate your understanding and are continuing to work on improving the experience.

### I have the same problem. (I am on an old(ish) version though)
I'm not sure how helpful it is, but in case it can help here is my story.
Everything worked fine for me until I tried to sync my whole music library (>20GB) over nextcloud. After I got a BadRequest error a few times, whenever I try to sync up (this specific folder, the others that I previously set up work fine) from the machine with the original Data (there was data in the folder when I linked it to nextcloud over the gui) i get the "Computed md5 hash is incorrect." error and my nextcloud app on windows (that tried to do the uploading) freezes.

other infos:
17.8GB got uploaded before it crashes faster than any progress is done.
I am one version behind on the nextcloud server.
I can download the uploaded content on my linux machine with the native nextcloud app without problems.

"userAgent": "Mozilla/5.0 (Windows) mirall/3.12.1stable-Win64 (build 20240306) (Nextcloud, windows-10.0.19045 ClientArchitecture: x86_64 OsArchitecture: x86_64)",
  "version": "28.0.2.5",

BadRequest Expected filesize of 6348595 bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) 3097600 bytes. Could either be a network problem on the sending side or a problem writing to the storage on the server side.
Related: nextcloud/server#29984
Same problem with server side Nextcloud 28.0.5.1 on debian 11 (bullseye) with php 8.2 and all updates applied.
On client side nextCloud Desktop client 3.4.2 (ubuntu-6.5.0-28-generic) on Ubuntu 22.04 (again all updates applied).

I do not have network limits set. Desktop client stands there showing "waiting..." in the settings dialog and I unfortunately I cannot find anywhere an information what it is waiting for. And actually it happens since I added (another) folder with a lot of subdirectories and files. I tried several times pausing, quitting, restarting the sync. Somehow by accident the client in the settings dialog where the sync process is shown, it showed me an error:

<folder>: server hat "404 Not Found" auf "MOVE https://<folder>" geantwortet"
which means server responded with 404 on the MOVE request.

I investigated the exact folder and found a lot of directories and subdirectories with 0-byte size (so no contents). I moved the folder on the client to a different location and deleted the folder via Nextcloud web interface. Then sync continued for a while but currently hanging again at different point - again with "Warte..." (=waiting). It would already help a lot if the client would show some information on what it is waiting for. - 
But it had a different error then shown in the server logs:
PHP Request Startup: POST Content-Length of 87320780 bytes exceeds the limit of 52428800 bytes at Unknown#0
Last operation found was syncing a very old .url file (from very old windows days). I deleted that and again sync continued for a while. Then it hanged again with content length error. I tried again in smaller pieces which worked. Then I experienced "Too many open files" errors on the desktop client. However, after a few seconds on such errors the sync process continous - but not very convincing...

But **finally** - with the hint of the "too many open files" error I **was able to solve the problem** by
`sudo vim /var/www/html/nextcloud/config/config.php`
and adding this line::
`'bulkupload.enabled' => false,`
followed by command
`sudo systemctl restart apache2`
I cannot even see really a performance difference and a further positive side effect is, that the displayed approximate upload remaining time and bytes is correctly shown. Before it was changing all the time, sometimes to something totally different.

I do now get a warning from time to time in the server logs:

> DeadlockException An exception occurred while executing a query: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction
> Error while updating parent storage_mtime, should be safe to ignore 

But that looks save.
> Same problem with server side Nextcloud 28.0.5.1 on debian 11 (bullseye) with php 8.2 and all updates applied. On client side nextCloud Desktop client 3.4.2 (ubuntu-6.5.0-28-generic) on Ubuntu 22.04 (again all updates applied).

@mwildam The client version you use is more than three years old and at least some of the problems you describe should be resolved since.
The recent stable version is 3.12.4 (3.13.0 being just released but facing some bugs). Maybe you have the possibility to retest with a recent version? (On Ubuntu you can use this PPA https://launchpad.net/~nextcloud-devs/+archive/ubuntu/client)

Oh, on my daily driver I have a current version - the one where 3.4.2 is running is the PC of my wife. Wondering, why - although all updates applied, she still got that 3.4.2. ... - OK, I have the appropriate extra repository added on my machine. Anyway, disabling the bulkupload solved the problem even for the old client.
 i have the same issue using client 3.12.6 and server 29.0.3
Same issue, I have 342 errors in the log in the past 7 days.

Clients:
* Desktop: 3.13.2 (Linux - Fedora 40)
* Android: 3.29.1 (Android - F-Droid)

Server:
* 29.0.4 (Linux - Ubuntu 20.04)
Hi, the same issue here. NC server version 30.0.1.2, windows desktop client 3.14. Network limit disabled, but still this error was presented and upload stucked. Adding `'bulkupload.enabled' => false,` helped, but the upload is way slower than before.
I had to turn off "bulkupload" as well. Uploads are slower but doesn't pause and throw as many errors, although still have a few.

nc 29.0.1

Same issue on Windows 10 client machine running desktop client version 3.15.2.
Happens when NC client on Windows 10 is trying to sync a new folder of size 963 MiB containing 193 photo files and a few small video files. The first ~650 MiB / ~140 files are transferred without issue, then the transfer stalls.
I got the same issue. Brand new install of Nextcloud Hub 9 (30.0.4) via AOI Docker contanier. 
Latest desktop client version Nextcloud desktop client 3.15.2. 
Needed to sync 10 Gb folder with media. After uploading 9Gb started throwing this error "Computed md5 hash is incorrect" in logs and getting stuck in the sync. 
For some reason when the desktop sync client is getting stuck, it takes with it and crashes the whole file explorer.

The issue persists on newest AIO-Docker NC-Hub 30.0.4 with client 3.13.4. 
I have approximately 700 gb of mainly images overall (but I never sync them all at once!).
It seems to appear more frequently when the amount of files to sync is quite high (> 5 gb).
Same issue on Windows 10 Nextcloud desktop client (3.15.3) with Nextcloud Hub 7(28.0.1) installed in Ubuntu server.
Thanks to advice given by @mwildam. After adding ```'bulkupload.enabled' => false,``` in config file and restart apache2, it works fine for me. Do not forget to restart client as well cause the client will stuch on uploading as bulk if not restarted.
Same here, Windows 10 desktop client 3.15.3, server debian php3.8 nextcloud 30.0.6.
I added a directory with nearly 3 GB of data and 500 files.
Same error log, same behaviour (desktop client stuck).
Don't know if it matters, but it always stuck on file **100** / XXX, even after I deleted the .sync_XXXX.db file and retried.
Always exactly the same issue.

`'bulkupload.enabled' => false` fixes the issue, thanks @mwildam !

Disclaimer : I use a non standard storage (a rclone mount over ssh)
I have the same issue here on Nextcloud server 30.0.6 (on TrueNAS SCALE 24.10.2 using the Nextcloud community docker image) and client version 3.16.0 on Windows 11. I'm uploading around 11GB of small image files from one client.
I'm also getting an "Unknown error while seeking content" error which may be somewhat related, but I have no idea.

Setting the `'bulkupload.enabled' => false` config option fixes both of those errors for me, with the caveat of the upload speed being reduced as mentioned in the previous comments in this issue.

<details><summary>Logs</summary>
<p>

```json
[
    {
        "reqId": "ir01b4cL8qQy7sZd4OTP",
        "level": 3,
        "time": "2025-03-10T21:09:49+00:00",
        "remoteAddr": "x.x.x.x",
        "user": "redacted",
        "app": "no app in context",
        "method": "POST",
        "url": "/remote.php/dav/bulk",
        "message": "Computed md5 hash is incorrect.",
        "userAgent": "Mozilla/5.0 (Windows) mirall/3.16.0 (build 20250306) (Nextcloud, windows-10.0.22631 ClientArchitecture: x86_64 OsArchitecture: x86_64)",
        "version": "30.0.6.2",
        "data": []
    },
    {
        "reqId": "S6kZJZowTaOpZvdI1x45",
        "level": 3,
        "time": "2025-03-10T21:09:51+00:00",
        "remoteAddr": "x.x.x.x",
        "user": "redacted",
        "app": "webdav",
        "method": "POST",
        "url": "/remote.php/dav/bulk",
        "message": "Unknown error while seeking content",
        "userAgent": "Mozilla/5.0 (Windows) mirall/3.16.0 (build 20250306) (Nextcloud, windows-10.0.22631 ClientArchitecture: x86_64 OsArchitecture: x86_64)",
        "version": "30.0.6.2",
        "exception": {
            "Exception": "Sabre\\DAV\\Exception",
            "Message": "Unknown error while seeking content",
            "Code": 500,
            "Trace": [
                {
                    "file": "/var/www/html/apps/dav/lib/BulkUpload/MultipartRequestParser.php",
                    "line": 117,
                    "function": "isAt",
                    "class": "OCA\\DAV\\BulkUpload\\MultipartRequestParser",
                    "type": "->",
                    "args": [
                        "--boundary_.oOo._EDhh3WlTpqNZuLyXiAtH9U0ATr+XrjHX--\r\n"
                    ]
                },
                {
                    "file": "/var/www/html/apps/dav/lib/BulkUpload/BulkUploadPlugin.php",
                    "line": 54,
                    "function": "isAtLastBoundary",
                    "class": "OCA\\DAV\\BulkUpload\\MultipartRequestParser",
                    "type": "->",
                    "args": []
                },
                {
                    "file": "/var/www/html/3rdparty/sabre/event/lib/WildcardEmitterTrait.php",
                    "line": 89,
                    "function": "httpPost",
                    "class": "OCA\\DAV\\BulkUpload\\BulkUploadPlugin",
                    "type": "->",
                    "args": [
                        {
                            "__class__": "Sabre\\HTTP\\Request"
                        },
                        {
                            "__class__": "Sabre\\HTTP\\Response"
                        }
                    ]
                },
                {
                    "file": "/var/www/html/3rdparty/sabre/dav/lib/DAV/Server.php",
                    "line": 472,
                    "function": "emit",
                    "class": "Sabre\\DAV\\Server",
                    "type": "->",
                    "args": [
                        "method:POST",
                        [
                            {
                                "__class__": "Sabre\\HTTP\\Request"
                            },
                            {
                                "__class__": "Sabre\\HTTP\\Response"
                            }
                        ]
                    ]
                },
                {
                    "file": "/var/www/html/apps/dav/lib/Connector/Sabre/Server.php",
                    "line": 43,
                    "function": "invokeMethod",
                    "class": "Sabre\\DAV\\Server",
                    "type": "->",
                    "args": [
                        {
                            "__class__": "Sabre\\HTTP\\Request"
                        },
                        {
                            "__class__": "Sabre\\HTTP\\Response"
                        }
                    ]
                },
                {
                    "file": "/var/www/html/apps/dav/lib/Server.php",
                    "line": 371,
                    "function": "start",
                    "class": "OCA\\DAV\\Connector\\Sabre\\Server",
                    "type": "->",
                    "args": []
                },
                {
                    "file": "/var/www/html/apps/dav/appinfo/v2/remote.php",
                    "line": 19,
                    "function": "exec",
                    "class": "OCA\\DAV\\Server",
                    "type": "->",
                    "args": []
                },
                {
                    "file": "/var/www/html/remote.php",
                    "line": 146,
                    "args": [
                        "/var/www/html/apps/dav/appinfo/v2/remote.php"
                    ],
                    "function": "require_once"
                }
            ],
            "File": "/var/www/html/apps/dav/lib/BulkUpload/MultipartRequestParser.php",
            "Line": 99,
            "message": "Unknown error while seeking content",
            "exception": {},
            "CustomMessage": "Unknown error while seeking content"
        }
    }
]
``` 

</p>
</details> 
With the upcoming release of the desktop client (version 3.16.3), the **bulk upload feature will be temporarily disabled**.

We understand that some of you may rely on this feature, and this decision wasn't made lightly. However, we've encountered ongoing technical issues involving the interaction between the client, server, and underlying systems—including network stack and Qt dependencies—that impact the stability of the feature.

In prioritizing a smoother and more reliable experience for all users, we believe it's best to disable bulk upload for now. The overall benefit of the feature does not currently outweigh the potential for disruption.

If you're unable to update to version 3.16.3 right away, we recommend manually disabling the feature on the server side to avoid any issues:
🔧 [How to disable bulk upload on the server →](https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/config_sample_php_parameters.html#bulkupload-enabled)

We appreciate your understanding and are continuing to work on improving the experience.

~~I can't verify if this is still an issue on 3.15.1 due to #7632 - it's not giving me any indication of syncing. Maybe I need to let this run for a bit?~~

EDIT: Yeah, just letting it run for a LONG time. It still exists for 3.15.1. I did a file upload of 5000 files with less than 100 MBs.
I think I have the same issue now with 3.15.3 and windows 10. I modified quite a lot of files, and now windows explorer is stuck.
On task manager, windows explorer is stuck with 15% CPU (one full core), but nextcloud is quite low (about 2-3% CPU).
As a workaround, I manually restarted explorer.exe. It's responsive again, but stays high on CPU (15-16%), for about 10 minutes, then nextcloud managed to finish sync.
Can confirm this behaviour on 3.16.2 Windows 11. Server 30.0.8. I have 3769 files that refuse to sync for network error 499, and am also seeing the tray icon flickering and the explorer process hang and crash.

ETA: As suggested above I left it running/hanging for a long time, and after a few rounds of "Failed to sync <every file on nextcloud> files" errors it cleared itself up.
With the upcoming release of the desktop client (version 3.16.3), the **bulk upload feature will be temporarily disabled**.

We understand that some of you may rely on this feature, and this decision wasn't made lightly. However, we've encountered ongoing technical issues involving the interaction between the client, server, and underlying systems—including network stack and Qt dependencies—that impact the stability of the feature.

In prioritizing a smoother and more reliable experience for all users, we believe it's best to disable bulk upload for now. The overall benefit of the feature does not currently outweigh the potential for disruption.

If you're unable to update to version 3.16.3 right away, we recommend manually disabling the feature on the server side to avoid any issues:
🔧 [How to disable bulk upload on the server →](https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/config_sample_php_parameters.html#bulkupload-enabled)

We appreciate your understanding and are continuing to work on improving the experience.

@dt64 could you share your configuration file and also some info on the file size ?
I am suspecting the bulk upload feature or chunk upload to be the issue
So I would need if you were uploading small files or very big ones
the dir structure includes about 31k files in 3,5k subdirectories using 1,22GB. Average file size is pretty small.
my config file is attached. There are two accounts configured. The issue was with acc ID 1.

[nextcloud.cfg.txt](https://github.com/user-attachments/files/18474834/nextcloud.cfg.txt)


With the upcoming release of the desktop client (version 3.16.3), the **bulk upload feature will be temporarily disabled**.

We understand that some of you may rely on this feature, and this decision wasn't made lightly. However, we've encountered ongoing technical issues involving the interaction between the client, server, and underlying systems—including network stack and Qt dependencies—that impact the stability of the feature.

In prioritizing a smoother and more reliable experience for all users, we believe it's best to disable bulk upload for now. The overall benefit of the feature does not currently outweigh the potential for disruption.

If you're unable to update to version 3.16.3 right away, we recommend manually disabling the feature on the server side to avoid any issues:
🔧 [How to disable bulk upload on the server →](https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/config_sample_php_parameters.html#bulkupload-enabled)

We appreciate your understanding and are continuing to work on improving the experience.

@Schneehexe can you test also by disabling bulk upload ?

https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/config_sample_php_parameters.html#bulkupload-enabled
I have changed this parameter (bulkupload enabled = false.


After synchronizing two image folders with a total of 1.3 GB (upload), I can see that it works as expected.
Now I have to make a correction.
The argument has probably reset itself to “true”. The upload also shows the old behavior again.
I have set it to “false” again, but the error is still there again - exactly as described before. 
Hello,

after changing config parameters, please restart the client to update correctly.
fyi: 

With the upcoming release of the desktop client (version 3.16.3), the **bulk upload feature will be temporarily disabled**.

We understand that some of you may rely on this feature, and this decision wasn't made lightly. However, we've encountered ongoing technical issues involving the interaction between the client, server, and underlying systems—including network stack and Qt dependencies—that impact the stability of the feature.

In prioritizing a smoother and more reliable experience for all users, we believe it's best to disable bulk upload for now. The overall benefit of the feature does not currently outweigh the potential for disruption.

If you're unable to update to version 3.16.3 right away, we recommend manually disabling the feature on the server side to avoid any issues:
🔧 [How to disable bulk upload on the server →](https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/config_sample_php_parameters.html#bulkupload-enabled)

We appreciate your understanding and are continuing to work on improving the experience.
The objectionable behavior in my case remains even with the 

`'bulkupload.enabled' => false,`

setting!

It is noticeable that not all folders or files are affected. It seems that the desktop client always hangs on the same directories/files.



Fix (patch):
diff --git a/src/libsync/owncloudpropagator.cpp b/src/libsync/owncloudpropagator.cpp
index 969a8ba031afc..30b48ef874a1c 100644
--- a/src/libsync/owncloudpropagator.cpp
+++ b/src/libsync/owncloudpropagator.cpp
@@ -1091,29 +1091,9 @@ Result<Vfs::ConvertToPlaceholderResult, QString> OwncloudPropagator::staticUpdat
 
 bool OwncloudPropagator::isDelayedUploadItem(const SyncFileItemPtr &item) const
 {
-    const auto checkFileShouldBeEncrypted = [this] (const SyncFileItemPtr &item) -> bool {
-        const auto path = item->_file;
-        const auto slashPosition = path.lastIndexOf('/');
-        const auto parentPath = slashPosition >= 0 ? path.left(slashPosition) : QString();
-
-        SyncJournalFileRecord parentRec;
-        bool ok = _journal->getFileRecord(parentPath, &parentRec);
-        if (!ok) {
-            return false;
-        }
-
-        const auto accountPtr = account();
+    Q_UNUSED(item)
 
-        if (!parentRec.isValid() ||
-            !parentRec.isE2eEncrypted()) {
-            return false;
-        }
-
-        return true;
-    };
-
-    return account()->capabilities().bulkUpload() && !_scheduleDelayedTasks && !item->isEncrypted() && _syncOptions.minChunkSize() > item->_size
-        && !isInBulkUploadBlackList(item->_file) && !checkFileShouldBeEncrypted(item);
+    return false;
 }
 
 void OwncloudPropagator::setScheduleDelayedTasks(bool active)