I think you had mentioned before about doing a regular backup. Do you do this via the Settings [Tab] -> Community Applications / Backup Appdata thingy? Or would you recommend another way?

 

Despite Squid being a good mate on here, I'll let you into a secret.  I actually have a script that runs via a cron job to backup my appdata but to be honest that's just because I set it up before Squid implemented the functionality in CA and I haven't got around to switching to the method in Community Applications, which if I were to start again would be exactly how I'd do it. 

 

Thank you for your patience and help!

 

No problems, glad we got it working.

I decided to install this docker to keep my backup unRAID server synced with my main unRAID server. Previously I've used rsync to achieve this, running it manually whenever I've added more than a few files to my collection and I decided I would like to automate the process.

 

I chose the Linuxserver.io container and read about the subject before installing. I set the folder type to Master on the main server and, after a very long initial scan, changes I make on the main server are propagated to the backup server.

 

But I notice that the default rescan interval is set to a mere 60 seconds, which I'm assuming will probably keep my disks from spinning down. I don't need anything like real-time backups and once a day is more than enough for my needs. Does anyone foresee any problem with me setting the rescan interval to 86400 seconds instead?

I decided to install this docker to keep my backup unRAID server synced with my main unRAID server. Previously I've used rsync to achieve this, running it manually whenever I've added more than a few files to my collection and I decided I would like to automate the process.

 

I chose the Linuxserver.io container and read about the subject before installing. I set the folder type to Master on the main server and, after a very long initial scan, changes I make on the main server are propagated to the backup server.

 

But I notice that the default rescan interval is set to a mere 60 seconds, which I'm assuming will probably keep my disks from spinning down. I don't need anything like real-time backups and once a day is more than enough for my needs. Does anyone foresee any problem with me setting the rescan interval to 86400 seconds instead?

 

The fact it's a editable variable suggests it should just work.... I can't think of any problems off the top of my head.

Thanks, it's just that it is such a huge change from the default. I'll give it a go and if I notice any unwanted side effects I'll report back.

I decided to wait until the first major sync between the two servers is complete before changing the scan interval. And therein lies the problem - it never will complete because of the issue outlined on this page: https://docs.syncthing.net/users/ignoring.html#effects-on-in-sync-status.

 

I have .stignore files set up to exclude Apple metadata (.AppleDB and .DS_Store) and also to exclude one particular sub-folder, which I want to keep local to each server. As a result, the Folders status alternates between Out of Sync and Scanning, while the Remote Devices status is permanently Syncing (100%). This keeps the unRAID disks spinning and CPU and RAM usage high (76% and over 4GB, respectively). It has also created a >20 GB database in the appdata/syncthing folder of each server.

 

It's a heavyweight application with, I can see, considerable power and versatility, most of which I don't need. I don't need to sync with tablets and smartphones or workstations and I think for my purposes rysnc (run manually or maybe using cron) is much the better solution - faster and far less demanding of resources. I won't remove syncthing for the moment and I'll continue reading around the subject. It's rather disappointing but it's also educational.

 

UPDATE:

I've now changed the rescan interval on both servers to 1 day (86400 seconds) and the changes caused Syncthing to re-start. After a while both settled down, each indicating Out of Sync for its own local state and Syncing (100%) for the other server's state. CPU usage is close to zero and RAM usage down to 64 MB. I hope this will let the disks spin down until the next scan in a day's time. If that is indeed what happens I'll add some files to the main server and see if they propagate across to the backup when the next scan runs. To facilitate testing I might have to speed things up temporarily by setting the rescan time to 1 hour, but if this works as I hope I'll stick with Syncthing.

 

UPDATE (the following morning):

When I woke up this morning the parity disks in both servers had spun down but the data disks were all still spinning and, according to the syslogs, had been all night. I checked that my changes to the scan interval had stuck and then stopped the Syncthing dockers. An hour later the disks had all spun down. This is the deal breaker.

 

This docker has been rebased to alpine with s6 overlay, please make sure you backup your appdata first before you update to this latest image.

 

For more information, please read : http://lime-technology.com/forum/index.php?topic=50793.0

Before the latest container update, I was on Syncthing v0.14.4. After the update, I now seem to be stuck at v0.14.3. Restarting, Starting/stopping, and force updating the container are not resolving it.

 

https://github.com/syncthing/syncthing/releases

Before the latest container update, I was on Syncthing v0.14.4. After the update, I now seem to be stuck at v0.14.3. Restarting, Starting/stopping, and force updating the container are not resolving it.

 

https://github.com/syncthing/syncthing/releases

 

Read the link above, we've turned off auto-updates.

 

Which is a good thing in my view with this app as clients won't sync if there are version discrepancies...

That's disappointing. I've never had a problem with that, even with Syncthing. In fact it was my favorite feature of the lsio containers.

 

Is there any way for me to force it to update or use a specific version?

 

Edit: Of note is that only major version discrepancies will break syncing with clients.

That's disappointing. I've never had a problem with that, even with Syncthing. In fact it was my favorite feature of the lsio containers.

 

Is there any way for me to force it to update or use a specific version?

 

Edit: Of note is that only major version discrepancies will break syncing with clients.

 

Yeah, I'm aware that it's only the major versions but we debated for a long time about the auto-updating feature and it just generates too many variable in terms of support and made it an absolute nightmare. 

I just started using this a week ago since this fits my needs better than crashplan. So far it has been working well but I feel that the sync transfer rate on my gigabit LAN is a little slow (20 to 40% cpu utilization). Also, how do we update it when a new release is out? Do we get a notification that an update is available when we do a "check for updates" in docker? Great work guys!

You get a notification in your Unraid webui when an update is available.

I just started using this a week ago since this fits my needs better than crashplan. So far it has been working well but I feel that the sync transfer rate on my gigabit LAN is a little slow (20 to 40% cpu utilization). Also, how do we update it when a new release is out? Do we get a notification that an update is available when we do a "check for updates" in docker? Great work guys!

 

I had to forward 2 ports specified in the Syncthing documentation to get decent speeds.

I just started using this a week ago since this fits my needs better than crashplan. So far it has been working well but I feel that the sync transfer rate on my gigabit LAN is a little slow (20 to 40% cpu utilization). Also, how do we update it when a new release is out? Do we get a notification that an update is available when we do a "check for updates" in docker? Great work guys!

 

I had to forward 2 ports specified in the Syncthing documentation to get decent speeds.

I will check if those two ports are open and relay settings. Both of my unRAID servers are behind my firewall and in the same network segment.

 

Sent from my Nexus 6P using Tapatalk

 

 

Hi,

 

I have this docker working, but a couple of questions. I am only getting 1/2 listeners working, when I highlight it I see that the error is "x509: failed to load system roots and no roots provided". A google tells me this error in a docker container can be related to missing ca-certificates (http://blog.cloud66.com/x509-error-when-using-https-inside-a-docker-container/) and chance of a fix for this?

 

Also how often does this docker get an update? or is it possible to in a update to the app in the docker, it is currently 14.3 but my other syncthing is up to 14.6.

 

Thanks,

Wob

 

I have the syncthing docker running on both of my servers now and no apparent errors (initially) but under webgui/Remote devices they now aren't seeing each other and are giving errors for backing up appdate (via the settings/Backup Appdata option).

 

While the servers did see each other initially they didn't actually sync, I really don't think I changed anything, because I was going to get back to it to figure out the syncing but now a few days later not only are they still not syncing but they haven't "seen" each other for days?

 

I have all the "discovery stuff" enabled:

Enable NAT traversal

Local Discovery

Global Discovery

Enable Relaying

 

and the global discovery server is set to default.

 

Log

 

_ _ _
| |___| (_) ___
| / __| | |/ _ \ 
| \__ \ | | (_) |
|_|___/ |_|\___/
|_|

Brought to you by linuxserver.io
We do accept donations at:
https://www.linuxserver.io/donations
-------------------------------------
GID/UID
-------------------------------------
User uid: 99
User gid: 100
-------------------------------------

[cont-init.d] 10-adduser: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
[OERHT] 03:00:23 INFO: syncthing v0.14.5 "Dysprosium Dragonfly" (go1.7 linux-amd64) buildozer@build-edge-x86_64 2016-09-05 07:42:17 UTC
[OERHT] 03:00:23 INFO: My ID: OERHTN2-LK3GSUO-QKZK5DQ-IBETEGC-LYKRHKM-LYPIYCJ-F6YOZ7J-G5VJJQK
[OERHT] 03:00:23 INFO: Single thread hash performance is ~112 MB/s
[OERHT] 03:00:24 INFO: Ready to synchronize Jwp6n-D23XC (readwrite)
[OERHT] 03:00:24 INFO: Ready to synchronize r7t5i-lhziq (readwrite)
[OERHT] 03:01:26 INFO: Ready to synchronize qbrrr-kfjva (readwrite)
[OERHT] 03:01:26 INFO: Using discovery server https://discovery-v4-1.syncthing.net/v2/?id=SR7AARM-TCBUZ5O-VFAXY4D-CECGSDE-3Q6IZ4G-XG7AH75-OBIXJQV-QJ6NLQA
[OERHT] 03:01:26 INFO: Using discovery server https://discovery-v4-2.syncthing.net/v2/?id=DVU36WY-H3LVZHW-E6LLFRE-YAFN5EL-HILWRYP-OC2M47J-Z4PE62Y-ADIBDQC
[OERHT] 03:01:26 INFO: Using discovery server https://discovery-v4-3.syncthing.net/v2/?id=VK6HNJ3-VVMM66S-HRVWSCR-IXEHL2H-U4AQ4MW-UCPQBWX-J2L2UBK-NVZRDQZ
[OERHT] 03:01:26 INFO: Using discovery server https://discovery-v6-1.syncthing.net/v2/?id=SR7AARM-TCBUZ5O-VFAXY4D-CECGSDE-3Q6IZ4G-XG7AH75-OBIXJQV-QJ6NLQA
[OERHT] 03:01:26 INFO: Using discovery server https://discovery-v6-2.syncthing.net/v2/?id=DVU36WY-H3LVZHW-E6LLFRE-YAFN5EL-HILWRYP-OC2M47J-Z4PE62Y-ADIBDQC
[OERHT] 03:01:26 INFO: Using discovery server https://discovery-v6-3.syncthing.net/v2/?id=VK6HNJ3-VVMM66S-HRVWSCR-IXEHL2H-U4AQ4MW-UCPQBWX-J2L2UBK-NVZRDQZ
[OERHT] 03:01:26 INFO: TCP listener (0.0.0.0:22000) starting
[OERHT] 03:01:26 INFO: Device OERHTN2-LK3GSUO-QKZK5DQ-IBETEGC-LYKRHKM-LYPIYCJ-F6YOZ7J-G5VJJQK is "tinytower" at [dynamic]
[OERHT] 03:01:26 INFO: Device CFEIJ4J-ELFSSVM-RJMMYUA-XVKLHDE-RZWKKJQ-RMDGKUD-4C62VWM-IMXCUAJ is "bigtower" at [dynamic]
[OERHT] 03:01:26 INFO: GUI and API listening on 0.0.0.0:8384
[OERHT] 03:01:26 INFO: Access the GUI via the following URL: http://127.0.0.1:8384/
[OERHT] 03:01:26 INFO: Completed initial scan (rw) of folder Jwp6n-D23XC
[OERHT] 03:01:26 INFO: Completed initial scan (rw) of folder r7t5i-lhziq
[OERHT] 03:01:37 INFO: Detected 0 NAT devices
[OERHT] 03:04:05 INFO: Completed initial scan (rw) of folder qbrrr-kfjva
[OERHT] 03:00:11 INFO: Exiting
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] syncing disks.
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 10-adduser: executing... 

