-
Notifications
You must be signed in to change notification settings - Fork 87
MD5 file hashes causing endless download loops in NC 12.0.3 #213
Comments
My guess here is that this is a nextCloud server bug. It probably sends multiple checksums when the |
I'm not yet familiar enough with the procedures here @ckamm to know what I should do if you're right - would I need to refile this under the server threads somewhere? |
Hey, I have the same problem, I think. I switched from owncloud, and it went smooth, there were no problems on server or on clients. Some time later I setup a fresh client, and the download goes in the endless loop. It there a working solution, even if a temporary one? |
I'm getting the same on my 12.0.3 box. I think this issue should be moved to server, although the mobile apps seem to sync fine. |
I used a workaround from there: |
And if there are several checksums, pick the "best" one. The case of several checksum was reported in nextcloud/client_theming#213
And if there are several checksums, pick the "best" one. The case of several checksum was reported in nextcloud/client_theming#213
The Woboq team was so nice to help us fix this in owncloud/client#6172 - we'll get it in our client soon. |
I had this issue, too. I have a different statment to remove the mis-behaving checksums: |
I know this repo is related to nextcloud, but ... Same problem happened to me using ownCloud Sync Client (and ownCloud Server). Fix that worked for meTyping (in MariaDB) while owncloud_db is used. UPDATE oc_filecache
SET checksum = ''
WHERE COALESCE (checksum, ‘’) <> ‘’; Fixed the problem for me. Server ConfigurationOperating system: Web server: Database: PHP version: ownCloud version: ownCloud Client: When it happenedAll files which I have deleted and then restored showed the error Maybe this Information helps. |
@Morodar This seems like a different issue, unrelated to the server sending multiple content hashes at once. Can you explain about how you created the situation in which you got the "does not match the checksum" error in detail? How exactly did you delete and restore files? Preferably create a new bug report at https://github.com/owncloud/client/issues . |
@ckamm The only thing I can remember is that I've reset my Android phone. (FolderSync is able to Sync Directories between your phone and GoogleDrive, Amazon, ... , and also ownCloud) Somehow FolderSync deleted about 400 .mp3 files. I restored them in the Browser in the ownCloud 'Deleted Files' section After that, my Workstation downloaded all restored .mp3 files. I opened ownCloud Sync Client which showed me That's the reason why i though that the File deletion and restoration may have caused the error. |
Steps to reproduce
Expected behaviour
It should download/sync the files to the new client
Actual behaviour
A large number of files get the error " Nextcloud,The downloaded file does not match the checksum, it will be resumed."
For each file that gets this error, it will re-try to download, again and again and again and again and never succeed.
Looking more deeply, I checked the database because I initially suspected corruption of the oc_filechache.checksum field. However, it is correct.
Here is an example:
Okay, so scratch head.... these checksums match!? So why is the client saying they don't match? I have no idea.
However, one more clue. Try removing checksum data from the particular column/cell for this file in the database:
1. Remove all checksum data: file syncs properly
2. Remove only alder32 data: file does not sync
3. Remove alder32 data and MD5 data, but leave SHA1 data: file syncs
Therefore, it appears that the problem is with the MD5 data, for some reason on certain files, it cannot verify.
Furthermore, I checked the server logs:
sudo -u www-data grep /mnt/ncdata/nextcloud.log
There was no entry for the affected files in the server logs.
So this appears to be a client issue.
As a final step, I tested what happens when I remove an affected file and re-upload it.
After doing so, the file downloads fine on all clients. Checking the new database entry, there is nothing in the checksum field. Interesting!
So I am wondering now what is going on with the checksums, why some files have them and some don't? I was migrated from an older Owncloud install a few months ago, could that be the issue?
Even if it is due to the owncloud migration, this should be handled automatically....
Server configuration
Operating system:
Ubuntu 16.04.3 LTS
Web server:
Apache/2.4.18 (Ubuntu)
Database:
MariaDB 10.2.9
PHP version:
7.0.22-0ubuntu0.16.04.1
Nextcloud version: (see Nextcloud admin page)
12.0.3
Updated from an older Nextcloud/ownCloud or fresh install:
Updated from 12.0.1 (but fresh install before that)
Where did you install Nextcloud from:
Tech and Me VM
Signing status:
Signing status
List of activated apps:
App list
``` Enabled: - activity: 2.5.2 - bruteforcesettings: 1.0.2 - calendar: 1.5.5 - comments: 1.2.0 - contacts: 2.0.1 - dav: 1.3.0 - drawio: 0.8.8 - federatedfilesharing: 1.2.0 - files: 1.7.2 - files_downloadactivity: 1.1.1 - files_external: 1.3.0 - files_markdown: 2.0.1 - files_pdfviewer: 1.1.1 - files_sharing: 1.4.0 - files_texteditor: 2.4.1 - files_trashbin: 1.2.0 - files_versions: 1.5.0 - files_videoplayer: 1.1.0 - firstrunwizard: 2.1 - gallery: 17.0.0 - logreader: 2.0.0 - lookup_server_connector: 1.0.0 - nextant: 1.0.8 - nextcloud_announcements: 1.1 - notifications: 2.0.0 - oauth2: 1.0.5 - password_policy: 1.2.2 - provisioning_api: 1.2.0 - richdocuments: 1.12.35 - serverinfo: 1.2.0 - sharebymail: 1.2.0 - spreed: 2.0.1 - survey_client: 1.0.0 - systemtags: 1.2.0 - theming: 1.3.0 - twofactor_backupcodes: 1.1.1 - updatenotification: 1.2.0 - workflowengine: 1.2.0 Disabled: - admin_audit - encryption - federation - previewgenerator - ransomware_protection - user_external - user_ldap ```Nextcloud configuration:
Config report
``` { "system": { "passwordsalt": "***REMOVED SENSITIVE VALUE***", "secret": "***REMOVED SENSITIVE VALUE***", "trusted_domains": [ "localhost", "***REMOVED SENSITIVE VALUE***", "***REMOVED SENSITIVE VALUE***", "***REMOVED SENSITIVE VALUE***" ], "datadirectory": "\/mnt\/ncdata", "overwrite.cli.url": "https:\/\/***REMOVED SENSITIVE VALUE***\/", "dbtype": "mysql", "version": "12.0.3.3", "dbname": "nextcloud_db", "dbhost": "localhost", "dbport": "", "dbtableprefix": "oc_", "mysql.utf8mb4": true, "dbuser": "***REMOVED SENSITIVE VALUE***", "dbpassword": "***REMOVED SENSITIVE VALUE***", "installed": true, "instanceid": "oc3h4gsr8sgn", "maintenance": true, "mail_smtpmode": "smtp", "memcache.local": "\\OC\\Memcache\\Redis", "filelocking.enabled": true, "memcache.distributed": "\\OC\\Memcache\\Redis", "memcache.locking": "\\OC\\Memcache\\Redis", "redis": { "host": "\/var\/run\/redis\/redis.sock", "port": 0, "timeout": 0, "dbindex": 0, "password": "***REMOVED SENSITIVE VALUE***" }, "htaccess.RewriteBase": "\/", "loglevel": "2", "log_type": "file", "logfile": "\/mnt\/ncdata\/nextcloud.log", "logtimezone": "America\/Denver", "mail_from_address": "admin", "mail_smtpauthtype": "LOGIN", "mail_domain": "***REMOVED SENSITIVE VALUE***", "mail_smtpauth": 1, "mail_smtphost": "***REMOVED SENSITIVE VALUE***", "theme": "" } } ```Are you using external storage, if yes which one: no
Are you using encryption: no
Are you using an external user-backend, if yes which one:
I don't fully understand the question... yes, there is webdav access for a backup process, but it has not touched the affected files here.
Client configuration
Browser:
I've tried Safari and Firefox
Operating system:
MacOS High Sierra
Client
Nextcloud client 2.3.2 (build 1)
Logs
Web server error log
Web server error log
Nextcloud log (data/nextcloud.log)
Nextcloud log
I have not included the whole log because it is large. However, after taking the system out of maintenance mode, I ran a new sync attempt on the client, and no logs were produced on the server, even though the client continued to report the same error on these files.
Browser log
Not applicable
Client log
This is just a short log extract from the client.
The text was updated successfully, but these errors were encountered: