desktop
desktop copied to clipboard
[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 and Desktop Releases for supported versions.
- [X] I agree to follow Nextcloud's 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
- Install VS Code on Windows
- Install some extensions
- 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
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
Here the client logs: debug.zip
Nextcloud is behind a Haproxy, but I tried also with a direct connection to the Docker container. Same result.
Here some screenshots:


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 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 →
We appreciate your understanding and are continuing to work on improving the experience.