• Content Count

  • Joined

  • Last visited

About ThePoet

  • Rank
  1. I don't know about your setup/install process, but for me, if you load rslsync with a config file, you can set a custom path: "storage_path" : "/some/config/dir/.sync", If you do not, the home dir of the loading user is used: /home/{user}/.sync I'm not saying that this is enough, and I don't even know if what you want to do is possible (I would assume not..), but it does contain your sync and history dat files, your License folder, and various .SyncUsernnnnnn folders and db/journals. I suspect it is probably safer to re-index either way, though. (I do not work for resilio and
  2. I only seem to get this issue when I kill and re-start the sync after syncing huge amounts of data. I'd be interested to know if it happened to your Windows box upon restarting. Also, have you restarted the sync on your Ubuntu machine since syncing large amounts of data?
  3. No no no, you are not listening. The above was just a copy and paste error from the wrong box while, ironically, showing you the config was not the problem. I am sorry that I copied my example from my 3rd box and confused you. The configs are 100% correct. If they were not, then the server would never work, and they have been working for years (apart from when this bug happens). When you say "It shall not be related to transferring a lot of files" can you please tell me what you have done to verify that this is the case? Have you actually run tests with several TB of data? Because transfe
  4. Ahh yes, sorry. I was copying from a different machine. The config in the script is correct. One of my syncs (which was originally on btsync) has a path of ~/Programs/btsync/btsync.conf, my new box is ~ /Programs/rslsync/rslsync.conf - I have edited my post to avoid confusion - a simply copy/paste error It's important not to get hung up on the config because I have been running with this for ages and it is most definitely not the problem. I didn't submit a support ticket last time, I just sucked it up and re-indexed, as with the other times it has happened. It is not until now that
  5. Hey Helen, thank you for your response. The storage path is set in the config like this: "storage_path" : "/home/user/.sync", I understand this is also the default location. The full config can be found in the linked post. I kill the process with "pkill rslsync", which sends the kill signal to the process and it gracefully shuts down. I wait for the web UI to time out, and for the hard drive activity indicator light on my array to stop blinking. After those two events I usually give it 10 to 30 seconds before starting the sync again, just in case there is any residual disk act
  6. 1. This started happening to me after migrating to 2.4.1 4. I can recreate this by adding a new server to the sync and copying a few TB of data. Restarting the sync on both servers appears to corrupt or somehow invalidate the sync.dat file, which in turn causes the lost identity. Do you recall if you had not restarted the sync for a while, or if you had copied large volumes of data before this happens? A friend of mine had a similar issue when he had 100,000+ files indexed.
  7. So I have around 30 to 35 thousand files under management across 20 synced folders for different data categories. All of these files are binary (video content from GoPro and other raw HD/4K sources) with file sizes averaging between 500mb to 5GB. My working assumption is that each time I sync more than 5 or 6 TB of data from one server to another, the sync.dat file corrupts on BOTH servers when shutting down the sync. The logs are showing that the shutdown was completed successfully, but on restarting I see the message "Unsupported or empty sync.dat file." in the logs (see attached logs (which
  8. The linked post "[Solved] Request Denied" spoke of checking the sync.log files after enabling debug logging. It might be worth doing that, attempting to re-link, noting down the time, and then checking to see if anything stands out in the logs around that time period.
  9. Hey Helen, I have almost finished re-indexing everything, so I do not want to retry using the --storage argument. I'm almost 100% sure that the sync is still using the /home/xxxxxx/.sync directory, because it is still logging to there. I have found the logs which I've cut to only include Oct 20 22:12 (5 minutes before I restarted and replaced 2.4.0 with 2.4.1, when everything was working fine) to 09:36 the next day, which is the point where I started to re-add my shares after a second instance where it removed my license. 20161021 09:36:22.860] [OnNotifyFileChange] "/home/xxxxx/.
  10. Hey Helen, Thanks again for your response The first thing I did was check the permissions of the new binary because literally the only thing that changed was the binary. I was using the same user as always, in the same folder, with the same permissions. The permissions on the 2.4.0 and 2.4.1 binaries are both still -rwxr-xr-x (when I update, I keep a copy of the old binary just in case) as they always have been. The raid array that my data is synced to has 1.1TB free storage, with no change to permissions. The env variable also hasn't changed - it simply points to my users home
  11. Hi Helen, Thanks for your response. This is exactly what I did, and I had an issue. When I was using 2.4.0, I had manually downloaded it. The same is true for 2.4.1. I simply replaced the 2.4.0 rslsync binary with the one from the 2.4.1 download. The config has not changed between versions. I always launch with the same launch script, which looks like this: $HOME/Programs/rslsync/rslsync --config $HOME/Programs/rslsync/rslsync.conf I know the config is still being picked up because I am still being prompted for my username and password for the web interface.
  12. Hey all, Updating to the latest sync has removed my pro license and all of my shares. I'm running the latest rslsync (2.4.1 (672)) which I updated from 2.4.0 (666) today I downloaded 2.4.1 from: I am running Linux (Ubuntu 14.04.5 LTS (GNU/Linux 3.16.0-70-generic x86_64)) I paused all of my shares, waited for all syncing to stop, I did a pkill on the process, and then I updated. After updating, I relaunched via the command line with my previous config (see below: xxx represents removed config data)