innerand Posted December 6, 2016 Report Share Posted December 6, 2016 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 Quote Link to comment Share on other sites More sharing options...
innerand Posted December 6, 2016 Author Report Share Posted December 6, 2016 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. Quote Link to comment Share on other sites More sharing options...
Helen Posted December 7, 2016 Report Share Posted December 7, 2016 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. Quote Link to comment Share on other sites More sharing options...
innerand Posted December 7, 2016 Author Report Share Posted December 7, 2016 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. Quote Link to comment Share on other sites More sharing options...
Helen Posted December 9, 2016 Report Share Posted December 9, 2016 cannot repro in the lab. will take close looks at the logs. Quote Link to comment Share on other sites More sharing options...
Helen Posted December 12, 2016 Report Share Posted December 12, 2016 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. Quote Link to comment Share on other sites More sharing options...
innerand Posted December 14, 2016 Author Report Share Posted December 14, 2016 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)? Quote Link to comment Share on other sites More sharing options...
iranzo Posted January 9, 2017 Report Share Posted January 9, 2017 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: EU4FYUQHKNAO4MJGYCPYKSN3SVLIT73XRYQBYYY/OPVPZWOW5C6NQBRICAHUDSGD54/3KDQ4FMA5RYFMMJWLE4RDOUBVA/X4AHX4NRBNSLI5SWGQ7KCHEXOE/JQOOQTUW42VVYEIKCWA2UHORAXE7PIT2U4J4ZTBBX7MCLFMTYVGYDWR5IH636UF5ANYSTD57KA23O/2D2IYQ2DOUNBBZOCWXIOYNKQL4]: state:SEED error: meta:1 conns:1 io:0 [20170109 06:54:00.802] PC[0x00007f0d682a38e0][0x00007f0d607ecf80][147.156.98.243:59999:TUNNELL] 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? Quote Link to comment Share on other sites More sharing options...
Helen Posted January 9, 2017 Report Share Posted January 9, 2017 @iranzo, 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: https://help.getsync.com/hc/en-us/articles/205450225-Error-103-Service-files-missinghttps://help.getsync.com/hc/en-us/articles/205450255-Folder-not-found such folders cease syncing. Quote Link to comment Share on other sites More sharing options...
innerand Posted January 11, 2017 Author Report Share Posted January 11, 2017 @iranzo Can you find (many) "FAILED HASH CHECK" in the logs from hosts with encrypted folders? Quote Link to comment Share on other sites More sharing options...
iranzo Posted March 7, 2017 Report Share Posted March 7, 2017 For completeness, this was an issue that was being investigated and solved with a newer update (not sure if yet released) Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.