Burizado

I have this issue I believe due to my backups and other server maintenance activity on a nightly basis. I usually periodically review if there is anything that has not copied over, and manually copy them.

My downloads have been working fine using the PIA port forwarding endpoints @xxDeadbolt listed above. Just a question to those stating they are having issues with certain endpoints on PIA, are you using a file that has high availability? I know I have SEVERAL files waiting for someone with 100% availability. I just want to make sure people aren't mistaking VPN issues with file availability issues. Just a thought. EDIT: I have seen slow transfer numbers as well, but not on a file that has a high number of availability.

True! I have 3 drives on the way (should be here tomorrow), so I may do some testing on SATA_0 with one of them. See if it works.

Thanks for the report and info. Yeah, if I need to expand I am looking at getting two of the ICY DOCK 3 in 2 SATA since I have four 5.25" external bays open in the Fractal Design Define XL R2 I have my in my setup. I would need to get a HBA card to attach them as well. ...only if I need more space...only if I NEED more space....I keep telling myself. 😆

Ah, ok. Thanks for the extended info. I had my hopes up there a bit. hahaha. I just ordered 3 more drives since they were on sale, bringing my total up to 7, and thought I would get another one if I could do 8. 😁

Hey @Hoopster. Sorry I have been away for a while dealing with real life stuff. So, are you saying you can have a NVMe SSD AND 8 SATA drives connected? From what I was reading in the manual it sounded like using the NVMe you would not be able to use SATA_0. I am using the "SAMSUNG 970 EVO PLUS M.2 2280 1TB PCIe Gen 3.0" as my NVMe device and was assuming this takes the space of SATA_0. If you or anyone else is using the NVMe slot and all 8 SATA ports without issue this would be awesome news! Quoted from the manual page 32: "These SATA3 connectors support SATA data cables for internal storage devices with up to 6.0 Gb/s data transfer rate. *The M.2 slot (M2_1) is shared with the SATA_0 connector. When M2_1 is populated with a M.2 SATA3/ PCIE3.0(x4 or x2) module, SATA_0 is disabled." ..and image of where I am seeing this:

The same thing happens to me and I am using PIA. I have seen no errors in the logs, and I am able to access PIA via my phone with the same endpoint. It seems to resolve itself after a while, which I'm not really sure what side the error is on PIA or my network. Something says PIA if it is resolving itself without any changes on my side. I thought of opening a support case with PIA but I cannot replicate the error on any other device, which again seems to point to my setup. Since there are no errors in my logs I'm not sure what they would have to go on either.

This time it might be a different sensor. @Hoopster which sensor are you seeing in System Temp plugin? It looks like it is still correlated to AUXTIN3 whatever that is. I believe we saw this last time, as I was going back through the thread to remember what we were seeing previously.

Just had my MB Temp go up this morning. Will be letting William from ASRock Support know.

Hmmm, well there goes that BIOS fix. I'm sure William will be thrilled to hear that. Mine still seems to be good (touch wood) with these versions:

Not that I am aware of, but might be a good enhancement for unRAID as a whole, not just specific to our MB and CPU. My though is it might be problematic for people without GPUs, but if there was a way to turn it on and off on the dashboard.

Thanks for the suggestion binhex. Yeah, still not able to access the webui from another device. To add further information, I don't think it is just the webui. My drives are set to spin down when not in use, and I am seeing no activity on any of the drives, cache or array, when the docker is up and 'running' and I am unable to access the webui. Typically I see at least the cache and one drive active in the Main tab. Also I have my Windows VM set to use the privoxy and it is not able to access any websites like when the docker is shut down, and states to 'check my proxy settings'. ... as I was in the middle of testing, and now it is back up and working. This is so weird.

I checked and the files on the PIA website are the same I have been using. I updated them anyway, but still not fixed.

Correct. Everything in the log shows it starts just fine, but the webui will not come up. If I turn off the vpn via the VPN_ENABLED container variable I can view the webui. This makes me believe it is something on the PIA side, specifically with my account, since I have not heard of anyone else having an issue here. I am assuming many others are using PIA, and some have to be using the Switzerland endpoint. I saw there are the DELUGE_DAEMON_LOG_LEVEL and DELUGE_WEB_LOG_LEVEL variables in the setup. Would setting these to 'debug' add anymore details I can look at? I mentioned before that I have seen this issue off and on over the past week, but it always 'magically' fixed itself without any intervention from me, which again points me to something changing on the PIA side.

