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)