Arkadin55

I have a rule on some of my subnets to force DNS queries to only go through my Pfsense. I had this rule disabled for my unRaid server, but mistakenly enabled it when I was making some changes the other day. So totally nothing to do with any problems with the Delugevpn container and just user error.

(Solved) Noticed this morning that both my Delugevpn and Sabnzbdvpn containers were not working. I could not connect to the web ui of either container. The logs show the following error "Error: error sending query: Could not send or receive, because of network error" in both containers. I assumed a problem with PIA and in the Deluge container tried all of the European endpoints with port forwarding, but all failed. The Sabnzbd container uses a different endpoint without port forwarding. I can connect to the web ui of both containers if vpn_enabled is set to false. I have made sure my account and password with PIA are working. I can successfully connect to the various endpoints I have tried in the Deluge container on another computer. I enabled debug and am attaching the supervisord log file. It shows "network error" and "Failed to resolve endpoint" on all the endpoints I have tried. The same errors show up in the Sabnzbd log files. Thanks in advance for any assistance. supervisord.log Edit: Found a problem with a firewall rule and now everything is working.

Not working for me either.

Just wanted to come back and mark this as solved. My most recent parity-check came back with no errors. It seems pretty certain to me that the problem was I forgot to change the ram clock speed after I added an additional 2 dimms. The recommended speeds differ depending on the number of dimms being used. This is a good example of why it's probably just better in most cases to leave your ram at stock speeds. Thanks again @johnnie.black and @trurl for your quick and helpful responses!

Will do. Thanks for your assistance and prompt replies.

Parity-check just completed with 2 errors on the same sectors as before. xanadu-diagnostics-20190119-1039.zip

Will do. Thanks.

Yes, I have returned the ram to non overlock speeds. I will do a memtest and then post my results. Seems like 24 hours is a commonly recommended amount of time to allow the test to run.

I had enabled D.O.C.P. and set it at the rated speed for my ram and motherboard on my original ram and never had any problems. I did recently return it to auto after reading in this forum about potential problems other were having. I'm wondering if I should remove the new ram I installed since it's the only thing that's changed since my last successful parity-check. If I do that, should I still run a memtest or should I do another parity-check?

I was planning to but have not yet done so. Should that be my next step?

Can someone please take a look at my diagnostics and help me interpret what's going on? Parity check found two errors. Also received message about raw read error rates for one drive and then another message that the rates were returned to normal. The drive with the errors is connected to a controller card and is my most recently added drive. I have also recently installed additional ram. I have done at least one parity-check since installing the drive on the controller and it was fine. I have not had any unclean shutdowns. I plan on checking the cables attached to the problem drive and the seating of the controller card, but was wondering what else I may need to be checking. xanadu-diagnostics-20190118-0937.zip