Shot2

Same "issue" here, whatever the cryptic message means. It's filling the logs, already 700MB with such lines in 2 hours :[

BTSync 1.2.73 under vanilla Ubuntu 13.10 x64 Server, still no luck enabling logging. Tried so far: adding "--log file" to daemon args in /etc/default/btsyncadding "--log file" in the /etc/init.d/btsync initscript (ain't that old-fashioned, btw?)both solutions above experimented with and without a 'debug.txt' file (containing variously '0' '1' 'ffff' 'omgwtfbbq') in BTSync's storage path.To no avail. Will gladly send logs if it helps debugging. Oh, wait...

Under Ubuntu find returns hidden files too try it for yourself, it works. Still, can't find a .sync directory anywhere on the server. Also, the only btsync executable is a daemon located at /usr/lib/btsync/, yet no .sync dir in there. ls -al /usr/lib/btsync/total 3356drwxr-xr-x 2 root root 4096 Oct 27 04:16 .drwxr-xr-x 59 root root 4096 Oct 27 04:16 ..-rwxr-xr-x 1 root root 3424952 Sep 20 12:50 btsync-daemonThe daemon runs under a system user, whose homedir has no .sync subdirectory - only a bunch of files (settings.dat etc. + databases corresponding to loaded secrets). Still can't figure where the webUI stores the new password, and whether it's possible - not to say advisable - to redact the older one in <btsyncinstance>.conf...

sudo find / -type d -iname ".sync"returns no results for BTSync latest under Ubuntu. Weird. Something fishy. I naively thought the webUI params were where I wrote them (e.g. in /etc/btsync/myuser.conf) but having changed the password in the webUI, that is indeed not reflected in that latter file. On to my question: now that the WebUI has stored its settings in some undisclosed/unreadable location, is it ok to remove the {webui} section (or perhaps more specifically, the plaintext login/pass info) from that myuser.conf?

What are they busy with, that's the question of the superbanco. They might as well have spent 15 days working hand-in-hand with their legal team and the NSA on how to implement a backdoor, fwiw. (just kiddin' )

Good for you... Still, can't make it work with Cherokee (cf. my previous posts).

Months go by and still no luck. Still stuck with this dumb "/gui/" (talk of a non-informative url...) At least, please consider providing a configuration option for that base directory (e.g. in the .conf file, under the webui section), something along these lines: "webui" : { "listen" : "127.0.0.1:8888", "login" : "username", "password" : "userpassword", "basedir" : "btsyncGUI" }so that the webui becomes accessible (and reverse-proxyable) at "http://127.0.0.1:8888/btsyncGUI/" Shouldn't be rocket science...

Same question. To me it's not perfectly clear: after experimenting, it seems in a "one master (r/w) - many clients (r-o)" scenario the clients do not exchange data between them. Example: I add one "NEW" file to the "master". It starts getting distributed to a few online "clients", who eventually get the whole file. Now I take the "master" offline, for a few days. Now a few "clients" come and are added to the swarm. They won't get the "NEW" file from existing "clients", not until I switch the "master" back online. Either there's something fishy in that definition of a swarm, or there's a bug which prevents r-o clients to contribute data between them... (tested Ubuntu x64 1.1.70)

+1 voice for the ability to have BTSync listen on a specific interface/IP only - currently it defaults to 0.0.0.0 i.e. all

Same error messages here (v1.1.69 Win or v1.1.48 Ubuntu "master" side, v1.1.48 client side). Syncing to that client has been stuck for days now (no progression), I get hundreds of thousands of such errors for 10s of thousands of files: Torrent Archive.zip status:137 error:<NULL> meta:1 conns:1 io:0 More worrying: for these thousands of files, it uploads something to the client (a few KB), then transfer speeds drop to zero. After a few hours/days, the same files reoccur with same issues and symptoms. Today only, it has uploaded ~3GB of data but to no avail... Wash, rinse, repeat. Nothing changes. The debug log file is now at ~500MB. Even if purportedly a "status message", it would be nice to have some actual reason for this mess... I know developers of closed-source software like to obfuscate the inner workings of their babies, but it could actually help to know the meaning of that cryptic "status:137 error:<NULL>".

Not possible with BTSync. Prioritization of inherited permissions in a hierarchy tree is no issue at all for other software and a variety of uses. Sure, takes a different kind of hierarchical processing but it's no definite theoretical impossibility - only a design choice in BTSync.

OK, got it. Found the ID, IP and version (1.1.42) of the read-only peer which has retained now-deleted files. Weird. Will ban it and disable logging, thx

As said, there is no way to contact this peer (or better said: I have no idea who to contact). Also, there is no ".sync" directory, nowhere on the server, zero, nada. The biggest issue at the moment is the logging of the same error every 10-12 seconds for several weeks now. Any way to disable any and all log messages? Or is there any way to block bad peers, peers gone mad etc.? (I'd do it with a simple firewall rule if BTsync was able to detect and display peers' IPs rather than their 'names') I really don't want to delete that secret (used by dozens of peers) only because of one remote peer acting crazy...

Hi, BTSync 1.1.42 running on Ubuntu 12.04.2 Server. One folder shared, successfully indexed in full, with 3 clients using a read-only secret (no idea about which version they use) Looking at my sync.log file, there is this error message repeating every 10-15 seconds... for days now: The thing is, this ~200MB file has been removed from my side, but if I interpret correctly that small error message, it's probably still present at some remote peer(s). No idea which ones, actually, the message does not provide any clue. Still I guess it's at that peer which appears in a "stuck" state for weeks now (= with everything to redownload, yet nothing moves). How to solve such a situation? I have no immediate access to/contact with the relevant remote peer(s)...

What's wrong with the Kimsufi 2G plan? Double the specs (i.e. 1TB, 2-core CPU), for a few bucks more. And everything works on their servers, unlike other providers with uncanny setups... For larger storage needs, you could easily use any other *serious* cyberlocker as a means to expand storage (any "backup" plan should allow it, provided you encrypt everything so the company has no peek at your usage)

Wish: a way to force peers to upgrade their clients / recreate the share. With its rapid development, btsync has seen numerous changes and improvements (hopefully) which may cause incompatibilities between outdated and more recent versions. So far, it seems clients simply fail connecting to a new up-to-date "master" share. I also guess it might explain why peers appear in a "stuck" state sometimes - incompatible versions, or their local btsync db being somehow corrupt. Not sure if secrets and peer connections transmit some version information that could be put to use in order to warn (and potentially mitigate) conflicts. Not sure either if they get any notice about version inconsistencies, but it would be nice if when adding/connecting to a secret they'd get a useful message e.g. "The secret was added, however it may not work as expected. To fix it, please consider upgrading your BTsync software. Alternatively, you could try deleting then re-adding that secret, pointing to the same folder." Or something along these lines. Would save time by encouraging "in the background" people to update / fix issues, rather than peers having to contact each other by mail, snailmail, phone "hey dude, your sync client is stuck, u should update blaah blah blah"

However, since secrets are not necessarily created randomly, what are the odds of two enthusiast geeks creating a same secret e.g. "ALLY0URBASEAREBEL0NGT0US"? remarkably high, methinks.

It makes a difference because the .Sync[Whatever] file or dir is no longer 1/ hidden 2/ interpreted as a special file by other software accessing the directory tree, e.g. a web server. Makes maintaining a server needlessly more complicated - having to define special rules for these BTsync-proprietary files. Image people downloading up-to-date files via, let's say, FTP or HTTP, they will stumble upon that "SyncArchive" dir and grab it for nothing (either because it's empty, or because it contains gigabytes of deprecated/outdated/buggy/temporary files). It's no definitive deal breaker, but it's imho a weird and rather unflexible design decision. Worse: just found that upon restarting btsync, and even though all shared folders are explicitely configured as "Do not use the Sync trash", that damn (and explicitely configured as "do not use, you're useless, keep away of my hierarchy!") folder gets recreated... So now we have to reconfigure servers to forcibly hide/do not serve a new filename (until the next change by btsync devs) + run a cron task to forcibly delete Sync[Whatever] folders

+1, this is a terribad idea. Especially now that it is no longer hidden by default under Nux. At least there should be a way to customize the location for "trash", and/or disable it altogether. The cleanest way would be NOT to mix app-specific metadata and trash/outdated files within live, current, potentially publicly-exposed data. A centralized DB (in %APPDATA% under Win, under /usr or e.g. user .config dir for GNU Linux) would be the way to go. (Sticking with 1.1.33 for the time being until it gets eventually fixed.)

Updating both sides to 1.1.33 seems to have fixed things.

Issue still there with 1.1.33 under Win. I uninstalled 1.1.30 Win, removing settings, and recreated the folder share. All files are there on both sides, correctly synchronized (i.e. with the Ubuntu 1.1.30 server) but the Win client is still stuck as if there was everything to upload. Half an hour later, nothing changed.

Same issue here, between Win (BTsync v1.1.27) and Ubuntu (BTsync v1.1.30). Both sides have the exact same set of files, but both sides show the must reupload the same set of files to the other side. Illustrative screenshots, both sides (WebUI Ubuntu & Client software Win): Nothing happens since 20 minutes ago... restarted both sides, in both orders (A/B or B/A), no change. Can't send logs now, as it includes a lot of personal info I have to expunge.

No luck either with Cherokee's HTTP reverse proxy, all I ever get is HTTP 400 Bad Request...

Same question here, btsync (1.1.27/Ubuntu12) binds to 0.0.0.0:3838 for I-don't-know-what reason, and there seems to be no way to prevent that weird behaviour. What is it for? How do you switch that off?

Updated to 1.1.26 on Ubuntu 12.04 server - went flawlessly - works like a charm thank you tuxpoldo!