RomanZ

@patoka Could you please elaborate how exactly it failed? Some error message? Just did nothing? Also, which version you are trying to upgrade from?

Hi Tim, While the part looks to be rather confusing for me. Though, here is what I understand from your setup: 1. The worst bandwidth on the path from your peer in China to US is 100Mbit down and 2Mbit up. This immediately caps us to maximum upload speed of ~240Kb/sec., while download speed should be fine. 2. You've got 2 NATs in China with dynamic IP which changes every 2 days, therefore direct connection from US to China is not possible: Sync can automatically penetrate only one NAT layer. 3. You've got 1 NAT which you control in US with static IP. 4. The connection as it is is not stable. Some things that I need to get more info on: A. Did you: - specify IP of your US NAT on China peer predefined hosts? - port forward the listening port of your US peer from USA NAT to actually peer? This should give China peer an ability to connect directly to US peer. Having at least one direct connection will allow you to utilize bandwidth. B. What are the versions of your clients? Must be 2.3.7 or later - there was a nasty connectivity issue in 2.3.6 and before, which only pop up in complex setups like yours. C. Monitor if connection goes via relay. Here is the screenshot on how releayed connection looks like.

@laurin1 Indeed, Sync archives the file only if change arrived from different peer. For example, if peer A changes the file, it'll appear in Peer B archive. But not in A's archive. Also, if B never got the file before you deleted it on A, file will never appear in B's archive also.

@jdh It's actually bad idea to set config_save_interval to 100 days. The config contains a lots of valuable data - users which were approved and declined by you, your folders, etc. If Sync is killed ungracefully or crashes - all this data could be lost and actually, will spawn lots of really strange and hard-to-debug issues. I'd advise to set it to once per day (once per 2 days the rarest).

Ok, then we need debug logs from both your peers involved. Reproduce issue, collect the logs, submit a request to us - we'll see what's going on there. While submitting, mention this forum topic in message body.

Cool. So what about files that are below 1000Mb? Are they archived as expected in your case?

@laurin1 It's not just folder_defaults. Take a look at folder properties. Also, no need to test with very small files. As soon as file is smaller than 1000Mb it should be archived and versioned as designed.

@Andy+ Please see our Synology article on KB - 2.3.8 is available for DSM 5.2 now. @geewiss Ok, our support will assist.

@jdh Could you please send me debug logs? We'll take a look why Sync saves sync.dat that often.

@Kay We did not push 2.3.8 to automatic update yet, therefore it is not working.

@Chameleon First couple of things to check: 1. Permissions. Your Sync should have full access to folders it Sync. 2. Connectivity. Does Sync UI shows that both peers are online? 3. Some time. Did you give Sync 10+ minutes? Sometimes, OS notifications may not work (especially, on large array of files, therefore Sync will only detect file changes during full rescan, which happens every 10 minutes by default (and may take rather long if you have 100K+ files).

@QuaCKeReD Sync 2.3.7 and 2.3.8 is compatible to DSM6.0. It is not officially confirmed by Synology - therefore you get the warning (and don't see Sync in official synology apps). We are working with Synology representatives to get it solved, though progress is very slow. It doesn't only depends on Resilio, but also on Synology, so I cannot provide you ETA for now.

@laurin1 Could you please check if the archive option is enabled in your folder preferences? Also note, that bigger files (1000Mb and more) are note saved to Archive to avoid hogging your disk space. This behavior can be changed by adjusting the "max_file_size_for_versioning" Power Option.

Sync uses UPNP/NAT-PMP to forward listening port to itself (i.e. port it uses to transfer data), but not the WebUI port. If you want to access WebUI port from outside of your router, you'll have to do a manual port forwarding or use some other tools if your NAS has dynamic IP.

@Kay 2.3.7 and 2.3.8 contain all the fixes that we had for high CPU usage issue. If you are running one of them - could you please collect your debug logs and send them to me?

@jdh 1. Yes, it is absolute path. All the WDMyCloud devices I encountered had the same path, although I suspect that some devices may have the "HD_a2" component be replaced with something else. The debug.txt file should already exist if you found Sync's settings folder correctly. All you need to do is to change its content and restart Sync to ensure it is not writing any logs (and disturb dozing HDD ) Sync is using regular POSIX API to access files, so I believe you can make symlink and place debug.txt in any place you want, but I see no big point as the dir we are looking for is the dir designated by WD to store Sync's settings. 2. You can grab new package here.

Tim, 2 things: 1. How slowly it proceeds? Is it 50Kb/sec? 500Kb/sec? 5Mb/sec? 2. Could you please check if connection goes directly or via relay? There are couple more tricks we can try to improve speed, though we need to understand where do you stand.

@Guentha Archives are vital to avoid re-downloading: sometimes it happens that OS itself first sends "delete this file" events, and later "hey, here is a new file" events, so Sync sends them to all other peers in separate blocks. If archives are enabled, Sync will pull files from archive instead of re-downloading them. Could you please try to turn archives on, and set Power Option "sync_trash_ttl" to "1"? This will force to keep archives only for 1 day and at the same time should return you files movements. Let me know if it helps.

Craig & all, Both 2.3.6 and 2.3.7 has a known issues causing to disconnect all the folders. It usually pops up when some device which stayed long time offline connects. I'd advise to upgrade to 2.3.8.

@BryanPlatt It is by design. Files status and progress only shows for Selectively Synced folders.

@Guentha Which version of Sync do you use? Also, do your have Archives enabled? Also, what is the average size of files you sync?

@JQCaffeine Couple of things to check: 1. Check if there is any connectivity between phones at all. Ping is ideal if you got a terminal on your phone. 2. Ensure that both apps on both phones are brought to foreground. Sync for android unloads core for 30 minutes to save power if app is in background. So technically, 2 apps on 2 androids may never meet if they started with a time shift.

@jdh Do also couple more things: 1. Put "0" value to "debug.txt" file. It should be in "/mnt/HD/HD_a2/Nas_Prog/BitTorrentSync/settings" for WD. 2. Upgrade your Sync to 2.3.8 - there was a bug in whole 2.3 preventing NAS devices from sleeping. Let me know if it helps.

Dear community, Sync 2.3.8 is now available. You can get it via direct links below, via official download page or via "Check now" button. Build is not yet available via auto-update. Direct Download Links: Installer for Windows: x64 installer, x86 installer Package for OS X: OS X package Gzip archive for Linux: arm, armhf, i386, x64, glibc23_i386, glibc23_x64 Gzip archive for FreeBSD: i386, x64 A list of what's new, improved, changed, and fixed in this version is available in the change log. Latest Android build is now also available via direct link: 2.3.5 APK Latest Raspberry Pi package is available via direct link: 2.3.8 DEB Known issues and peculiarities: - Linux users please note: starting from 2.3.0, Sync now creates and uses storage folder (.sync folder) in current directory, not next to binary - Upgrading from 2.3.0-2.3.3 may remove your identity and folders. It is strongly advised that you backup your storage folder prior to upgrade to 2.3.8.

@Gorn We've reproduced it in lab and are on it. Hopefully, we'll find out what has changed in Arch that causes crash. Stay tuned for updates.