[/size]thoughts?

Is there any other information other than the above that I could post that would make the diagnosis easier? I'd really like to get this working but am at a loss on where else to try

Are all the clients the same version?

 

Sent from my LG-H815 using Tapatalk

 

 

Yes, v0.14.5, Linux (64 bit)

I am having trouble connecting to clients running version 14.7

 

Is there a way to manually update the version inside the docker?

 

 

I am having trouble connecting to clients running version 14.7

 

Is there a way to manually update the version inside the docker?

 

Not that I know of, I was going to chat to Sparkly about tagging these, might take a little while to get around to it though.

I am having trouble connecting to clients running version 14.7

 

Is there a way to manually update the version inside the docker?

 

v14.7? Just out of curiosity, how are you updating? I click on "check for updates" and am told that I am up to date with v14.5 on linux 64 bit etc but if you have 14.7 then perhaps I am not up to date? (and updating would help the problem I am having? hopefully?)

I am having trouble connecting to clients running version 14.7

 

Is there a way to manually update the version inside the docker?

 

v14.7? Just out of curiosity, how are you updating? I click on "check for updates" and am told that I am up to date with v14.5 on linux 64 bit etc but if you have 14.7 then perhaps I am not up to date? (and updating would help the problem I am having? hopefully?)

 

His clients are 14.7....

I am having trouble connecting to clients running version 14.7

 

Is there a way to manually update the version inside the docker?

 

v14.7? Just out of curiosity, how are you updating? I click on "check for updates" and am told that I am up to date with v14.5 on linux 64 bit etc but if you have 14.7 then perhaps I am not up to date? (and updating would help the problem I am having? hopefully?)

 

His clients are 14.7....

 

Perhaps I am confused about what clients are? When I go to the webui -> actions -> about it says v14.5 (and in the log it tells me [OERHT] 21:59:43 INFO: syncthing v0.14.5 "Dysprosium Dragonfly" go1.7 linux-amd64). If I update from the Docker page I would think it would update syncthing to the newest version? (maybe I am all off and he updated manually to  14.7 which isn't in the repo or something... I am just hoping that an update might go some ways towards helping me resolve the issue I am having)

I am having trouble connecting to clients running version 14.7

 

Is there a way to manually update the version inside the docker?

 

v14.7? Just out of curiosity, how are you updating? I click on "check for updates" and am told that I am up to date with v14.5 on linux 64 bit etc but if you have 14.7 then perhaps I am not up to date? (and updating would help the problem I am having? hopefully?)

 

His clients are 14.7....

 

Perhaps I am confused about what clients are? When I go to the webui -> actions -> about it says v14.5 (and in the log it tells me [OERHT] 21:59:43 INFO: syncthing v0.14.5 "Dysprosium Dragonfly" go1.7 linux-amd64). If I update from the Docker page I would think it would update syncthing to the newest version? (maybe I am all off and he updated manually to  14.7 which isn't in the repo or something... I am just hoping that an update might go some ways towards helping me resolve the issue I am having)

 

I assume by clients he means other machines connecting to his Unraid instance. 

 

As regards your issues I don't think an upgrade will necessary fix your issues given you seem to be the only one experiencing it, I'm using this personally and not had any problems whatsoever.  Might be worth a look over at the Syncthing forums?

 

We can't upgrade this app at the moment as v14.5 is the latest version in the Alpine Repo.