dalben

OK, thanks. I'll kick one off tonight then to see how it goes. As an aside, it might be a worthy addition to the Parity Check summary to say it did correct xxxxxx errors to avoid the easily confused like me

So the correcting check ran. Last check completed on Sunday, 03-03-2019, 18:07 (today), finding 488376000 errors. Duration: 17 hours, 54 minutes, 33 seconds. Average speed: 93.1 MB/sec Log has a fair few of these entries, then stopped logging Mar 3 08:40:58 tdm kernel: md: recovery thread: P corrected, sector=7814037848 Mar 3 08:40:58 tdm kernel: md: recovery thread: P corrected, sector=7814037856 Mar 3 08:40:58 tdm kernel: md: recovery thread: stopped logging Then we see Mar 3 18:07:53 tdm kernel: md: sync done. time=64472sec Mar 3 18:07:54 tdm kernel: md: recovery thread: completion status: 0 So now I'm trying to work out if it did correct those errors. I can't see a log entry or comment anywhere of the amount of errors it corrected. As 17hour Parity check is about 5 hours more than usual so it assumes it did a fair bit of extra work, but I'd like to see some confirmation.

Thanks. It looks like you're right. Started a correcting check, all fine until the 4tb mark now is correcting errors at a rapid rate. As my biggest data disk is 4tb that seems in line with your thoughts.

I'm assuming that was the parity rebuild, not the copy, that took a while as well. To rebuild the parity am I right that these are the correct steps: Unassign the parity drive, then start and stop the array, then reassign the parity drive and restart the array ?

I used the parity swap procedure found here: https://wiki.unraid.net/The_parity_swap_procedure Moved the 4tb parity to a data drive then chose the new 6tb as the parity. I'm pretty sure I ran a full parity after the swap and remembered seeing the increase in speed to 194.5 MB/s which I assumed was due to a 6tb parity run knowing there'd be 2tb of nothing to check. But I could be mistaken. What would be the risks of another parity check and correcting errors vs rebuilding parity from scratch. I haven't noticed any file corruptions (yet).

I've just noticed that since Jan 1st my parity checks have thrown me 480m errors. The last two monthly parity checks I just didn't click as I must have ignored that number as a date or something, Realised yesterday there were errors and now noticed it's been the last 2 monthly checks. With that size number out of nowhere, and not having experienced any issues with the server, could it be something other than real parity errors? Anything I can check or look at to see what the real state of my server is ? I'm more they are real errors with the parity check increasing by 4 hours. The only real change is that the Dec 02 run is when I installed a 6Tb parity disk. The last few checks: 2019-03-01, 12:14:33 12 hr, 14 min, 32 sec 136.2 MB/s OK 488376000 2019-02-01, 12:15:10 12 hr, 15 min, 9 sec 136.1 MB/s OK 488376000 2019-01-01, 12:15:14 12 hr, 15 min, 13 sec 136.0 MB/s OK 488376000 2018-12-02, 15:46:17 8 hr, 34 min, 21 sec 194.5 MB/s OK 0 2018-11-30, 04:53:20 8 hr, 36 min, 50 sec 129.0 MB/s OK 0 2018-11-01, 08:30:29 8 hr, 30 min, 28 sec 130.6 MB/s OK 0 2018-10-12, 06:25:34 8 hr, 33 min, 52 sec 129.8 MB/s OK 0

OK, thanks. Looking back, the initial problems I had setting up this container look like they were because of this need to restart the USG router to get the port forwarding working again. Also explains why it "magically" started working for me. I imagine the router upgraded itself and rebooted.

Everything is on my SSD Cache

No. I deleted the old one and set it all up from scratch. Tried reinstalling a couple of other times too. I'll keep sniffing around and see if I can see anything

Is anyone seeing huge CPU usage with this container? With no cameras connected, Zoneminder was pushing 2 of my 4 i5-2500 cores to around 80%. Stopping the container brings the CPU back to low single digits idle.

No one else uses this combo of containers and seeing this problem? Myself and one other than I have seen so far. I'm surprised as they are both popular containers.

Reporting this from the ngix thread where it didn't get any answers. I'm not sure where the problem is: I have an issue where when the ngix docker stops and restarts (nightly backup, etc) the port forwarding from my router (USG using the LSIO Unifi Docker) no longer works. I have to restart the Unifi container/controller for the port forwarding to work. Does anyone else have this combo of containers and experiencing the same problem ?

