nextcloud
[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 and Desktop Releases for supported versions.
- [X] I agree to follow Nextcloud's Code of Conduct
Bug description
Error "Computed md5 hash is incorrect" thrown in Log, while sync files with Nextcloud Desktop App.
Steps to reproduce
- Sync files with Nextcloud Desktop App
- 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
{
"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
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.
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:
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.
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.
Logs
[
{
"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"
}
}
]
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.
