• Content Count

  • Joined

  • Last visited

About atomicbird

  • Rank
  1. Slight update, the Macs not quite reaching 100% seems to be unrelated. I fixed that after reading this forum message, but the conflict on the Ubuntu side still exists.
  2. I have a share on two local Macs and one Ubuntu VPS, all running Resilio 2.6.3. The Ubuntu host is reporting a conflict file in its web UI. But it's using an encrypted key, so while I know that the affected file is called "CMRQCTHMAJJVPK2..." [246 characters long] I have no idea what file(s) on the Macs are related to this, or what to do about it. There's an "Ignore" button but I don't know what effect that would have. The "more info..." link in the error takes me to this page, which doesn't look like it's helpful in my case:
  3. I just had the same problem when setting up a share on an Ubuntu VPS. I fixed it using the process described by @bratten (thanks), but in the spirit of providing more information: The Ubuntu server is running 2.6.1 (1319), (installed as described at Resilio's site) with Ubuntu 16.04. It uses an encrypted key and showed the conflicted files in its web UI. The folder is also shared on two Macs, also running 2.6.1 (1319) on mac OS 10.13.6. They use read/write keys. A sample long filename apparently causing trouble: "HIYsdOFEuPMf5x7PXgZIhkz_l5t7InMiOiJzMyIsImIiOiJhZG4tdXNlci1hc3N
  4. I don't recall if I saw those warnings. Since there's no documentation on moving to a new directory, I guessed (incorrectly) that entering the same key would mean that Resilio could re-scan the contents. I didn't expect Resilio on Linux to automatically follow the share, I was trying to tell Resilio how to find it. Assuming that I did see those messages, I'm not sure why Resilio left the existing files in place if the message warns that they'll be overwritten. It would be useful if this were explained somewhere, so as to help people from making the same mistake in the future.
  5. I sort of got through this, but in the absence of better advice, I have to say that if you need to move a shared directory to a new location, just don't. You'll be better off creating a new copy and letting it sync. In the case of my problem sync, described extensively above: I expanded the dedicated partition to 40GB. Eventually it completed. However, it's using 36GB of space on the partition for a shared directory that the web UI reports as containing 12.95GB of data. Since that seems ludicrous, I set up another Linux VPS with Resilio and added the encrypted key there. It has now f
  6. As of just now, Resilio ran out of space on its partition. It's a 30GB partition, and Resilio on my Mac reports that this shared folder contains 12.95GB of data. I would have thought that setting aside >2x the expected requirement would be more than enough, but apparently not. This partition on the Linux box doesn't have anything else on it, only Resilio sync data. Can anyone tell me what I should have done to move my working shared directory to a new location? I assume that I screwed up somewhere but I don't know where.
  7. To update this, shortly after posting, the Linux share started uploading files from my Macs instead of simply reindexing its own files. I had thought that my steps to move to a new directory would do the job without needing to re-upload most of the data, but it looks like I was mistaken. The partition I'm using doesn't have enough space to hold the >10GB of files still not accounted for. This is looking like a disastrous failure. Where did I go wrong?
  8. A few days ago I needed to move a shared directory to a new location, since the old location was running out of space. This is on Ubuntu 16.04, and it's using an encrypted key. I initially set up Resilio using the steps described at To move the store I did this: Used the Linux web UI to disconnect and remove the existing location Copied the contents of the share directory using "sudo cp -a [old location] [new location]" Copied the encrypted key from Resilio on my Mac, and entered it in
  9. Still seeing this with 2.0.105 running on OS X 10.10.3. According to "peset -g assertions", BitTorrent Sync is preventing system sleep. I turned off debug logging, since some people mentioned that, and relaunched the app. No change, though.
  10. But did this last? I've had the same kind of problem, and rebooting and/or restarting the sync app gets things going... for a while. Pretty soon it's right back to "out of sync" though.
  11. I wrote to support about this and they requested debug logs, which I sent, but I haven't heard any more. Support also seemed to think that the Linux node might be part of the problem. They didn't say so specifically but mentioned it several times in their response. So I tried creating a new share between just the two Macs, with no other machines connected. I used rsync to copy over everything from the broken share to the new one (except for the .sync/ directory) to the new one. I also upgraded the Mac client to 1.4.93. The new share worked great! For a day or so. Now it's out of sync as we
  12. I have the following setup: Two Macs, on the same LAN, running Bittorrent Sync 1.4.91, using a read/write keyOne Linux box, remote, running 1.3.109, using an encrypted read-only keyI've configured two sync folders between these devices. One sync folder works extremely well. Syncing is quick and reliable. One sync folder isn't working at all-- the Macs simply show it as "Out of sync", even though they can ping each other via their local IP addresses. Where do I even start looking to figure out why one works and one does not? The peers obviously connect, but only for one sync folder. If it