Lonewolf147

Latest version fixed my issues too! Thanks binhex!

Switched back to ver .03 this morning and all is working again.

Alright, sorry for the delay. It's been a day... iptables -S -P INPUT DROP -P FORWARD DROP -P OUTPUT DROP -A INPUT -p udp -m udp --sport 53 -j ACCEPT -A INPUT -p tcp -m tcp --sport 53 -j ACCEPT -A OUTPUT -p udp -m udp --dport 53 -j ACCEPT -A OUTPUT -p tcp -m tcp --dport 53 -j ACCEPT

I'll do the rest of the testing after work today. As for the openvpn config files, I'm using PIA's strong encryption file which uses port 1197

Looked through those, and I still don't see anything specifically blocking them (and I never programmed them to). Running netstat I see lots of references to port 53, with the TIME_WAIT status.

Changed it, but same issue. supervisord - Copy.log

Here are my own files, I did not downgrade yet. And for note, my STRICT_PORT_FORWARD is set to no. supervisord - Copy.log Sabnzbd comman execution.txt

I just updated to the latest version yesterday, and now I can't connect to the GUI, and I'm getting this in the logs: 2024-07-02 06:29:03.508182 [info] Host is running unRAID 2024-07-02 06:29:03.539106 [info] System information Linux 4b1397840fb5 6.1.79-Unraid #1 SMP PREEMPT_DYNAMIC Fri Mar 29 13:34:03 PDT 2024 x86_64 GNU/Linux 2024-07-02 06:29:03.602092 [info] SHARED_NETWORK not defined (via -e SHARED_NETWORK), defaulting to 'no' 2024-07-02 06:29:03.635790 [info] PUID defined as '99' 2024-07-02 06:29:03.680954 [info] PGID defined as '100' 2024-07-02 06:29:03.745159 [info] UMASK defined as '000' 2024-07-02 06:29:03.775618 [info] Permissions already set for '/config' 2024-07-02 06:29:03.813028 [info] Deleting files in /tmp (non recursive)... 2024-07-02 06:29:03.881986 [info] VPN_ENABLED defined as 'yes' 2024-07-02 06:29:03.924489 [info] VPN_CLIENT defined as 'openvpn' 2024-07-02 06:29:03.945996 [info] VPN_PROV defined as 'pia' 2024-07-02 06:29:04.020537 [info] OpenVPN config file (ovpn extension) is located at /config/openvpn/ca_toronto.ovpn 2024-07-02 06:29:04.147855 [info] VPN remote server(s) defined as 'ca-toronto.privacy.network,' 2024-07-02 06:29:04.183599 [info] VPN remote port(s) defined as '1197,' 2024-07-02 06:29:04.203870 [info] VPN remote protcol(s) defined as 'udp,' 2024-07-02 06:29:04.242027 [info] VPN_DEVICE_TYPE defined as 'tun0' 2024-07-02 06:29:04.289293 [info] VPN_OPTIONS not defined (via -e VPN_OPTIONS) 2024-07-02 06:29:04.315415 [info] NAME_SERVERS defined as '84.200.69.80,37.235.1.174,1.1.1.1,37.235.1.177,84.200.70.40,1.0.0.1' Error: error sending query: Could not send or receive, because of network error Error: error sending query: Could not send or receive, because of network error ... The error just keep repeating (I know it retries every 10 seconds or so). I've left it sit overnight and it was still erroring out this morning. I've restarted the app a few times with no luck. I don't know if this error is a VPN issue or not, but I have one other docker (qbittorrent) that is connecting to my VPN just fine, and I have my laptop and cell phone also connected to PIA just fine.

About an hour before I got home from work, I got notice that my Plex and all other apps went offline. I tried to login remotely to Unraid, but my connection timed out. Once I finally got home, I turned on the monitor and saw a bunch of repeating info about the kernel scrolling over and over instead of a login prompt. I couldn't break the process, so I turned off and restarted the whole system. Booted up just fine and is running again. Thankfully, I had log mirroring turned on, and I ran a diagnostics as soon as it was booted. I've attached both here. Does something stand out as to what the problem was? Something that I can look into to try and prevent it from happening again? syslog-previous valaskjalf-diagnostics-20240627-1434.zip

