yottabit

Put your logfile in a BTSync share and e-mail BT your Secret?

What's stopping you? I have Dropbox participating in a BTSync share by way of Junction Point in Windows. When (following) symlink support is added, you should have this functionality in Linux/FreeBSD, too. You could also just share the DropBox directory directly. If you are having a problem with this, start a new topic and the community will help. If you want to know how I'm using Junction Point in Windows, search for 'junction point' in the forums. You'll find my post detailing how I used them to backup only parts of a Windows Profile.

Hi josiahsprague. Starting with build 128 there is now a native FreeBSD 8.x version that I have run successfully on FreeNAS 8.3.1-p2. I have successfully run build 128 and 130. There was a reported problem of build 131 crashing on FreeBSD but I haven't confirmed myself. (Build 131 isn't officially released yet.) However, if you still want to run BTSync on Linux with a mountpoint to a NAS like I have (FreeNAS in this case), here's what I did. Create a dataset on your NAS and export to CIFS. (I used CIFS instead of NFS because of the known problem on FreeNAS where NFS is always run in sync mode even when you explicitly set to async, which causes a dramatic slowdown since it works counter to the method ZFS employs with extensive caching.) Mount the export on Linux. I did this using /etc/fstab. Note that I'm also mounting as root, and running BTSync as root. You probably shouldn't do this. You would want to adjust the permissions on the mount point to make it writeable by whichever user under which you choose to run BTSync. //nas1.domehq/btsync /mnt/btsync cifs credentials=/root/btsync.cred,rw,uid=root,gid=root,forceuid 0 0 Place your Linux btsync binary wherever you like, including within the mountpoint if you like. (I put mine in /root but will probably move it to the mountpoint at some point. Just remember that due to meta cache storage, you should not share the directory in which the binary runs.) Configure BTSync. /path/to/btsync --dump-sample-config > /path/to/btsync.conf nano -w /path/to/btsync.conf Add BTSync to your rc.local init script for auto start. echo 'nice -n 19 /path/to/btsync --config /path/to/btsync.conf' >> /etc/rc.local Start BTSync from init script, or manually. /etc/rc.local start or nice -n 19 /path/to/btsync --config /path/to/btsync.conf Note that I used 'nice -n 19' to run BTSync as lowest priority, giving up its cycles to other applications when needed. This isn't perfect though, since if you're running BTSync to a non-SSD, or to a multi-disk array that isn't served by a high quantity of disks, the indexing process will still be largely I/O bound and cause detrimental performance. However, running this indexing of a remote mount will probably keep the local Linux system responsive since its local disks won't be I/O bound. Hope this helps!

Have you considered creating a chroot jail yourself and running BTSync within? I haven't tried it, but this may work... http://ubuntuforums.org/showthread.php?t=1156240

I think that fix had to do with an exploit that would allow BTSync to access files outside of the shared directory. It is unrelated to your issue.

Well looks like you have the right binary for your system. Maybe try 128 and/or 130 to see if that's better? Those worked for me without any fuss.

Post output of 'cat /etc/version; echo; uname -a; echo; file btsync; echo; ./btsync --help | head -n 1' so BT can have all the details of your system. Build 128 and build 130 run fine on mine: EDIT: corrected to /etc/version.

Build 131 hasn't been officially announced yet on the forums, so it's just a test build to see if it fixes specific problems users are encountering. I just updated my FreeBSD/FreeNAS to build 130 from 128. I'm not going to update again because I want to see the auto-update mechanism work when BitTorrent officially releases. Build 128 was the first FreeBSD build. I'm sure Build 116 is still the most prevalent version "in the wild" because BitTorrent hasn't pushed the newly released Build 130 into the auto-update mechanism yet.

Search the forums, read the forums, read the official and unofficial FAQ, and read the instructions on the download page. It's all explained very well how to punch it through firewalls using UPnP or static NAT/PAT mappings.

Or by using "Run as..." option from context menu? Just an idea...

It sounds like you installed the Linux binary, not the FreeBSD binary. I'm running build 128 on FreeNAS 8.3.1-p2 (but not in jail).

If BTSync followed the symlink instead of transferring the link itself, it would act much like Junction Points on Windows, and would be preferable. I use Junction Points on Windows to link everything I want to sync from my profile into a single BTSync directory, and would love to do the same with Linux and FreeBSD.

Galaxy S3 (4.1.2) Nexus 10 (4.2.2) Archos 101 (2.3) Samsung Charge (2.3)

Seems to be working fine so-far for a day ... running 3-way between FreeBSD 8 and 2x Win7 x64.

Ideally a bandwidth limiter exactly like is present in uTorrent would be awesome. Simple and obvious interface, works great.

It does have parallel capabilities but when doing an intensive operation like indexing on slow disks I think the overall system and app are quite I/O bound and you'll see poor performance. After indexing, I've had a half dozen shares active simultaneously with even more than one peer per share.

Indexing (a non-SSD) significantly slows down syncing. Wait for indexing to finish and see if it starts working.

Sorry everyone, I was tired and/or being an idiot.

No, structure is: btsync/ sync.dat share1/ share2/ etc.

Thanks, kos. So will those files resolve/delete themselves? Or should I do a clean-up?

RAM, not CPU ... try 'free -m' while btsync is running, and post results.

Yes, read-only peers will act as seeds.

Linux here. Just noticed sync.pid has an mtime of 6-May, but it's presently 2-May. Why is sync.pid created 4 days into the future? I stopped btsync, removed sync.pid, restarted btsync, and it recreated the file still with mtime 6-May.

I just noticed in the BTSync directory on my Linux system I have a few sync.dat files that are curious: sync.dat - timestamp 2-May sync.dat.new.1366842849.bad - timestamp 24-Apr sync.dat.new.1367459505.bad - timestamp 1-May sync.dat.old - timestamp 2-May Any ideas? I'm concerned specifically about the "...bad" files. I also have one peer saying it has 6.6 GB left to upload, but the (BTSync-reported) file count matches on both ends and my end says it's in-sync (no transfers pending). A restart of BTSync on both ends had no effect, even after it showed indexing progress and completion.

n.b., at least without using hardlinks/junction points.