yottabit
-
Posts
143 -
Joined
-
Last visited
-
Days Won
2
Posts posted by yottabit
-
-
I would absolutely love the ability to sync with (or at least Mirror a read only backup to) cloud services like Mega, Dropbox, Google Drive and Sky Drive.
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.
-
@yottabit, I'd be interested in knowing more details about mounting BtSync storage to a FreeNAS/FreeBSD server.
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!
- 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.)
-
Have you considered creating a chroot jail yourself and running BTSync within? I haven't tried it, but this may work...
-
Can you please advise on this fix? Upon selecting "Add folder" the webui is still listing '/' vs 'storage_dir'.The daemon is running under the related system user, even went as far as copying the binary to their storage_dir and running it there but no dice.
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:
FreeNAS-8.3.1-RELEASE-p2-x64 (r12686+b770da6_dirty)
FreeBSD x.y.z 8.3-RELEASE-p7 FreeBSD 8.3-RELEASE-p7 #1 r249203M: Sat Apr 6 09:28:27 PDT 2013 root@build.ixsystems.com:/tank/home/jpaetzel/fn8.3/freenas/os-base/amd64/tank/home/jpaetzel/fn8.3/freenas/FreeBSD/src/sys/FREENAS.amd64 amd64
btsync: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), stripped
BitTorrent Sync 1.0.130
EDIT: corrected to /etc/version.
-
You are right... sorry for my stupidity
I noticed that version 131 is out, what changed?
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.
-
Though, frankly you can probably run two copies right now by using fast user switching.
Or by using "Run as..." option from context menu? Just an idea...
-
Great Guys!
Is there something i need to do so i can run this on freebsd?
When i wget the tar, untar, chmod 777 the file and run ./btsync i get the following error:
ELF binary type "0" not known.
./btsync: Exec format error. Binary file not executable.
Do i need to brandelf the binary?
Running from a jail in freenas 8.3
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)
- Galaxy S3 (4.1.2)
-
Seems to be working fine so-far for a day ... running 3-way between FreeBSD 8 and 2x Win7 x64.
-
This feature already exists in SyncApp! You can already specify separate download and upload speed limits! (granted, you can't "schedule" these limits at present to have different ones at different times of day, but if you're concerned about your bandwith, you can globally limit the amount that SyncApp will use)
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.
zaphod@eddie:~$ sudo stat /mnt/btsync/sync.pid
File: `/mnt/btsync/sync.pid'
Size: 6 Blocks: 1 IO Block: 16384 regular file
Device: 13h/19d Inode: 64898 Links: 1
Access: (0640/-rw-r-----) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2013-05-02 14:34:40.587328600 -0400
Modify: 2013-05-02 14:35:15.591866500 -0400
Change: 2013-05-02 14:35:15.591866500 -0400
Birth: -
zaphod@eddie:~$ sudo ls -l /mnt/btsync/sync.pid
-rw-r----- 1 root root 6 May 2 14:35 /mnt/btsync/sync.pid
-
No, structure is:
btsync/
sync.dat
share1/
share2/
etc.
-
Sync wasn't able to save file for some reasons.
Thanks, kos. So will those files resolve/delete themselves? Or should I do a clean-up?
-
Yes, BTSync consistently uses anywhere between 10-70% of the total CPU power of the Pi unit, however, it never really reaches 100% -- so I don't believe that's the actual issue. (I've monitored during transfer with htop).
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.
- sync.dat - timestamp 2-May
-
No, it's not currently possible to have two syncs setup on a single folder at any one time
n.b., at least without using hardlinks/junction points.
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.
Sync Read-Only folder with computer that already has partial folder
in Sync General Discussion
Posted
Put your logfile in a BTSync share and e-mail BT your Secret?