• Posts

  • Joined

  • Last visited

Everything posted by Osiris

  1. I confirm: remove the .sync folder & start btsync. I had to do this 2x because I interrupted the wizard by exiting the browser.
  2. Already fixed? I still hit the same issues today, with todays download from https://download-cdn.getsyncapp.com/stable/FreeBSD-x64/BitTorrent-Sync_freebsd_x64.tar.gz So that's 2.0.93.
  3. I must concur with dgl289. No http proxy is sad, since it's the only way to proxy over here. Allthough ... when I set it to https, I am able to connect to the update site (which otherwise is blocked or gives a timeout, both without proxy as with the socks proxies). Whatever I try, I cannot get it to work. I've added a predefined host, I've tried all forms of the proxy. Should I check whether our proxy supports http connect ? UPDATE : in response to florentm: Using proxifier & my ssh tunnel, I'm able to route all btsync traffic through the tunnel, making the sync function. I've added a proxification rule for the btsync.exe app to any host on any port throught the http proxy on port 8080 (which is our corporate proxy).
  4. Hi, Since the (manual) update to 1.4.72 on my qnap I have a strange issue where I cannot click the share or edit buttons on existing sync-folders. The buttons actually appear on the header bar when I hover over the sync folder. When I move to the header bar to click the buttons, they disappear again (since I'm not hovering over the folder). What can I do ? UPDATE : This only occurs in the latest Firefox. In Chrome & IE it works fine.
  5. at 1.2.82, I'm experiencing this error, even when chmodding the folder to 777 when I mount the map to /something I can add it in btsync. not when I use /mnt/e/share/something. Weird stuff edit : had to restart btsync deamon after chmod.
  6. Any updates here ? Experiencing similar problems after 1.2.82 upgrade
  7. +1 Also need log file size limit. I'm syncing 8TB between nasses. my logfile is 25 GB atm.
  8. Not trying to necromance this, but ... Is there a way to automatically remove files from destination folders if they're not present on the read-only source ?
  9. Syncing 6TB of data from freebsd64 btsync on nas (FreeNas os) to ARM btsync on another nas (QNAP QTS 4.0.2 os). Syncing succesfully done. Logfile : 10GB. Any method to cap its size ?
  10. Can this topic be un-pinned or have its title changed ??
  11. Totals : how much is synced / to be synced on all folders combined. Either on top of bottom, preferably configurable.
  12. seconding. I'm syncing 4.1 TB from one source to 2 destinations. Rearranging causes massive unnecessary traffic.
  13. From ubuntu to my mapped nas find /nas -iname ".syncarchive" -print0 | xargs -0 -I{.} find {.} -mindepth 1 -maxdepth 1 -exec ls {} \; -exec rm -R {} \;
  14. Update. Still syncing. Less than a terrabyte to go. Where can I find info on the whole syncing process ? Can't seem to find it in the docs. It seems some .!sync files are still being created on my read-only destinations. I assume these files are to be considered in progress. Yesterday, there were different ones on my destination but also 1 on my source. This is weird since there's no two way syncing being done. I'm assuming that syncing of the (large) file started while the file was being copied to the system and the .!sync file was then created somehow. I'm going to prudently conclude that this one file was the only problem.
  15. You cannot begin to imagine how much this has helped me. I ran this on both machines find /mnt/raid6/video/ -name "*.\!sync" -exec rm {} \;and restarted the btsync processes. Syncing resumed. a massive +1, if u ask me. I'm talking about a sync between a freebsd (Freenas 9) and my qnap. Had to run the line on a mapped drive from my ubuntu server to the qnap nas, since their find command doesn't allow the -exec. So In my opinion, case sensitivity has nothing to do with it. It also means that everything I said before was wrong or insignificant. Hurrah !
  16. Go all open security-wise on file level & see what gives ... Adapt accordingly & give full access to 'others' on files for both btsync program as synced folder (& all files & folders below). chmod -R 777 /mnt/raid6/programs/btsync/chmod -R 777 /mnt/raid6/btsyncedAlso, go all open in samba/cifs -> creation masks 0777 or 2777 If you see a sudden boost in sync speed, this will show I was right on a few previous accounts. It's a rights problem. Do me a favor. Post the owners of your synced files as well as your .SyncBlabla folders/files. Is your btsync user 'btsync' the owner of the .Sync... folders/files ? Perhaps adapt this as well with a chown btsync:nogroup (or the right group) on the .Sync folders/files. Do this for linux & android ...
  17. If this would describe btsync's actual behaviour, I'm considering this a major bug.
  18. Adding/changing files or folders in a btsynced folder causes a silent reindex, it seems. The larger the folder, the more the effect. When talking about larger folders of +500GB, the btsync app seems like it's doing nothing at all in the webui. After some time, it will continue with the actual file transfers. For large, synced folder in which files are often changed or added, btsync is missing its effect, imho. When on a rather weak cpu, like the one in most NAS'es, this will cause a full load on the cpu for a long time. Question 1: Am I stating this behaviour correctly ? Is anyone else experiencing this ? Question 2: Could this re-scan be at least visualised somehow in the webui ?
  19. Hi Guys, Is anything known on 1.1.82 ? Release notes ?
  20. Same issue on 3 syncing linux machines : Freenas server, QNAP TS-412, Ubuntu server 13.04 I'm syncing my video files via bittorrent sync. About 6TB. I think I actually fixed the issue, but still not sure. Syncing is slow and uses 3-5 % of network capacity. What helps is splitting up the folders in different sync entries in the webui. I had to run this line on my Freenas (which is the main server, the others do read-only sync): find /mnt/raid6/video/ -name ".Sync*" -exec chown btsync:nogroup {} \;... since somehow I had done a chown nobody:nogroup on everything. The btsync user could no longer access the .Sync* folders and files, but no warning is given UNLESS you have ZERO files already synced in that folder. Yes you better read that again :-) If zero files and folders are synced and btsync is trying to index, you get the warning (in even worse English than mine) : "Don't have permissions to write to the selected folder."
  21. Oh and eh ... I believe restarting the btsync process will cause those Terrabytes of data to be scanned again ... invisibly. No (indexing...) message will be displayed. For a long time, it will appear that btsync is doing nothing. Scheduling server reboots weekly/monthly can't be done when using btsync. I'm having this issue already with my 10TB zfs pool.
  22. This is - according to me - normal. Btsync won't consume your network resources to the max. Best is you do a normal cp first, then set up the sync. Having the same issue with my FreeNas (which is FreeBSD ofc). If I copy directly to it, I get 80MB/sec over my Gbit lan. With btsync, it's a fraction of that speed.
  23. Syncing 10 TB of media files with other nas devices at my sisters & mothers. Very sweet app. I can configure & sync the nas on my lan, then move the nas to another network with firewalls, routers, port forwarding setups ... and I don't have to reconfigure anything. It just tunnels through. Loving that.
  24. 1. Pause button(s) 2. Scheduler 3. Sync history Log
  25. A Simple 'Pause Syncing' Button on the gui would be a nice start.