I've been getting tons of those faults all week. But I've also been doing a lot of drive data rebuilds. I did run memtest just this morning to check, and all the tests ran ok.

Yeah, I switched not only the cables, but which port they were each plugged in to. The power cable is a shared split cable from the power supply. I did change which power cables I was using too. I'm still in the rebuild of the one drive, so I'll have to see if it finishes without issue.

That didn't seem to make a difference. I switched out the power cables for those two drives specifically. And they both still failed with write errors after starting the data rebuilds. I did spend the time and did a complete preclear on one of them before putting it back in the system. Still no luck. I removed both drives from the array again, put the one data drive in and started another rebuild, while leaving the second parity drive offline for now. Here's my latest diagnostics too. valaskjalf-diagnostics-20231224-1437.zip

I'll give that a try.

I have an 18tb drive that had a write error, then became disabled. I pulled it, reformatted it, put it back in and the rebuild started. It crashed with another write error a few hours into the build. I had this happen once before a few weeks ago, but it performed the rebuild just fine, and and extended smart test came back with no errors. If there are physical issues with the platters, if I run the preclear app on it, will that mark all the bad sectors if there are any? Here's a sample from my log of the write error occurring. Does this say what is actually wrong? (full diagnostics attached) Dec 21 01:04:26 Valaskjalf kernel: sd 10:0:7:0: [sdy] tag#983 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=3s Dec 21 01:04:26 Valaskjalf kernel: sd 10:0:7:0: [sdy] tag#983 Sense Key : 0x2 [current] Dec 21 01:04:26 Valaskjalf kernel: sd 10:0:7:0: [sdy] tag#983 ASC=0x4 ASCQ=0x0 Dec 21 01:04:26 Valaskjalf kernel: sd 10:0:7:0: [sdy] tag#983 CDB: opcode=0x8a 8a 00 00 00 00 00 5a 44 c9 b0 00 00 04 00 00 00 Dec 21 01:04:26 Valaskjalf kernel: blk_print_req_error: 8 callbacks suppressed Dec 21 01:04:26 Valaskjalf kernel: I/O error, dev sdy, sector 1514457520 op 0x1:(WRITE) flags 0x4000 phys_seg 128 prio class 2 Dec 21 01:04:26 Valaskjalf kernel: md: disk17 write error, sector=1514457456 Dec 21 01:04:26 Valaskjalf kernel: md: disk17 write error, sector=1514457464 Dec 21 01:04:26 Valaskjalf kernel: md: disk17 write error, sector=1514457472 . . . Dec 21 01:04:26 Valaskjalf kernel: md: disk17 write error, sector=1514464600 Dec 21 01:04:26 Valaskjalf kernel: md: disk17 write error, sector=1514464608 Dec 21 01:04:26 Valaskjalf kernel: md: disk17 write error, sector=1514464616 Dec 21 01:04:26 Valaskjalf kernel: md: recovery thread: exit status: -4 valaskjalf-diagnostics-20231221-0249.zip

Yeah. I know. It's my current only way of getting the extra drives into the array. I've been running this for over a year now and never had that specific problem. I get that it is risky, and I'm willing to accept that. In the meantime, I'm slowly saving money to get a larger case and a few more HBA's in order to move all the drives to an internal configuration.

Alright, so I'm back up and running now. I don't know why exactly. I shut everything down so I could pull each drive and mark it's location on my spreadsheet. I checked the HBA, it and its cables seemed fine. I went back to my list of 'missing' drives. None of them were on the HBA. All 8 drives were in one external USB enclosure. I'm guessing that when I powered down the enclosure to get at the drive serial numbers, it reset something in it, and let unRaid see them all again. I successfully upgraded back to 6.12.6.

I'm just starting to dig around in the case. I think they may all be on my HBA. I can't verify until I check the serial numbers against the list. But, if that is the problem, then could the update have messed with the HBA drivers? I'm concerned that they didn't come back online when I downgraded, if it is a drivers issue.

I upgraded to 6.12.6 this morning from 6.12.4. When I rebooted, 8 of my drives showed missing. I tried rebooting again, but no luck. I've attached my diagnostics from just after the upgrade. I have downgraded back to 6.12.4 to try and get my system running again. EDIT - Downgrading didn't work. Upon reboot the drives were still missing. valaskjalf-diagnostics-20231204-0712.zip

