yottabit

Junctions seem to be more compatible and better supported.

In a debug log I'm getting this repeatedly: [2013-05-29 22:48:15] Torrent 1532952576-11280600.jpeg status: 137 error: <NULL> meta: 1 [2013-05-29 22:48:15] Torrent 1521647616-10463714.jpeg status: 137 error: <NULL> meta: 1 [2013-05-29 22:48:15] Torrent 151289856-7304695.jpeg status: 137 error: <NULL> meta: 1 I can't get the files to transfer. The GUI shows the other computer directly connected. The debug log also shows the other system responding to ping requests. It seems like it should work ... Any ideas?

Sorry kos, my FreeBSD install still doesn't see the update today, 28 May ...

No, no. I realize build 134 isn't "new" -- what I'm saying is that the "auto update" feature looks like it has finally been officially turned on, so the clients will update themselves, without requiring download & reinstall. However, I notice this only appears to be the case with my Windows clients. My Linux and FreeBSD clients still say they're "up to date," i.e., the auto-update feature hasn't registered with them yet. I didn't see any reference to the auto-update feature being turned on in any recent posts. And I did a quick search to be sure.

My Windows clients running 1.0.116 and 1.0.131 just now showed an auto-update message to 1.0.134. Linux on 1.0.116 and FreeBSD on 1.0.130 still report "up to date" ... Any ideas when we will see auto-update function for Linux & FreeBSD? Thanks!!

I'm running the p2 patch of the same NAS and have no problems. Btsync is RAM and disk intensive. Are you sure there's no faulty hardware lurking?

Are the computers on the same subnet? Try adding the peer addresses directly in the advanced settings of the shares. Those computers are plenty fast enough of course.

It's not a shell script, not is the binary named that way. So why did you add the .sh to the filename in your init script? And don't forget to specify the config file maybe? And you didn't specify the absolute path to your rc.local so make sure you're editing the file in the correct place. Usually it's /etc/rc.local and the file should already exist.

Indexing compete on all peers? You didn't answer my other questions. Keep in mind the encryption is expensive time-wise for older CPUs. Also UDP is not optimized with some kernels and drivers... try turning encryption off and forcing TCP.

If DHT enabled it to work, you have firewall issues. DHT is there for sort of last resort scenario since it's slow to discover and very chatty.

btsync operates just fine on a LAN without any routers or outside Internet connectivity. Just make sure you don't have a software firewall or switch ACL interfering.

It's generally quick if firewall isn't interfering, and indexing is finished. Search these forums for many many many useful threads about ports, firewalls, etc.

I am also having this problem the last two days with a number of builds and shares running on 2x Win7, Linux, and FreeBSD.

For the peer connections are you showing left/right arrows, or cloud? What is kph? Please try to sanitize the units in your post. It doesn't make sense. You mention time to transfer a 1 GB file at the end, but all other units are not in time format. So what transfer rate do you see when transferring that file without btsync? Also what are your system specs? Mainly CPU model and RAM size.

The random secret being used now is adequately strong and unique, and generally far more secure that username/password combinations. Don't think of a username & password as two separate things... they aren't. It's just a single secret, no different than BTSync is using. User:Password v. ABC234..., etc. Unless you have extraordinarily long and random usernames & passwords, they are less secure than the secrets being generated by BTSync. Now two-factor authentication might have some uses, but would also complicate things. And like has been posted before, once your data is shared, anyone can share it with anyone else (on the same secret or on a different secret). BTSync doesn't use DRM and it shouldn't.

Adding the debug file just turns on verbose messaging in the standard log. The debug file doesn't change.

Check Wishlist topic for similar suggestions already made, as well as some alternatives/work-alikes.

You need to persist your umask by putting it in the profile of the user running btsync.

There is no "install" in UNIX. Just place the btsync binary where you like, along with its config file and all of the meta cache it has already created since you've run it in tmp already. Then add a startup line to /etc/rc.conf.local (FreeBSD) or /etc/rc.local (Linux).

I've completed a couple days of successful testing with native x64 builds 128 and 130 on FreeNAS 8.3.1-p2 (FreeBSD 8.3-p7).

I'm assuming you're using a /24 subnet and not /16? Okay, so a few things to check. First, can the peers all reach the tracker on the Internet? Make sure it isn't being blocked by your firewall(s). Second, are your firewalls allowing random outbound ports such as used by BTSync? If your firewall/router is only allowing selective ports to pass between the subnets, note that the clients by default use a random outbound port to relay the transfers through the BT Relay server on the Internet instead of connecting directly to each other. Third, if your firewall doesn't restrict ports between the subnets, try adding the IP of a peer on the second subnet to a client on the first subnet's Share's Advanced settings. See if the peers directly connect when you do that.

Gotcha'. So you're saying just hardlink the files between BTSync shares. Sure, that makes sense and would be nice. Filesystem-level deduplication (ZFS) is great for saving space, but in this case the files would still have to be transferred and then the underlying filesystem space freed afterward. By hardlinking the files between BTSync shares you immediately "sync" the file and save the storage space. Dropbox does this on their storage servers. If you copy a large file, like an ISO, to your Dropbox you'll see it indexing and then immediately state sync'd without transferring it. This is because someone else has already transferred that ISO and they're just linking the file from your Dropbox to the same file data on their end. Of course this still counts against your quota, bah! +1 for this functionality!

What, you don't have deduplication option enabled on your ZFS? But in all seriousness, this would require BTSync to maintain hashes of your entire filesystem (or at least a subset you choose). And in this case, you typically would want hardlinks, not symlinks. Symlinks only used for directories and pointing to other filesystems.

P.S. If you delete a file from the readonly peer, it will never come down from the other peer again. A future version will implement a "force resync" request.

Your understanding is correct. Please check that you're running the latest version (build 130 or 132) on both computers. If you continue to have difficulty, turn on debug logging and send a report. See for instructions: