sciurius Posted December 22, 2016 Report Share Posted December 22, 2016 Yes, this is an oldie: 1.4.111 running on Synology DS413, but the newer versions are not supported on this architecture. One of my RO shares stopped synching recently and I cannot get it to work anymore. I get lots of messages in the log like these: [20161222 12:25:24.083] SF[1BA0] [4899]: Going to sync state with peer xxx.xxx.xxx.xxx:xxxxxx [20161222 12:25:24.157] MC[1BA0] [4899]: generating intial request with root 0000000000000000000000000000000000000000 [20161222 12:25:24.303] SF[1BA0] [4899]: Received request "id" [20161222 12:25:24.303] SF[1BA0] [4899]: Got id message from peer XXX (XXXXXXXXXXXX) 1.3.109 [20161222 12:25:24.304] SF[1BA0] [4899]: Received request "peers" [20161222 12:25:24.304] SF[1BA0] [4899]: Received request "root" [20161222 12:25:24.304] MC[1BA0] [4899]: processing root message, remote hash XXXXXXX, timediff: -6 [20161222 12:25:24.304] MC[1BA0] [4899]: requesting nodes for root [20161222 12:25:24.512] SF[1BA0] [4899]: Received request "nodes" [20161222 12:25:24.512] MC[1BA0] [4899]: processing nodes message for / [20161222 12:25:24.512] MC[1BA0] [4899]: will request files for /Folder1* [20161222 12:25:24.512] MC[1BA0] [4899]: will request files for /Folder2* [20161222 12:25:24.512] MC[1BA0] [4899]: will request files for /Folder3* ... several more ... [20161222 12:25:24.514] MC[1BA0] [4899]: sending get_files message [20161222 12:25:28.261] SF[1BA0] [4899]: Received request "files" [20161222 12:25:28.261] MC[1BA0] [4899]: processing files message with 1000 files [20161222 12:25:28.708] MC[1BA0] [4899]: failed to verify group signature of files message, aborting [20161222 12:25:28.712] SF[1BA0] [4899]: State sync finished This happens with most of the peers. Some peers report failure on a specific (but always the same) document: [20161222 13:42:26.170] MC[1BA0] [E88D]: sending get_files message [20161222 13:42:26.827] SF[1BA0] [E88D]: Received request "files" [20161222 13:42:26.827] MC[1BA0] [E88D]: processing files message with 1000 files [20161222 13:42:29.997] MC[1BA0] [E88D]: failed to verify signature of remote file Folder4/Document1.odt, aborting [20161222 13:42:29.999] SF[1BA0] [E88D]: State sync finished I have removed the share, re-created it, restarted btsync, re-installed btsync after removing the config directory, and so on. Several times. At first I thought I was running out of memory (it's a NAS) but given the second type of failures I'm not sure. Any ideas what may be going on here? I have no control over the peers, I'm just a leecher (so to say). I installed sync on a different PC and it works fine. But I would like to have it running on the NAS, as it has been done for a couple a years now. Quote Link to comment Share on other sites More sharing options...
Helen Posted December 23, 2016 Report Share Posted December 23, 2016 if you search forum for "failed to verify signature of remote", you will find a lot of threads discussing, explaining this and suggesting the fix. the thing is that file signature (for example , Folder4/Document1.odt), or the group's of files signature cannot be checked. For example, a non-utf symbol in the name, or an invalid attribute. try renaming the entries or check their timestamp. Quote Link to comment Share on other sites More sharing options...
sciurius Posted December 23, 2016 Author Report Share Posted December 23, 2016 Thanks for taking the time to address my question. In the mean time I have been able to reproduce the problem with sync 2.4.4. I did search the forums before posting my question, but all suggested fixes seem to be not applicable to my sync. For example, the offending document Folder4/Document1.odt is not on my system (and shouldn't be part of the share anyway since it was removed weeks ago). What to do with "failed to verify group signature of files" is even a bigger mystery. Do I understand correctly that if just one of the participants manages to corrupt a filename, this basically blocks the whole synching process? Quote Link to comment Share on other sites More sharing options...
Helen Posted December 23, 2016 Report Share Posted December 23, 2016 despite the Sync's version, file's signatures remain the same. These "failed to verify signature" lines mean that folder tree cannot get merged, so it's all stucks, yes. But still "Folder4/Document1.odt" cannot get merged as well. And if it was removed, then it's removal cannot get merged and verified. Was it removed from all peers? 1 hour ago, sciurius said: What to do with "failed to verify group signature of files" is even a bigger mystery. Look at the enties above - these are the "group" which the error line refers try also renaming them: Folder3 -> Folder3 will be ok. Else, try putting a file to their parent folder and restart Sync. A quick fix would be to remove the share from Sync and add again. Signature will get recalculated. Quote Link to comment Share on other sites More sharing options...
sciurius Posted December 23, 2016 Author Report Share Posted December 23, 2016 Thanks for your patient reply. Removing the share from the sync and add again does not help, within seconds the "failed to verify signature of remote file" messages start flowing in again. And rslsync has been running at 100% cpu since... As for the suggestion of trying to rename the offending files/folders: these are not in my share. These have been removed from the share many weeks ago. So I do not know what to do. Quote Link to comment Share on other sites More sharing options...
sciurius Posted December 23, 2016 Author Report Share Posted December 23, 2016 FWIW, each abort message is followed by assert failed /opt/sync/SyncFolderMergeController.cpp:916 To me, an "assert failed" at least hints at a software problem, not a user problem. Quote Link to comment Share on other sites More sharing options...
Helen Posted December 26, 2016 Report Share Posted December 26, 2016 because of failed merge the assert also fails. So this assert is a symptom, not the cause. Ok, are these entries absent from all peers? and did you remove the share from Sync on all peers? If yes and yes, then Sync will have no where to take them from. And once they are still in the logs, it means that either of "yes" is actually "no" - these stuck entries are still somewhere there, or you did not remove the share from all peers Quote Link to comment Share on other sites More sharing options...
sciurius Posted December 26, 2016 Author Report Share Posted December 26, 2016 I think the message is clear: once there are bogus entries on one or more peers, the synching process for everyone becomes crippled and may even come to a standstill. Currently over 75% of the peers seem to be 'infected'. Also clear is that there is nothing I can do, since I have no control over the peers. I can't even blacklist infected peers. It looks like the only option is to ask the share masters (the ones with A-codes) to discard this one and start a brand new share with a new code. Quote Link to comment Share on other sites More sharing options...
Helen Posted December 27, 2016 Report Share Posted December 27, 2016 Well, then if re-sharing is troublesome, you could try and put a file into the parent directory of those Folder 1- 3 on the source peer. And I'd also suggest updating XXX peer from Sync 1.3.109 to latest. V1.3. is quite outdated. Quote Link to comment Share on other sites More sharing options...
sciurius Posted December 28, 2016 Author Report Share Posted December 28, 2016 Thanks for the update suggestion. Unfortunately, Resilio Sync stopped providing binaries for Synology DS413 so I'll have to use this one. Quote Link to comment Share on other sites More sharing options...
Helen Posted December 29, 2016 Report Share Posted December 29, 2016 the latest Sync for qoriq is 2.0.85, you can download the binary from here http://syncapp.bittorrent.com/2.0.85/ Quote Link to comment Share on other sites More sharing options...
sciurius Posted December 29, 2016 Author Report Share Posted December 29, 2016 I seem to recall that 2.0 ('free' version) had a limitation in the number of folders that could be shared, a limitation that was lifted in later versions. Is that correct? Quote Link to comment Share on other sites More sharing options...
Helen Posted December 30, 2016 Report Share Posted December 30, 2016 Yes, correct. Quote Link to comment Share on other sites More sharing options...
sciurius Posted December 30, 2016 Author Report Share Posted December 30, 2016 I guess I have to keep using 1.3 then :( . Quote Link to comment Share on other sites More sharing options...
sciurius Posted January 14, 2017 Author Report Share Posted January 14, 2017 The latest Sync for qoriq (2.0.85) seems to be a 30 day trail... of what? 14 days left... What happens when the trial expires? Quote Link to comment Share on other sites More sharing options...
Helen Posted January 16, 2017 Report Share Posted January 16, 2017 On 1/14/2017 at 3:04 PM, sciurius said: 30 day trail... of what? of Pro. On 1/14/2017 at 3:04 PM, sciurius said: What happens when the trial expires? Answered here. But I thought you decided upon 1.3.? Quote Link to comment Share on other sites More sharing options...
sciurius Posted January 16, 2017 Author Report Share Posted January 16, 2017 Thanks for your patient answers. I'm trying to work out what is the least worse of options... 1.3 with many bugs, 2.0.85 with less bugs, but crippled, or buying a new NAS so I can run 2.4 and stay up to date. 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.