atomicbird

Members
  • Posts

    13
  • Joined

  • Last visited

atomicbird's Achievements

Member

Member (2/3)

  1. I'm running Resilio on a new Raspbian install. It works when I start it, but after a reboot it runs but doesn't seem to do anything. When the system starts up, ps shows that Resilio is running with the following command: /usr/bin/rslsync --config /etc/resilio-sync/config.json However syncing doesn't work and the web GUI doesn't respond (and nc shows connections refused for web GUI). It sure looks like it should be running but nothing happens: $ sudo systemctl status resilio-sync ● resilio-sync.service - Resilio Sync service Loaded: loaded (/lib/systemd/system/resilio-sync.service; enabled; vendor preset: enabled) Active: active (running) since Sat 2021-05-22 00:36:31 BST; 1min 13s ago Docs: https://help.resilio.com Process: 379 ExecStartPre=/bin/mkdir -p ${SYNC_RUN_DIR} ${SYNC_LIB_DIR} (code=exited, status=0/SUCCESS) Process: 384 ExecStartPre=/bin/chown -R ${SYNC_USER}:${SYNC_GROUP} ${SYNC_RUN_DIR} ${SYNC_LIB_DIR} (code=exited, status=0/SUCCESS) Process: 389 ExecStart=/usr/bin/rslsync --config ${SYNC_CONF_DIR}/config.json (code=exited, status=0/SUCCESS) Process: 403 ExecStartPost=/bin/sleep 1 (code=exited, status=0/SUCCESS) Main PID: 402 (rslsync) Tasks: 17 (limit: 725) CGroup: /system.slice/resilio-sync.service └─402 /usr/bin/rslsync --config /etc/resilio-sync/config.json May 22 00:36:28 zeroone systemd[1]: Starting Resilio Sync service... May 22 00:36:31 zeroone systemd[1]: Started Resilio Sync service. If I restart Resilio with sudo systemctl restart resilio-sync ...then everything's fine. What's going on at startup, and how can I get it to start normally? Thanks.
  2. 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.
  3. 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: https://help.resilio.com/hc/en-us/articles/204753629-Conflict-files-in-Sync The Macs don't report any problems, although "status" on them stays at 100% without ever quite finishing. What can I do about this? I'm attaching a screenshot of the error shown on the Ubunto host.
  4. 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_l5t7InMiOiJzMyIsImIiOiJhZG4tdXNlci1hc3NldHMiLCJrIjoiYXNzZXRzL3BhZ2UvNzYvNzAvMDAvNzY3MDAwMDAwMDAwMDAwMC5wbmciLCJvIjoiIn0-3777.png" In my case all conflicts were for files in the same directory on the Macs. I resolved it by deleting the directory (which I didn't need anymore anyway).
  5. 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.
  6. 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 finished syncing, and is using 14GB of space for the same shared directory, which its web UI also reports as having 12.95GB of data. I don't know what the original Resilio install is doing with that extra 22GB of space. Since it's a VPS I'm just going to destroy the instance and forget about it. If I ever need to move a shared folder in the future, I'll set up a new VPS instance and let it sync rather than try to move the existing directory. However, if anyone knows the correct way to move a directory, or has any theories on why my move resulted in needing more than 150% extra disk space for the same shared directory, I'd love to hear about it.
  7. 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.
  8. 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?
  9. 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 https://help.getsync.com/hc/en-us/articles/206178924-Installing-Sync-package-on-Linux 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 the Linux web UI Selected the directory where I had copied the files back in step 2. Now there are a couple of things that have me concerned. The "indexing" step seems to be taking an extremely long time. On my Mac Resilio reports the size as 12.95GB. In the Linux web UI it's gradually growing. But, a little over 5 hours ago it was at 3.53GB and now it's at 4.03GB. At this rate indexing will take several days. Is this normal? The system is not maxed out for CPU, disk access, memory, or bandwidth, so what's holding it back? My Mac reports that the total data size is 14.51GB, but on the Linux box the total file size (from "du -sh") is currently at about 26GB and growing. It's kind of a race to see if the indexing finishes before the partition runs out of space, which is odd since it's already using nearly 2x the space I'd expect. Can anyone offer suggestions or advice on this? Did I screw something up, and if so what should I have done differently?
  10. 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.
  11. 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.
  12. 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 well. So what, basically, the hell? The Macs are both on the same LAN. Sharing worked great at first but then inexplicably just stopped. Do shares just give up and die? Is there something I could look for in the logs that might give me a clue?
  13. 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 makes a difference, the working sync folder has about 36MB total, while the broken one is roughly 810MB.