I have an issue where when this docker stops and restarts (nightly backup, etc) the port forwarding from my router (USG using the LSIO Unifi Docker) no longer works. I have to restart the Unifi container/controller for the port forwarding to work. Does anyone else have this combo of containers and experiencing the same problem ?

Thanks. I'll rethink whether I do it or not.

Is it possible to add the UNRaid GUI through this letsencrypt/nginx reverse proxy? I've tried but the formatting is all out of whack. I also need to turn off restricted and rely on the unraid WebGui for authentication.

Is it possible to get the UNRAID GUI working through this letsencrypt / nginx reverse proxy ? I tried but there were some pretty bad formatting errors that made it unusable.

Thanks, changing the localhost to 0.0.0.0 worked fine. Looking at me logs, up until dec 31 2017, my container was using 0.0.0.0 From Jan 1st 2018 onwards it was loading with localhost. I can only assume it was a change in the docker update

I came home to find the server had hung. Power cycled it to get it going with no problem. Started the letsencrypt docker so I could see the logs again and FMD letsencrypt started fine, pulled the certs and installed everything. I just checked from my phone and the site is accessible. I have no idea what it didn't work or why it works now. Nothing has changed. But I remember now why "have you tried restarting your machine" was the first question asked from support people. Thanks and sorry for wasting your time

Not sure if this was missed or not.

Two logs attached. One fresh start after zapping the container. One after a restart (in case it makes a difference). A couple of screen shots showing access to the nginx container from the interweb log_new.txt log_restart.txt

Correct. When I have the standalone nginx docker running, it gives me the default web pages whether I use http or https. This is is consistent on whether intranet or internet using my phone. I stop that docker and start the letsencrypt docker (same ports being used so no router or dns changes] and I get nothing. Again this is consistent whether intra or internet. I’ve killed the container a couple of times and recreated but the symptoms are the same.

OK, done. But https://192.168.1.10:7443/ gives me nothing here's the run command: root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='br-letsencrypt' --net='bridge' --privileged=true -e TZ="Asia/Singapore" -e HOST_OS="unRAID" -e 'EMAIL'='[email protected]' -e 'URL'='mydomain.com' -e 'SUBDOMAINS'='www' -e 'ONLY_SUBDOMAINS'='false' -e 'DHLEVEL'='2048' -e 'VALIDATION'='http' -e 'DNSPLUGIN'='' -e 'PUID'='99' -e 'PGID'='100' -p '81:80/tcp' -p '7443:443/tcp' -v '/mnt/cache/appdata/letsencrypt':'/config':'rw' 'linuxserver/letsencrypt' OK, I have confirmed my port forwarding / DNS settings are working fine by installing the plain ngix docker from LSIO and managed to access the default site it throws up via 80 and 443.

Quick question beiore I get too detailed. If I install the docker and start it, should I at least get some sort of page when I go to https://192.168.1.10 and/or http://192.168.1.10:81 I have port forwarded the router 443 to the container 443 and the router 80 to container 81. 81 is set to the containers 80 and 443 to 443. I am getting errors in the log file about not being able to get validation data etc but before I delve there I just want to make sure that ngix and the port forwarding is working at least internally before looking at the outside world. This was originally set up with it's own IP address but it's now back to the server's IP in case that was a pre-req.