Update to BIOS went well. Temp reading dropped down to a normal reading (26C). I will be monitoring to make sure it stays that way.

Is anyone having any issues with PIA today? I am using the Switzerland endpoint, and all day it seems I cannot access the webui in Deluge. I tried disabling the vpn via the VPN_ENABLED container variable, and I am able to access the webui fine. I can also connect to PIA Switzerland from my phone and other devices, so it doesn't seem like an 'outage' unless it is something specific to unRAID or dockers. I have had similar issues in the past weeks but it has always 'magically' come back on, which makes me think something on the PIA side. Attaching my log file but everything looks fine in there (I took out my credentials from the log). I'll be the first to admit I am fairly new to unRAID and dockers, so I do not claim to be an expert. My next step I think will be to try a different endpoint, then open a ticket with PIA. supervisord.log

My plan is to update this weekend. I will report what I find out.

Thanks Hoopster! So it sounds like it was a "no" to rolling in the changes into the fully supported released BIOS I am guessing. I am planning on updating in the next few days and will report back, unless you get to it sooner than me Hoopster. 😉

...and back to working, just after 09:00 EDT.

Although, with binhex stating this, it makes me feel the same. I am guessing something on the PIA side. I saw they did have port forwarding issues earlier this month. I am not certain what logs to send them to open a support ticket with them. I may just open the ticket then send logs as requested.

Yeah mine worked all day (At least I think it did. I was not monitoring it all day), but this morning I see the same issue, logs look fine but unable to open the deluge webui. I did add the PIA app to my phone just to try an external connection outside my unraid server, and it connects just fine and works. This makes me think something is up with the docker vpn version. I did try setting the VPN_ENABLED to 'no' and I was able to access the webui. Something must be up with the vpn connection inside the docker I am thinking, since the connection works fine from my phone, to the same endpoint (Switzerland).

Well, I took some time doing some other chores around the house, came back, and the webgui is working again. Wonder if there was an outage or something with PIA that affected it. Glad it is working again.

Looking a little more, I am seeing movement in the deluged.log file. So I think it is working on the backend, but just not able to open the webui. I want to try disabling the VPN, but how do I pause all my current file downloads without the webui? I would like to test with just one download. I will look in the config files if there is a setting.

I am seeing a similar issue I think. It looks like everything starts fine in the log, but cannot open the webui. Here is the end of my log. Not seeing anything abnormal above that. For reference I am using PIA with Switzerland as my endpoint. 2020-04-25 08:48:38,134 DEBG 'watchdog-script' stdout output: [info] Deluge process started [info] Waiting for Deluge process to start listening on port 58846... 2020-04-25 08:48:38,247 DEBG 'watchdog-script' stdout output: [info] Deluge process listening on port 58846 2020-04-25 08:48:47,043 DEBG 'watchdog-script' stdout output: Setting "random_port" to: False Configuration value successfully updated. 2020-04-25 08:48:48,846 DEBG 'watchdog-script' stdout output: Setting "listen_ports" to: (46278, 46278) Configuration value successfully updated. 2020-04-25 08:48:50,450 DEBG 'watchdog-script' stdout output: [info] No torrents with state 'Error' found 2020-04-25 08:48:50,451 DEBG 'watchdog-script' stdout output: [info] Starting Deluge Web UI... [info] Deluge Web UI started 2020-04-25 08:48:50,456 DEBG 'watchdog-script' stdout output: [info] Attempting to start Privoxy... 2020-04-25 08:48:50,450 DEBG 'watchdog-script' stdout output: [info] No torrents with state 'Error' found 2020-04-25 08:48:50,451 DEBG 'watchdog-script' stdout output: [info] Starting Deluge Web UI... [info] Deluge Web UI started 2020-04-25 08:48:50,456 DEBG 'watchdog-script' stdout output: [info] Attempting to start Privoxy... 2020-04-25 08:48:51,461 DEBG 'watchdog-script' stdout output: [info] Privoxy process started [info] Waiting for Privoxy process to start listening on port 8118... 2020-04-25 08:48:51,466 DEBG 'watchdog-script' stdout output: [info] Privoxy process listening on port 8118

Ha ha ha! AWESOME! I was just drafting up a reply back to him too. I still will send it and just note that I heard he was already on it. 😁 I debated just starting a group email so he doesn't have to contact us separately, but separate tickets might put more preasure on the BIOS team for a fix.