Encrypted folder doesn't sync (failed hash check)

Recommended Posts

I've created a rslsync encrypted folder on my NAS (QNAP TS119, Marvell Kirkwood SOC)
and added the encrypted key to a rslsync folder on a vserver. This setup
won't sync apparently due to failing hash checks at the vserver.

Syncing to another target (Notebook, Arch Linux, Linux 4.8.11, x86_64, rslsync
2.4.2, r/w key) works in all directions (NAS <-> Laptop, vserver <-> Laptop).

I think I've quoted the relevant logfile entries, if not the full logfiles are

Many thanks for your support!


platform: Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64

platform: Linux 3.16.0-4-kirkwood #1 Debian 3.16.36-1+deb8u2 (2016-10-19) armv5tel



[20161206 12:20:11.310] PD[B140] [6D82]: Sending ping to ""
[20161206 12:20:11.395] SyncFolderNotify: SyncFolderNotify: "D76B709F276A8B29F9CB7AD9DFF601CB96917C33.!sync", event = "IN_MODIFY"
[20161206 12:20:11.395] [OnNotifyFileChange] "/home/rslsync/shares/sync/.sync/D76B709F276A8B29F9CB7AD9DFF601CB96917C33.!sync"


[20161206 12:20:11.415] PC[0xb483aab8][0xb3e63360][] got bad piece 155
[20161206 12:20:12.313] TF[B140] [0xb3e63360][<< Path to file removed >>]: state:SEED error: meta:1 conns:1 io:0




Share this post

Link to post
Share on other sites

I've now tried to sync from the NAS to a folder on the notebook with the encrypted key. Sync doesn't work here either due to failing hash checks.

Looks like the problem is located somewhere at the NAS or at the arm deb package. 

Share this post

Link to post
Share on other sites

well, this error means that while the file was being synced, its piece hash has changed. And thus the receiving side will not accept the file. 

You can check if anything is accessing the file while it's being synced, simplest is lsof /path/to/file. You can add -r N parameter so that lsof checks for file usage every 15 or N seconds. Do that on both machines. 



Share this post

Link to post
Share on other sites

I did that on both seeding devices (NAS, Notebook), the only access lsof reports are from rslsync.
On the receiving target (vserver) the file doesn't appear, therefore I can't do it there. 

I don't think the file is altered as this only happens at targets with the encrypted key, while with the r/w key everything works fine (didn't test the r key).
Syncing fails only if the seeding device is the NAS and the target has the encrypted key.

Edit: Tried a newly created encrypted folder, same results. 

Share this post

Link to post
Share on other sites

Frankly speaking nothing more in the logs - the piece just arrives different form what was sent. I don't think I can know for sure why it changes.

Share this post

Link to post
Share on other sites

That's strange, but thank you for looking into it.

If I had to guess I would say there is something wrong with hash generation and/or encryption at the NAS. I cant imagine that something is altering the packages, more specific the packages going to a peer using the encrypted key. 
From that point of view there is either a (hardware platform specific) bug in rslsync (or a used library) or there is some hardware fault at my NAS. 

Can anyone confirm that seeding to peers with the encrypted key is working with Debian Jessie on Marvel SoC 'Kirkwood' (eg. Qnap TS11x, 12x, 21x, 22x, 41x, 42x devices)? 

Share this post

Link to post
Share on other sites

I'm experiencing (suffering) something similar, an encrypted folder is synced unencrypted to 3 hosts and encrypted to 5 more hosts.


The 3 unencrypted can sync the whole set of folders and files ( ~ 158Gb), the other 5, at some point fail and stop to sync with similar messages:


[20170109 06:54:00.802] PC[0x00007f0d682a38e0][0x00007f0d607ecf80][] disconnect - reason: "Is seed", wb: 0, error: 0, ref: 0
[20170109 06:54:00.909] JOURNAL[8603]: Mutex file check failed with error : 103
[20170109 06:54:01.170] JOURNAL[8603]: Mutex file check failed with error : 103
[20170109 06:54:01.170] JOURNAL[4AB2]: Mutex file check failed with error : 100

with version 2.4.4 on all ends (some 32 bits, others 64) and a qnap running arm version of binary.

I was able to start syncing from '0' on an encrypted peer (empty folder) until some point where it just stops and one of the curious things is that different hosts show different number of missing files to do a full sync.

Have you figured out what's going on?

Share this post

Link to post
Share on other sites


By "something similar" you mean that "Mutex file check failed" error ? cause other than that I don't see any errors from those 4.5 log lines. 
Mutex file check failed with error means either of these two problems:
such folders cease syncing.

Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.