nils

/dev/random can block if it does not have enough entropy i.e. sources it uses to create pseudo-random numbers. /dev/urandom will not block, which could in theory lead to sequences which could be cracked - if knowledge of the system is available to the attacker. As this is highly improbable /dev/urandom can be used, see http://stackoverflow.com/questions/3690273/did-i-understand-dev-urandom @dmason: thank you for the commandline version to generating new secrets

Hi Thomas, Judging by your setup description, it should work. Have you tried to do an initial sync at home in your own LAN? It might be that torrent traffic is blocked/ ports are not forwarded in your router and therefore it does not seem to work from the outside.

Hello, That's strange, I have one instance of BTsync running on FreeBSD and did an SSH forward to my local machine on port 1024 without problems. What exactly did you do in your case?

Hmm, that seems strange, but that is how they have realised it for the time being, maybe put up a request.

Hello, Have you tried to "Add Folder" on the web interface? You need to insert the key in the Secret field and then select the folder where it should be stored.

I do not have any Android device, but the iOS version adds every folder as not automatically synced i.e. you can browse through the share and tap each file you want to download. I cannot try it, so maybe create a small share and see if it works, otherwise put it in a request for the android wish list. HTH

Hello, If the devices find each other it should be ok, have you tried if torrent traffic works? Was the folder accessible to the user that was running btsync? And maybe have a look at /attach your sync.log file.

Whilst BTsync is not out of beta, I would recommend to make one or multiple backups of anything you want to test-run through BTsync. Once you have that, you can test it out. BTsync should not write anything to the db-files in your shares if it is the only master-node. The RO-nodes might get corrupted, as BTsync on the master-node will synchronise without caring about other processes accessing the files.

Have you tried it from somewhere else than university? Some universities block torrent traffic by default, which might apply to yours as well.

How much data are you trying to sync? Hashing a lot of data or files could be one cause. Have you looked at your sync.log?

Have you tried the latest version as well? Maybe check on both networks if the NAT/UPnP ports were requested on the routers. Secondly, check if torrent/P2P traffic works on your end and from the remote site - some Linux ISO will do. HTH If not, you will have to look at the sync.log (if you can) on your NAS.

Hello, There has been a similar thred in this forum about changing the web interface, specifically the icon and name shown in a browser. The user however found out, that by restarting BTsync, all the changes were overwritten again. The developers distribute the webui within the binary file and do not currently allow permanent changes to it as far as I can tell. Maybe it is worth waiting for an API, which could (probably) be accessed via PHP.

Well, if everything else would be the same on the systems you are syncing, it might work. I would probably start with a fresh install, setup both systems exactly the same and then create a share. I still have my doubts that it would work, but am happy to be proven wrong

Hello Tim, The developers are thinking about implementing an API for BTsync so third party programs could be used with it. The Monit package in Linux and Unix makes it possible to monitor and restart services if necessary, maybe something similar exists for Windows as well.

Hello, First of all it seems that WiFi and ethernet at your workplace do not have the same subnet and/or firewall config, otherwise you would be able to access your local printer from your WiFi. Secondly torrent clients do not by default need to have NAT/UPnP enabled or allowed by the firewall/router to function. BTsync on the other hand needs to "poke" holes through your firewall in order to work, either by someone setting up port forwards in the firewall or by using UPnP, which needs to be allowed by the firewall, otherwise clients cannot find each other. Possible remedies are talking to the admin at work or setting up a VPN (if the firewall allows those). HTH

I have no clue about QNAP but assume it runs some flavour of Linux. If you can add a new user and run btsync with it, then you have what you wanted. There are also some configs floating around in the forum on how to start btsync as service upon booting in Linux/Unix with options to set a user. Not sure either if that is possible to be implemented in QNAP either, but worth a try.

If one wants to have less shares to maintain, symlinks are not a bad option IMHO. Let's say a user has several software packages and their configs - for whatever reason - all reside in different folders. Now syncing all these configs to a NAS as backup is a pain if each one has to be set up as a single share, so by using symlinks, everything could be synced in one single share. but YMMV

Permissions will get garbled up. The reason is simple: On Mac1 BTsync runs as Administrator and has - based on its privileges - access to all user files. That's good because that is what you want. It does not however care about ownership, maybe some access rights like writeable and executable. On Mac2 BTsync runs as Administrator as well, waiting to receive the files and saves them under its own username and therefore effectively kill the ownership settings. BTsync is multiplatform, so the whole bunch of Unix/Linux clients would not bode well if they cared about ownerships when paired with Windows clients. What you could do instead is syncing shares on the user level, which would allow User on Mac1 to sync to User on Mac2. Although I think some extended attributes won't make the sync either and could break some other stuff. Maybe some other sync solution would be more suitable for your use case scenario e.g. rsync.

A daemonized version for all systems (where possible), including the webui OR make desktop versions headless capable with commandline switches and a webui. OS X specific wish (minor bug?): Closing of the window (Open Bittorrent Sync) with cmd+x would be great.

So far the OS X version is a GUI version only and no separate daemon version is available, similar to the Unix and Linux version. What you could try: 1) DL the OS X version on your headless server and cd to the directory BitTorrent Sync.app/Contents/MacOS. Try to run the Bittorent Sync binary and see what happens, maybe try commandline options. 2) use virtualbox on the commandline, create an image for linux and run btsync inside. 3) make a feature request (as you did already on the wishlist) and wait/hope for such a version. HTH

The desktop clients support setting up specific ip addresses/hostnames with ports. If you use those and disable relay and tracker, you have your own tracker, circumventing the ones set up by the btsync crew. Edit: Of course this means you need to have either a fixed IP address at this node or something similar to dyndns/noip setup as well as access to port forwarding of firewall configurations to allow communications for the specific UDP port if necessary.

UC4 is available in the iOS version, where you can select files to be sent to another mobile device from the photos and shared folders on the client. What happens behind the scene probably works this way: 1) copy selected files to temp folder 2) create new share on the iOS client using the temp folder 3) generate link/QR code 4) other mobile grabs the QR code and connects 5) leaving the screen deletes the share and the temp folder. The QR code secrets are already quite neat with a format like btsync://<your secret here>?n=<your share name here> edit: "all" that is necessary would be porting this to the desktop version and you would have instant file transfer through btsync UC3 will probably never make it into btsync, because as soon as you even have a one time secret, that person can make a copy of the shared folder upon sync completion, without you knowing it. If this will ever be realised, then with btsync as backbone through an API used in a 3rd party program.

Nice find @axon BG44UNMLJ2LA7CLMBT7WABMSJ3M26B3RJ

... or the OP was talking about USING SMB/WebDAV as the storage medium and the iOS client to access and share it.