Question - I have a script that monitors my CPU temp. I have a command built in to have it 'run' once a minute. The script runs just fine, my question is if I set it to run on Array Start, will it automatically be terminated when the array is stopped? If not, is there some command I can add to the script to check the status of the array and to kill the script if the array is stopped?

Just copy/pasting this code into User Scripts I have an error right at the beginning

My bad. I meant to put Raid1, not 0. I've edited my original post. Here's my diagnostics too. I'm looking at my Plex pool drives. valaskjalf-diagnostics-20230918-0808.zip

I currently have a two drive pool in a Raid 1 setup. One drive is 256GB, the other is 1TB. I know that I'm only getting 256 protection. I'm wondering if there is a way to now remove the 256 drive and have the 1tb drive take over the pool at the full 1tb size? Or is the 1tb drive now configured as a 256 in unraid? edit: I originally typed raid 0, I meant to say raid 1, so I changed the wording.

I just started seeing this error in my logs now too. I just upgraded to 6.12.4 yesterday. I usually keep a Firefox tab open with my Dashboard displayed, but for the past day I've actually had a tab open in Edge. When I went to look at it after it had sat for a few hours, all the animations on the dashboard (CPU/RAM/temps, etc) started going super fast, as if there were all fastforwarding to catch up with the current time. Then they all returned to normal speed. When I looked in the logs (checking for other issues) I found all these entries which coincide with the time that I was looking. Sep 10 01:39:22 Valaskjalf nginx: 2023/09/10 01:39:22 [crit] 12634#12634: ngx_slab_alloc() failed: no memory Sep 10 01:39:22 Valaskjalf nginx: 2023/09/10 01:39:22 [error] 12634#12634: shpool alloc failed Sep 10 01:39:22 Valaskjalf nginx: 2023/09/10 01:39:22 [error] 12634#12634: nchan: Out of shared memory while allocating message of size 28129. Increase nchan_max_reserved_memory. Sep 10 01:39:22 Valaskjalf nginx: 2023/09/10 01:39:22 [error] 12634#12634: *351766 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/devices?buffer_length=1 HTTP/1.1", host: "localhost" Sep 10 01:39:22 Valaskjalf nginx: 2023/09/10 01:39:22 [error] 12634#12634: MEMSTORE:01: can't create shared message for channel /devices Sep 10 01:39:22 Valaskjalf nginx: 2023/09/10 01:39:22 [crit] 12634#12634: ngx_slab_alloc() failed: no memory Sep 10 01:39:22 Valaskjalf nginx: 2023/09/10 01:39:22 [error] 12634#12634: shpool alloc failed Sep 10 01:39:22 Valaskjalf nginx: 2023/09/10 01:39:22 [error] 12634#12634: nchan: Out of shared memory while allocating message of size 16811. Increase nchan_max_reserved_memory. Sep 10 01:39:22 Valaskjalf nginx: 2023/09/10 01:39:22 [error] 12634#12634: *351769 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/disks?buffer_length=1 HTTP/1.1", host: "localhost" Sep 10 01:39:22 Valaskjalf nginx: 2023/09/10 01:39:22 [error] 12634#12634: MEMSTORE:01: can't create shared message for channel /disks Sep 10 01:39:23 Valaskjalf nginx: 2023/09/10 01:39:23 [crit] 12634#12634: ngx_slab_alloc() failed: no memory Sep 10 01:39:23 Valaskjalf nginx: 2023/09/10 01:39:23 [error] 12634#12634: shpool alloc failed Sep 10 01:39:23 Valaskjalf nginx: 2023/09/10 01:39:23 [error] 12634#12634: nchan: Out of shared memory while allocating message of size 28129. Increase nchan_max_reserved_memory. Sep 10 01:39:23 Valaskjalf nginx: 2023/09/10 01:39:23 [error] 12634#12634: *351776 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/devices?buffer_length=1 HTTP/1.1", host: "localhost" valaskjalf-diagnostics-20230910-0222.zip

That seemed to do it. Thanks!

Here you go. Does it matter if the app is running or not? This report is with it not started. And yes, looks like I have the same issue as the other guy. Sorry, I didn't see that. I don't see a solution for them either though. ClamAV-Inspect.txt