superloopy1

Hit a similar problem this evening. Sorted by confirming that ovpn i was using was responding very slowly. Switched routing with another vpn config, no changes at all to docker , and all now working. seems PIA have been making changes.

Drop him a pm, he's v.helpful. Sent from my CLT-L09 using Tapatalk

I tried synching and a real pita it was too. I even registered on the ST forum, asked a couple if questions and was told that it wasn't really designed to be used in the way I wanted use a regular backup to another machine. I have a backup unraid server which I wanted to power up, say weekly, and rsync changes with. Hoopster's your man ... Sent from my CLT-L09 using Tapatalk

I'd wait for Hoopster to chip in here. He will offer a full blown rsync solution complete with SSH keys and all ... Sent from my CLT-L09 using Tapatalk

So ... there's a conflict somewhere? What needs to change? Do I need a new address for br3? None of these have a cable attachment or any dockers using the range yet. Sent from my CLT-L09 using Tapatalk

Ok ... i've found them and my br2/br3 look like this IPv4 custom network on interface br2: Subnet: 192.168.2.0/24 Gateway: DHCP pool: not set IPv4 custom network on interface br3: Subnet: 192.168.2.0/24 Gateway: DHCP pool: not set Subnet: 192.168.1.0/24 Gateway: 192.168.1.1 DHCP pool: not set Could this be the cause and nothing to do with the existing dockers?

Where are the advanced docker settings? Can't see them under advanced view on the dockers page itself? And yes, there is a :xxx.xxx.xxx. type entry alongside. Sent from my CLT-L09 using Tapatalk

They are using 172.17.0.2 & 3 respectively. No command line input at all. In bridge mode. Sent from my CLT-L09 using Tapatalk

I only have Maria and nextcloud dockers installed as preconfigured. Sent from my CLT-L09 using Tapatalk

In syslog ... ' rc.docker: Error response from daemon: Pool overlaps with other one on this address space' Seen it a few times recently.

And it was! Thanks for the help.

Thanks! I'll post up the good news when it goes through cleanly ;>)

Thanks, it's running now. Looking at the syslog seems to be saying that it was parity 2 disc that was corrected so does this mean that my data disks are ok and that possibly parity2 got itself a bit 'lost' during the earlier hangup and subsequent power cycle? would it be right in saying that if it was a defective data disk then i would've seen a disk id in the log? I dont know as this is the first occurrence of sync errors in 7 years!!

Gents ... parity checks have ALWAYS been clean until now - 893 errors! Can someone take a look at my diagnostics file taken immediately after the check ended and give me a heads up on whether i need to to do another, uncorrecting this time, run to see what's what. I'm inclined to think that this may have arisen after a problem lockup last time around when parity check kicked in and the system was lost on itself again. when it returned after all that it said parity was valid so i've just been running on that since then. Maybe it wasnt giving me the right picture? Anyways, here's the diagnostics file smtower-diagnostics-20200618-1317.zip

Thanks. I'll give both suggestions a go.