Tried here in SG and Cloudfare are running 3rd. 8. 8. 4. 4 | Min | Avg | Max |Std.Dev|Reliab%| ----------------+-------+-------+-------+-------+-------+ - Cached Name | 0.001 | 0.002 | 0.002 | 0.000 | 100.0 | - Uncached Name | 0.004 | 0.050 | 0.256 | 0.078 | 100.0 | - DotCom Lookup | 0.007 | 0.036 | 0.174 | 0.060 | 100.0 | ---<-------->---+-------+-------+-------+-------+-------+ google-public-dns-b.google.com GOOGLE - Google LLC, US 8. 8. 8. 8 | Min | Avg | Max |Std.Dev|Reliab%| ----------------+-------+-------+-------+-------+-------+ - Cached Name | 0.002 | 0.002 | 0.004 | 0.000 | 100.0 | - Uncached Name | 0.005 | 0.055 | 0.291 | 0.083 | 100.0 | - DotCom Lookup | 0.007 | 0.030 | 0.174 | 0.054 | 100.0 | ---<-------->---+-------+-------+-------+-------+-------+ google-public-dns-a.google.com GOOGLE - Google LLC, US 208. 67.220.220 | Min | Avg | Max |Std.Dev|Reliab%| ----------------+-------+-------+-------+-------+-------+ - Cached Name | 0.001 | 0.002 | 0.002 | 0.000 | 100.0 | - Uncached Name | 0.003 | 0.126 | 0.408 | 0.115 | 100.0 | - DotCom Lookup | 0.040 | 0.205 | 0.472 | 0.128 | 100.0 | ---<O-OOO-OO>---+-------+-------+-------+-------+-------+ resolver2.opendns.com OPENDNS - OpenDNS, LLC, US 208. 67.222.123 | Min | Avg | Max |Std.Dev|Reliab%| ----------------+-------+-------+-------+-------+-------+ - Cached Name | 0.002 | 0.002 | 0.003 | 0.000 | 100.0 | - Uncached Name | 0.003 | 0.127 | 0.460 | 0.134 | 100.0 | - DotCom Lookup | 0.009 | 0.232 | 0.479 | 0.135 | 100.0 | ---<O-OOO-OO>---+-------+-------+-------+-------+-------+ resolver1-fs.opendns.com OPENDNS - OpenDNS, LLC, US 208. 67.222.222 | Min | Avg | Max |Std.Dev|Reliab%| ----------------+-------+-------+-------+-------+-------+ - Cached Name | 0.002 | 0.002 | 0.004 | 0.000 | 100.0 | - Uncached Name | 0.002 | 0.136 | 0.539 | 0.149 | 100.0 | - DotCom Lookup | 0.046 | 0.199 | 0.409 | 0.100 | 100.0 | ---<O-OOO-OO>---+-------+-------+-------+-------+-------+ resolver1.opendns.com OPENDNS - OpenDNS, LLC, US 208. 67.220.123 | Min | Avg | Max |Std.Dev|Reliab%| ----------------+-------+-------+-------+-------+-------+ - Cached Name | 0.002 | 0.002 | 0.004 | 0.000 | 100.0 | - Uncached Name | 0.003 | 0.139 | 0.447 | 0.122 | 100.0 | - DotCom Lookup | 0.039 | 0.231 | 0.467 | 0.106 | 100.0 | ---<O-OOO-OO>---+-------+-------+-------+-------+-------+ resolver2-fs.opendns.com OPENDNS - OpenDNS, LLC, US 1. 0. 0. 1 | Min | Avg | Max |Std.Dev|Reliab%| ----------------+-------+-------+-------+-------+-------+ - Cached Name | 0.002 | 0.003 | 0.005 | 0.000 | 100.0 | - Uncached Name | 0.003 | 0.098 | 0.235 | 0.096 | 100.0 | - DotCom Lookup | 0.009 | 0.100 | 0.210 | 0.092 | 100.0 | ---<-------->---+-------+-------+-------+-------+-------+ 1dot1dot1dot1.cloudflare-dns.com CLOUDFLARENET - Cloudflare, Inc., US 1. 1. 1. 1 | Min | Avg | Max |Std.Dev|Reliab%| ----------------+-------+-------+-------+-------+-------+ - Cached Name | 0.002 | 0.003 | 0.004 | 0.001 | 100.0 | - Uncached Name | 0.003 | 0.100 | 0.288 | 0.094 | 100.0 | - DotCom Lookup | 0.168 | 0.185 | 0.232 | 0.013 | 100.0 | ---<-------->---+-------+-------+-------+-------+-------+ 1dot1dot1dot1.cloudflare-dns.com MEGAPATH2-US - MegaPath Networks Inc., US 208. 67.222.220 | Min | Avg | Max |Std.Dev|Reliab%| ----------------+-------+-------+-------+-------+-------+ - Cached Name | 0.002 | 0.003 | 0.004 | 0.001 | 100.0 | - Uncached Name | 0.003 | 0.138 | 0.520 | 0.150 | 100.0 | - DotCom Lookup | 0.004 | 0.204 | 0.470 | 0.113 | 100.0 | ---<O-OOO-OO>---+-------+-------+-------+-------+-------+ resolver3.opendns.com OPENDNS - OpenDNS, LLC, US

Tried the Docker, maybe worse than the plugin. Docker: Testing download speed................................................................................ Download: 576.49 Mbit/s Testing upload speed.................................................................................................... Upload: 95.03 Mbit/s Plugin: Download 385Mbit Upload 180Mbit PC: Download 753Mbit Upload 897Mbit