innerand

@iranzo Can you find (many) "FAILED HASH CHECK" in the logs from hosts with encrypted folders?

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)?

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.

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.

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 attached. Many thanks for your support! Setup V-Server: platform: Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 version: 2.4.2.708 Nas: platform: Linux 3.16.0-4-kirkwood #1 Debian 3.16.36-1+deb8u2 (2016-10-19) armv5tel version: 2.4.2.708 Logfiles vserver: [20161206 12:20:11.310] TF[B140] [0x00007f2fec00bbe0][/home/rslsync/shares/sync/UPBWW6NDNON4BVATGDQ53XO3QLABMZKYQM3CBHU4FS762DNIFFZ45FIIV62EEXCXA5L563TAI4ZJ4OCHOJ3J3VOXKGRUYYLZXUPB3VA5T5EXSI4RFNFRDW5BFALKZG3GWY6KRAM7WY66XDSPXSTSXTIANQXXGQ53S6IOM5VBTVOWX42DW7RXITYAOMEF52M6RUO6EGA26BTEVLKXLS5AN4KMGE]: state:DOWNLOAD error: meta:1 conns:1 io:0 [20161206 12:20:11.310] PD[B140] [6D82]: Sending ping to "192.168.1.10:60064" [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.395] TF[B140] [0x00007f2fec00bbe0][/home/rslsync/shares/sync/UPBWW6NDNON4BVATGDQ53XO3QLABMZKYQM3CBHU4FS762DNIFFZ45FIIV62EEXCXA5L563TAI4ZJ4OCHOJ3J3VOXKGRUYYLZXUPB3VA5T5EXSI4RFNFRDW5BFALKZG3GWY6KRAM7WY66XDSPXSTSXTIANQXXGQ53S6IOM5VBTVOWX42DW7RXITYAOMEF52M6RUO6EGA26BTEVLKXLS5AN4KMGE]: *** PIECE 155 FAILED HASH CHECK [20161206 12:20:11.395] TF[B140] [0x00007f2fec00bbe0][/home/rslsync/shares/sync/UPBWW6NDNON4BVATGDQ53XO3QLABMZKYQM3CBHU4FS762DNIFFZ45FIIV62EEXCXA5L563TAI4ZJ4OCHOJ3J3VOXKGRUYYLZXUPB3VA5T5EXSI4RFNFRDW5BFALKZG3GWY6KRAM7WY66XDSPXSTSXTIANQXXGQ53S6IOM5VBTVOWX42DW7RXITYAOMEF52M6RUO6EGA26BTEVLKXLS5AN4KMGE]: sending bad piece 155 to peer [6D82] nas: [20161206 12:20:11.415] PC[0xb483aab8][0xb3e63360][138.201.92.183:60064:TUNNELL] 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 nas-sync.tar.xz vserver-sync.tar.xz