hansolo77

I have 2 set up. One is with dizqueTV and the other is OTA which grabs guide data from zap2it.

I see.. Thanks! I'm having another problem now that's actually more frustrating. When I load up Plex and look at my guide, some of shows have the actual show art, where others are just like a screenshot grab of a character. How do I fix that?

I'm using the plain vanilla xTeve docker... I'm pretty sure I have it all set up and working. Curious to know if there is a way to have it buffer to the RAM rather than the drive the docker is installed too. Just looking for any kind of performance boost I can get.

Darn, 1st of the month and I'm getting the same symptoms again. Lots of sync errors and the same errors in the system log as posted in the OP. I've gone back through and re-read the thread. Apparently my brain is numb.. I completely glazed over the suggestion you had of simply moving the drives around. I'll give that a shot.

Cool. We're not having any issues with those. He's not using VM's (yet). We also only have the 1 parity drive right now. Thanks for the quick response.

Hey guys. I built my first Unraid server a few years ago and gave it to my brother when I decided to upgrade. Well about a week ago his stopped working. He claimed he smelled burning plastic. After a days worth of digging over voice chat, we finally got the motherboard out and found the back of it was scorched! UHG. As popular as this motherboard was when I bought it, I can't find it again ANYWHERE. The motherboard is an ASRock Rack E3C224-4L. We have an Intel Xeon E3-1200 CPU installed (socket is LGA 1150), along with 32gb DDR3-1600 ECC RAM. I have a controller card (PCIe-16 slot) and expansion card (PCIe-16x slot) and an old Hauppauge TV Tuner card in an old PCI slot. The onboard USB connector has the Unraid flash drive in it. So as I said, I can't find a replacement motherboard. I found a site I never heard of (PriceBlaze) who offered it. I bought it, and a week has gone by with no status updates. Then today I get an email from them saying that they had to cancel the order because they couldn't get it in. Another option is from ANOTHER unknown site called Tech4Drive. I don't know if I trust these sites. They're not BIG names like Amazon, Newegg, Microcenter. But, to avoid another cancellation, I attempted to contact Tech4Drive for confirmation they have it in stock before I buy. Still waiting to hear back. So moving on to what may be an even bigger ordeal... complete hardware replacement. As far as we can tell, the only dead part was the motherboard. So we're just looking to replace that for now. The CPU, RAM, and everything else seems to be ok. So I'm on Newegg looking for a compatible replacement. They only have 4 options that support the CPU/RAM, and only 1 really seems to fit our needs as far as expansion slots. The seller (not Newegg?) is in China, but offers free expedited FedEx shipping. So I can get it in about 3-5 days for $99, not bad. The bad part, I don't know how Unraid will handle it. Thus brings my questions: Will Unraid's license still function if used on a new motherboard? If not, is there a way to transfer the license without having to buy a new one? If getting a new license is required, will that result in him losing all the data currently on all his drives? He really can't afford this, as it has his only copies of photos (this was a backup server after all). If licensing is not an issue, will getting completely new hardware cause any unforeseen headaches? I'm already aware we'll have to navigate the BIOS and enable/disable things, etc. But it should be as simple as dropping in place right? Thanks guys for this awesome software and any support you may have to offer. I've not made any purchases yet, so I'm definitely still open to suggestions. If you can find a place selling our specific motherboard, I think that would be the most ideal. If anybody can think of a better replacement option, let me know that too! For reference, here is the one from China I'm looking at.

I haven't run the docker since this mess with the security happened. I just tried running it and didn't come across any issues. However, it indicates I'm running v6.6 and that v6.8 is available. According to Unraid though, I'm on the latest version, which is inaccurate.

Hey guys! I've been running NZBGET for a while now. Here lately I've noticed every single day I have to login to docker screen. I keep the docker up and running all day (for obvious reasons), and have it's screen running on a dedicated browser tab. When I get home from work and go to that tab to check history/errors/etc it always reports a communication error and requires me to refresh the tab and re-login. At first I thought this would be due to a constant stream of updates, but I just checked the github and and it's not been updated in a while. Any ideas what could be going on? Does the docker just time out after a set time? I checked the logs for the docker, all it seems to indicate is a history of files downloaded/extracted/etc. Thanks for any help!

I'm going to mark this as resolved. I had another 100% successful (without error) parity check and the logs have been clean. I definitely feel at this point that the problem was with the SATA connector. Had a crack in it, so it was apparently keeping the connection loose. If things change, I'll try to remember to reopen this thread. Thanks for being a support!

Not yet, that's the surprising thing. Everything is good.

Just to quickly follow up. I took another look at the SATA cables connecting my parity drives. One of them had a loose connector plug on one end and the other one was pinched under the motherboard. I was trying to maneuver them out of the way to improve air flow. I went ahead and replaced both cables and just left them “in the way” for now. I did another parity check with recovery and it found another 6k in errors. But it fixed them and I ran another check that came back clean. I then did a reboot and another check and it was clean. Then I rebooted again and set the scheduler to parity check on every Sunday just so I’m not waiting a month for the next checks. It came back clean again last night. So it might have been bad cables the whole time. I’ll wait another week with typical usage and another check before I mark this as resolved. I hate that it’s been doing this but I hate even more if it was a simple fix lol. Fingers crossed.

Ok, was I correct in the procedure? I've never done this before. Real Quick Edit: I was checking out the Parity Drives just now, did a quick self test on them to see that they're still ok which they are). I noticed in the SMART data that neither drive has had any reallocated sectors, and really show no signs of pre-fail. However, what I ALSO noticed was that the 2nd drive is running at 6.0 Gb/s SATA speed while the first drive is only running at 1.5 Gb/s SATA speed. Maybe there's a misconfiguration somewhere. They should both be running 6 right?

Yeah my HBA is completely full with drives, no spares left. Is it possible that I'm having trouble because the parities are on the motherboard and not connected to the HBA? Like a speed problem, or something like cross compatibility (using SATA rather than SAS (even though all my drives are SATA)). I have no problem troubleshooting, it's what I like to do. Just getting irritated with all the errors cropping up, when there shouldn't be any. Before trying to swap out the drives entirely, do you think changing SATA ports on the motherboard might help? I'm not looking at it right now, but I think the motherboard had 4 or 6 SATA ports and the parities are only using 1 and 2. If/when I go to swap the drives, how do I go about doing that? Am I correct in this procedure: Stop Array Unassign Parity 1 and Drive 2 Physically Remove Parity 1 and Drive 2 Start Array (Detects drives are missing) Stop Array Replace alternates (Disk 2 to Parity 1, and Parity 1 to Disk 2) Reassign New Parity 1 and Drive 2 Start Array That would then either automatically start a parity rebuild, or I'd have to manually start it. If I'm correct, do I need to do anything to the drives prior to rebuilding, like pre-clear them first?

Sorry, forgot to add that. kyber-diagnostics-20221005-1332.zip

I've been having recurring issues with my monthly parity checks. Some months go fine with 0 errors. Then occasionally I'll get a couple hundred. Then again, back to 0. My power went out on 9/28, and the system should have shut down safely (I'm on a UPS). Apparently it didn't, as the system started a parity check once it was back online. The UPS issue needs to be addressed at a later time. Anyway, the parity check returned with over 160k errors. I'm tired of seeing it. Before doing anything, I shut the server down and unplugged and replugged all the power and data cables going from the HBA to the backplane, and the parity drives to the motherboard. I also removed and reseated each RAM stick and gave the CPU some new thermal grease and reseated that. I then pulled each drive, blew out the connectors and reseated those as well. I then rebooted into a MEMTEST drive and ran it for 24 hours. After 4 complete passes I rebooted back into Unraid and did another manual check. After about 3 hours it started hitting errors so I stopped it and restarted it doing a corrective pass. This time it started failing within about 20 minutes, but by the end of the cycle it only found and correct 16 errors. Ok.. that's a lot better than THOUSANDS. So I rebooted once more, and did a manual check once again. Got home today and it came back clean. Whew. I obviously missed my 10/1 scan, but given what I just went through, I think I'm ok. The next thing I did was to run an extended Fix Common Problems scan. It found a bunch of files with wrong permissions. Might have been due to the parity corrections, hard to say. I went in and started doing a Docker Safe Perms scan to fix the permissions. While running that, I had a log window open (system log, not the tool log). It was throwing up a bunch of errors (sorry if this spams the post) Oct 4 14:56:22 Kyber emhttpd: cmd: /usr/local/emhttp/plugins/fix.common.problems/scripts/newperms.sh Oct 4 14:58:02 Kyber kernel: ata3.00: exception Emask 0x10 SAct 0xa5effff9 SErr 0x90202 action 0xe frozen Oct 4 14:58:02 Kyber kernel: ata3.00: irq_stat 0x00400000, PHY RDY changed Oct 4 14:58:02 Kyber kernel: ata3: SError: { RecovComm Persist PHYRdyChg 10B8B } Oct 4 14:58:02 Kyber kernel: ata3.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata3.00: cmd 60/40:00:40:11:6a/00:00:3b:00:00/40 tag 0 ncq dma 32768 in Oct 4 14:58:02 Kyber kernel: res 40/00:18:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata3.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata3.00: failed command: WRITE FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata3.00: cmd 61/c0:18:80:ea:91/00:00:43:00:00/40 tag 3 ncq dma 98304 out Oct 4 14:58:02 Kyber kernel: res 40/00:18:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata3.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata3.00: failed command: WRITE FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata3.00: cmd 61/40:20:c0:d7:61/00:00:3c:00:00/40 tag 4 ncq dma 32768 out Oct 4 14:58:02 Kyber kernel: res 40/00:18:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata3.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata3.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata3.00: cmd 60/40:28:40:09:91/00:00:43:00:00/40 tag 5 ncq dma 32768 in Oct 4 14:58:02 Kyber kernel: res 40/00:18:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata3.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata3.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata3.00: cmd 60/80:30:00:71:52/00:00:0c:00:00/40 tag 6 ncq dma 65536 in Oct 4 14:58:02 Kyber kernel: res 40/00:18:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata3.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata3.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata3.00: cmd 60/80:38:40:70:52/00:00:0c:00:00/40 tag 7 ncq dma 65536 in Oct 4 14:58:02 Kyber kernel: res 40/00:18:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata3.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata3.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata3.00: cmd 60/80:40:80:e1:05/00:00:0a:00:00/40 tag 8 ncq dma 65536 in Oct 4 14:58:02 Kyber kernel: res 40/00:18:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata3.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata3.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata3.00: cmd 60/40:48:40:93:a6/00:00:09:00:00/40 tag 9 ncq dma 32768 in Oct 4 14:58:02 Kyber kernel: res 40/00:18:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata3.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata3.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata3.00: cmd 60/40:50:80:b3:67/00:00:08:00:00/40 tag 10 ncq dma 32768 in Oct 4 14:58:02 Kyber kernel: res 40/00:18:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata3.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata3.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata3.00: cmd 60/80:58:c0:b2:67/00:00:08:00:00/40 tag 11 ncq dma 65536 in Oct 4 14:58:02 Kyber kernel: res 40/00:18:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata3.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata3.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata3.00: cmd 60/20:60:e0:c5:c5/00:00:07:00:00/40 tag 12 ncq dma 16384 in Oct 4 14:58:02 Kyber kernel: res 40/00:18:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata3.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata3.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata3.00: cmd 60/20:68:a0:cc:05/00:00:06:00:00/40 tag 13 ncq dma 16384 in Oct 4 14:58:02 Kyber kernel: res 40/00:18:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata3.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata3.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata3.00: cmd 60/40:70:c0:70:1f/00:00:44:00:00/40 tag 14 ncq dma 32768 in Oct 4 14:58:02 Kyber kernel: res 40/00:18:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata3.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata3.00: failed command: WRITE FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata3.00: cmd 61/40:78:40:d8:61/00:00:3c:00:00/40 tag 15 ncq dma 32768 out Oct 4 14:58:02 Kyber kernel: res 40/00:18:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata3.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata3.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata3.00: cmd 60/40:80:80:2a:16/00:00:44:00:00/40 tag 16 ncq dma 32768 in Oct 4 14:58:02 Kyber kernel: res 40/00:18:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata3.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata3.00: failed command: WRITE FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata3.00: cmd 61/40:88:00:04:5a/00:00:3b:00:00/40 tag 17 ncq dma 32768 out Oct 4 14:58:02 Kyber kernel: res 40/00:18:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata3.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata3.00: failed command: WRITE FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata3.00: cmd 61/40:90:80:d2:8d/00:00:3b:00:00/40 tag 18 ncq dma 32768 out Oct 4 14:58:02 Kyber kernel: res 40/00:18:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata3.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata3.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata3.00: cmd 60/40:98:80:43:e9/00:00:42:00:00/40 tag 19 ncq dma 32768 in Oct 4 14:58:02 Kyber kernel: res 40/00:18:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata3.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata3.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata3.00: cmd 60/40:a8:80:47:91/00:00:43:00:00/40 tag 21 ncq dma 32768 in Oct 4 14:58:02 Kyber kernel: res 40/00:18:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata3.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata3.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata3.00: cmd 60/40:b0:40:36:23/00:00:44:00:00/40 tag 22 ncq dma 32768 in Oct 4 14:58:02 Kyber kernel: res 40/00:18:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata3.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata3.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata3.00: cmd 60/40:b8:40:70:91/00:00:43:00:00/40 tag 23 ncq dma 32768 in Oct 4 14:58:02 Kyber kernel: res 40/00:18:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata3.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata3.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata3.00: cmd 60/40:c0:80:48:91/00:00:43:00:00/40 tag 24 ncq dma 32768 in Oct 4 14:58:02 Kyber kernel: res 40/00:18:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata3.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata3.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata3.00: cmd 60/40:d0:00:7a:36/00:00:43:00:00/40 tag 26 ncq dma 32768 in Oct 4 14:58:02 Kyber kernel: res 40/00:18:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata3.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata3.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata3.00: cmd 60/40:e8:c0:4c:2a/00:00:44:00:00/40 tag 29 ncq dma 32768 in Oct 4 14:58:02 Kyber kernel: res 40/00:18:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata3.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata3.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata3.00: cmd 60/00:f8:c0:11:6a/01:00:3b:00:00/40 tag 31 ncq dma 131072 in Oct 4 14:58:02 Kyber kernel: res 40/00:18:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata3.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata3: hard resetting link Oct 4 14:58:02 Kyber kernel: ata2.00: exception Emask 0x10 SAct 0x3b9ffffd SErr 0x90202 action 0xe frozen Oct 4 14:58:02 Kyber kernel: ata2.00: irq_stat 0x00400000, PHY RDY changed Oct 4 14:58:02 Kyber kernel: ata2: SError: { RecovComm Persist PHYRdyChg 10B8B } Oct 4 14:58:02 Kyber kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata2.00: cmd 60/40:00:40:d3:8d/00:00:3b:00:00/40 tag 0 ncq dma 32768 in Oct 4 14:58:02 Kyber kernel: res 40/00:10:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata2.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata2.00: failed command: WRITE FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata2.00: cmd 61/c0:10:80:ea:91/00:00:43:00:00/40 tag 2 ncq dma 98304 out Oct 4 14:58:02 Kyber kernel: res 40/00:10:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata2.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata2.00: cmd 60/40:18:c0:13:5a/00:00:3b:00:00/40 tag 3 ncq dma 32768 in Oct 4 14:58:02 Kyber kernel: res 40/00:10:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata2.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata2.00: cmd 60/40:20:c0:11:5a/00:00:3b:00:00/40 tag 4 ncq dma 32768 in Oct 4 14:58:02 Kyber kernel: res 40/00:10:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata2.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata2.00: failed command: WRITE FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata2.00: cmd 61/40:28:c0:d7:61/00:00:3c:00:00/40 tag 5 ncq dma 32768 out Oct 4 14:58:02 Kyber kernel: res 40/00:10:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata2.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata2.00: cmd 60/40:30:80:83:22/00:00:3b:00:00/40 tag 6 ncq dma 32768 in Oct 4 14:58:02 Kyber kernel: res 40/00:10:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata2.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata2.00: cmd 60/40:38:80:2a:16/00:00:44:00:00/40 tag 7 ncq dma 32768 in Oct 4 14:58:02 Kyber kernel: res 40/00:10:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata2.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata2.00: cmd 60/80:40:00:71:52/00:00:0c:00:00/40 tag 8 ncq dma 65536 in Oct 4 14:58:02 Kyber kernel: res 40/00:10:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata2.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata2.00: cmd 60/80:48:40:70:52/00:00:0c:00:00/40 tag 9 ncq dma 65536 in Oct 4 14:58:02 Kyber kernel: res 40/00:10:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata2.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata2.00: cmd 60/80:50:80:e1:05/00:00:0a:00:00/40 tag 10 ncq dma 65536 in Oct 4 14:58:02 Kyber kernel: res 40/00:10:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata2.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata2.00: cmd 60/40:58:40:93:a6/00:00:09:00:00/40 tag 11 ncq dma 32768 in Oct 4 14:58:02 Kyber kernel: res 40/00:10:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata2.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata2.00: cmd 60/40:60:80:b3:67/00:00:08:00:00/40 tag 12 ncq dma 32768 in Oct 4 14:58:02 Kyber kernel: res 40/00:10:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata2.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata2.00: cmd 60/80:68:c0:b2:67/00:00:08:00:00/40 tag 13 ncq dma 65536 in Oct 4 14:58:02 Kyber kernel: res 40/00:10:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata2.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata2.00: cmd 60/20:70:e0:c5:c5/00:00:07:00:00/40 tag 14 ncq dma 16384 in Oct 4 14:58:02 Kyber kernel: res 40/00:10:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata2.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata2.00: cmd 60/20:78:a0:cc:05/00:00:06:00:00/40 tag 15 ncq dma 16384 in Oct 4 14:58:02 Kyber kernel: res 40/00:10:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata2.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata2.00: cmd 60/40:80:40:70:91/00:00:43:00:00/40 tag 16 ncq dma 32768 in Oct 4 14:58:02 Kyber kernel: res 40/00:10:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata2.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata2.00: failed command: WRITE FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata2.00: cmd 61/40:88:40:d8:61/00:00:3c:00:00/40 tag 17 ncq dma 32768 out Oct 4 14:58:02 Kyber kernel: res 40/00:10:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata2.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata2.00: failed command: WRITE FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata2.00: cmd 61/40:90:00:04:5a/00:00:3b:00:00/40 tag 18 ncq dma 32768 out Oct 4 14:58:02 Kyber kernel: res 40/00:10:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata2.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata2.00: failed command: WRITE FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata2.00: cmd 61/40:98:80:1b:18/00:00:44:00:00/40 tag 19 ncq dma 32768 out Oct 4 14:58:02 Kyber kernel: res 40/00:10:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata2.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata2.00: failed command: WRITE FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata2.00: cmd 61/40:a0:80:d2:8d/00:00:3b:00:00/40 tag 20 ncq dma 32768 out Oct 4 14:58:02 Kyber kernel: res 40/00:10:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata2.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata2.00: cmd 60/40:b8:40:10:18/00:00:44:00:00/40 tag 23 ncq dma 32768 in Oct 4 14:58:02 Kyber kernel: res 40/00:10:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata2.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata2.00: cmd 60/40:c0:40:45:10/00:00:43:00:00/40 tag 24 ncq dma 32768 in Oct 4 14:58:02 Kyber kernel: res 40/00:10:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata2.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata2.00: cmd 60/c0:c8:80:ca:f2/00:00:42:00:00/40 tag 25 ncq dma 98304 in Oct 4 14:58:02 Kyber kernel: res 40/00:10:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata2.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata2.00: cmd 60/40:d8:80:ba:79/00:00:43:00:00/40 tag 27 ncq dma 32768 in Oct 4 14:58:02 Kyber kernel: res 40/00:10:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata2.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata2.00: cmd 60/40:e0:80:b8:79/00:00:43:00:00/40 tag 28 ncq dma 32768 in Oct 4 14:58:02 Kyber kernel: res 40/00:10:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) Oct 4 14:58:02 Kyber kernel: ata2.00: status: { DRDY } Oct 4 14:58:02 Kyber kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 4 14:58:02 Kyber kernel: ata2.00: cmd 60/c0:e8:c0:b2:1d/00:00:44:00:00/40 tag 29 ncq dma 98304 in Oct 4 14:58:02 Kyber kernel: res 40/00:10:80:ea:91/00:00:43:00:00/40 Emask 0x10 (ATA bus error) I checked the MAIN tab and I believe ATA2 and ATA3 are my Parity 1 and Parity 2 drives. When I click on the disk log for each of those drives, I get a similar log of errors, of which are not on any of the actual array drives. So is this an indication that my parity drives are failing? If so, that would explain a lot such as the frequent parity checks failing with so many errors. The strange thing though, neither drive seems to indicate anything wrong in the SMART logs. If, in fact, this does indicate a possible failure or corruption, how does one go about replacing the Parity Drives? I'm due for an upgrade soon anyway, these are 12TB drives and I'd like to maybe start rebuilding up to 20TB. Just looking for some advice from the better educated people out there. Thanks!

I'm cautious to apply that fix. Without reading the details, it appears to be a flag to disable some type of security, which is never a good thing. Can anybody confirm this is a safe thing to do? I'll stick to the roll back until I hear otherwise.

I'm having the same problem. How do I roll back?

While still waiting for a reply, I did a thing. It's nothing new, I've done it many times before. I went into the TOOLS tab and ran the "Docker Safe New Perms" tool. After that I rebooted and ran another extended test. Now it's saying "No problems found". I wouldn't think much of this, except for that nothing has changed "setup-wise". My dockers and shares still have the same permissions they did before, and new files are added daily. My Macrium backups are daily with multiple types done through-out the week. The "ARR" dockers are always grabbing things. So I'm lost. Why would it be throwing up alerts when I run a test every couple of months without making any changes and then again not have ANY problems for days? Very confusing.

FCP has been running great with it's quick checks, but lately when I do an extended test I'm getting some errors. The error "section" is labeled: I know this is kind of a generic section. I do use Sonaar/Radaar, but many of the files that are in error are not in the paths those dockers use. Some of them are, but not all. For instance: I have a computer that creates a daily backup using Macrium. I created a network share for it to store the files in. I thought I had the share set up right, but maybe not. The Macrium software requires me to provide a username/password to access the share when I do a restore, the anonymous access doesn't work in the recovery environment. I think this might be what's causing the problem here. It writes with the ownership of the user that will be accessing it during restore. So, I think these might be false/positives. Another series of files I'm getting issues with, is the random Sonarr/Radarr finds. Most of them are coming up as either " nobody/users (99/100) 0640 " or " nobody/users (99/100) 0660 " Since it's saying that might be a permission problem on the new downloads, it bugs me why it's a "random" appearance. What settings should I be using for those dockers? For instance, in the docker config for Sonarr, it is set to use "Key 1 (PUID) = 99" and "Key 2 (PGID) = 100". Then in the docker itself, under "Settings->Media Management", I have it set to NOT set permissions, the default setting says "755", and "chown group" is blank". Should I be changing anything here? Thanks guys! Love Unraid, and this plugin!

I haven't successfully solved the problem "YET". I've got it running another parity check now. But it's not come up with any sync errors since I started it 8 hours ago, and it was just a couple hours in before when it started throwing up errors. The thing about this that bugged me, I completely forgot about leaving the RAM speed at default. I had it set, and it was working. When I installed the additional memory, the BIOS detected the change and reset it's defaults. Only then did I go in and change it back from 2666mhz (default/auto) to the RAM spec of 3600mhz. It just slipped my mind about not changing that. It was only after I remembered a year ago having crazy amounts of parity errors that had me go back and find my old thread where the RAM speed was the issue. It's really confusing actually. The spec sheet for the motherboard says it can support all these crazy speeds, even up to like 4k as long as the CPU is a 3rd gen. Then I look at the spec sheet for the CPU and it too says i can support up to the 4k mhz speeds. So in my mind, if the RAM I buy is built with the label indicating it's 3600mhz, I just automatically start tweaking BIOS settings to get that speed. It's what everything else should support. But it wasn't until I saw the post/screenshot that indicated the Ryzen processors are only designed to run RAM at 3200mhz MAX for stability, that I realized I was overclocking. Strange thing is, I don't remember if I underclocked it to 3200mhz before or not. By default, when the BIOS detects the RAM it sets it to 2666mhz. So that's what I have it set to now. For added assurance, I did go ahead and disable the C-States. There is another setting for controlling the CPU idle power, which I set to something like "standard" versus "low" or "disabled" (I don't recall what it was exactly). I think by default this motherboard sets it to disabled, which allows it to have the full range of power. I read that having that capability can cause corruption if the CPU idles harshly, or something like that. Another setting somebody suggested checking was the IOMMU. The options are AUTO, ENABLED, and DISABLED. I left it set to auto for now. I feel disabling may prevent the 10G NIC from being usable in my VM's, which I need. But I didn't want to completely ENABLE it, if IOMMU was in fact givng me trouble and the AUTO just enables what it needs. Anyway, so far so good. I hope this works. I really miss having my data. I don't want to risk accessing any part of the array until the check is completed 100% clean.

Yeah, we went through this before. I forgot about it honestly. When I installed the additional RAM, the BIOS reset. So I went in and set it all back up the way I thought it should be. I found my old thread here and I'm going back into the BIOS now to adjust things. Hopefully that's all I need.

Just reporting back in. The problems I had were all solved. I have been sitting happy with no errors for months. That is, until the start of this month. Started getting errors again. Rather than updating this thread, which is no longer related to shut down issues, I've created a new thread for my new troubles.

Yup.. I had a feeling that would be necessary. I just didn't know if it was something I can do while the check is running. One quickie... I logged into the terminal to see if I could catch the log of the parity check, and I'm seeing a whole lot of red: Aug 15 11:21:44 Kyber nginx: 2022/08/15 11:21:44 [error] 9999#9999: nchan: Out of shared memory while allocating message of size 503. Increase nchan_max_reserved_memory. Aug 15 11:21:44 Kyber nginx: 2022/08/15 11:21:44 [error] 9999#9999: *783811 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/devices?buffer_length=1 HTTP/1.1", host: "localhost" Aug 15 11:21:44 Kyber nginx: 2022/08/15 11:21:44 [error] 9999#9999: MEMSTORE:00: can't create shared message for channel /devices Aug 15 11:21:44 Kyber nginx: 2022/08/15 11:21:44 [crit] 9999#9999: ngx_slab_alloc() failed: no memory Aug 15 11:21:44 Kyber nginx: 2022/08/15 11:21:44 [error] 9999#9999: shpool alloc failed Aug 15 11:21:44 Kyber nginx: 2022/08/15 11:21:44 [error] 9999#9999: nchan: Out of shared memory while allocating message of size 234. Increase nchan_max_reserved_memory. Aug 15 11:21:44 Kyber nginx: 2022/08/15 11:21:44 [error] 9999#9999: *783812 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/arraymonitor?buffer_length=1 HTTP/1.1", host: "localhost" Aug 15 11:21:44 Kyber nginx: 2022/08/15 11:21:44 [error] 9999#9999: MEMSTORE:00: can't create shared message for channel /arraymonitor Aug 15 11:21:44 Kyber nginx: 2022/08/15 11:21:44 [crit] 9999#9999: ngx_slab_alloc() failed: no memory Aug 15 11:21:44 Kyber nginx: 2022/08/15 11:21:44 [error] 9999#9999: shpool alloc failed Aug 15 11:21:44 Kyber nginx: 2022/08/15 11:21:44 [error] 9999#9999: nchan: Out of shared memory while allocating message of size 824. Increase nchan_max_reserved_memory. Aug 15 11:21:44 Kyber nginx: 2022/08/15 11:21:44 [error] 9999#9999: *783813 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/update3?buffer_length=1 HTTP/1.1", host: "localhost" Aug 15 11:21:44 Kyber nginx: 2022/08/15 11:21:44 [error] 9999#9999: MEMSTORE:00: can't create shared message for channel /update3 Aug 15 11:21:44 Kyber nginx: 2022/08/15 11:21:44 [crit] 9999#9999: ngx_slab_alloc() failed: no memory Aug 15 11:21:44 Kyber nginx: 2022/08/15 11:21:44 [error] 9999#9999: shpool alloc failed Aug 15 11:21:44 Kyber nginx: 2022/08/15 11:21:44 [error] 9999#9999: nchan: Out of shared memory while allocating message of size 233. Increase nchan_max_reserved_memory. Aug 15 11:21:44 Kyber nginx: 2022/08/15 11:21:44 [error] 9999#9999: *783815 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/wireguard?buffer_length=1 HTTP/1.1", host: "localhost" Aug 15 11:21:44 Kyber nginx: 2022/08/15 11:21:44 [error] 9999#9999: MEMSTORE:00: can't create shared message for channel /wireguard Aug 15 11:21:44 Kyber nginx: 2022/08/15 11:21:44 [crit] 9999#9999: ngx_slab_alloc() failed: no memory Aug 15 11:21:44 Kyber nginx: 2022/08/15 11:21:44 [error] 9999#9999: shpool alloc failed Aug 15 11:21:44 Kyber nginx: 2022/08/15 11:21:44 [error] 9999#9999: nchan: Out of shared memory while allocating message of size 605. Increase nchan_max_reserved_memory. Aug 15 11:21:44 Kyber nginx: 2022/08/15 11:21:44 [error] 9999#9999: *783816 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/temperature?buffer_length=1 HTTP/1.1", host: "localhost" Aug 15 11:21:44 Kyber nginx: 2022/08/15 11:21:44 [error] 9999#9999: MEMSTORE:00: can't create shared message for channel /temperature Aug 15 11:21:44 Kyber nginx: 2022/08/15 11:21:44 [crit] 9999#9999: ngx_slab_alloc() failed: no memory Aug 15 11:21:44 Kyber nginx: 2022/08/15 11:21:44 [error] 9999#9999: shpool alloc failed Aug 15 11:21:44 Kyber nginx: 2022/08/15 11:21:44 [error] 9999#9999: nchan: Out of shared memory while allocating message of size 800. Increase nchan_max_reserved_memory. Aug 15 11:21:44 Kyber nginx: 2022/08/15 11:21:44 [error] 9999#9999: *783817 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/cpuload?buffer_length=1 HTTP/1.1", host: "localhost" Aug 15 11:21:44 Kyber nginx: 2022/08/15 11:21:44 [error] 9999#9999: MEMSTORE:00: can't create shared message for channel /cpuload Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [crit] 9999#9999: ngx_slab_alloc() failed: no memory Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: shpool alloc failed Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: nchan: Out of shared memory while allocating message of size 3620. Increase nchan_max_reserved_memory. Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: *783818 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/var?buffer_length=1 HTTP/1.1", host: "localhost" Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: MEMSTORE:00: can't create shared message for channel /var Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [crit] 9999#9999: ngx_slab_alloc() failed: no memory Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: shpool alloc failed Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: nchan: Out of shared memory while allocating message of size 503. Increase nchan_max_reserved_memory. Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: *783819 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/disks?buffer_length=1 HTTP/1.1", host: "localhost" Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: MEMSTORE:00: can't create shared message for channel /disks Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [crit] 9999#9999: ngx_slab_alloc() failed: no memory Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: shpool alloc failed Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: nchan: Out of shared memory while allocating message of size 314. Increase nchan_max_reserved_memory. Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: *783820 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/parity?buffer_length=1 HTTP/1.1", host: "localhost" Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: MEMSTORE:00: can't create shared message for channel /parity Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [crit] 9999#9999: ngx_slab_alloc() failed: no memory Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: shpool alloc failed Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: nchan: Out of shared memory while allocating message of size 503. Increase nchan_max_reserved_memory. Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: *783821 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/devices?buffer_length=1 HTTP/1.1", host: "localhost" Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: MEMSTORE:00: can't create shared message for channel /devices Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [crit] 9999#9999: ngx_slab_alloc() failed: no memory Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: shpool alloc failed Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: nchan: Out of shared memory while allocating message of size 234. Increase nchan_max_reserved_memory. Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: *783822 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/arraymonitor?buffer_length=1 HTTP/1.1", host: "localhost" Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: MEMSTORE:00: can't create shared message for channel /arraymonitor Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [crit] 9999#9999: ngx_slab_alloc() failed: no memory Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: shpool alloc failed Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: nchan: Out of shared memory while allocating message of size 810. Increase nchan_max_reserved_memory. Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: *783823 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/update3?buffer_length=1 HTTP/1.1", host: "localhost" Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: MEMSTORE:00: can't create shared message for channel /update3 Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [crit] 9999#9999: ngx_slab_alloc() failed: no memory Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: shpool alloc failed Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: nchan: Out of shared memory while allocating message of size 233. Increase nchan_max_reserved_memory. Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: *783824 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/wireguard?buffer_length=1 HTTP/1.1", host: "localhost" Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: MEMSTORE:00: can't create shared message for channel /wireguard Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [crit] 9999#9999: ngx_slab_alloc() failed: no memory Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: shpool alloc failed Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: nchan: Out of shared memory while allocating message of size 802. Increase nchan_max_reserved_memory. Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: *783825 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/cpuload?buffer_length=1 HTTP/1.1", host: "localhost" Aug 15 11:21:45 Kyber nginx: 2022/08/15 11:21:45 [error] 9999#9999: MEMSTORE:00: can't create shared message for channel /cpuload Aug 15 11:21:46 Kyber nginx: 2022/08/15 11:21:46 [crit] 9999#9999: ngx_slab_alloc() failed: no memory Aug 15 11:21:46 Kyber nginx: 2022/08/15 11:21:46 [error] 9999#9999: shpool alloc failed Aug 15 11:21:46 Kyber nginx: 2022/08/15 11:21:46 [error] 9999#9999: nchan: Out of shared memory while allocating message of size 235. Increase nchan_max_reserved_memory. Aug 15 11:21:46 Kyber nginx: 2022/08/15 11:21:46 [error] 9999#9999: *783826 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/notify?buffer_length=1 HTTP/1.1", host: "localhost" Aug 15 11:21:46 Kyber nginx: 2022/08/15 11:21:46 [error] 9999#9999: MEMSTORE:00: can't create shared message for channel /notify Aug 15 11:21:46 Kyber nginx: 2022/08/15 11:21:46 [crit] 9999#9999: ngx_slab_alloc() failed: no memory Aug 15 11:21:46 Kyber nginx: 2022/08/15 11:21:46 [error] 9999#9999: shpool alloc failed Aug 15 11:21:46 Kyber nginx: 2022/08/15 11:21:46 [error] 9999#9999: nchan: Out of shared memory while allocating message of size 3620. Increase nchan_max_reserved_memory. Aug 15 11:21:46 Kyber nginx: 2022/08/15 11:21:46 [error] 9999#9999: *783827 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/var?buffer_length=1 HTTP/1.1", host: "localhost" Aug 15 11:21:46 Kyber nginx: 2022/08/15 11:21:46 [error] 9999#9999: MEMSTORE:00: can't create shared message for channel /var Aug 15 11:21:46 Kyber nginx: 2022/08/15 11:21:46 [crit] 9999#9999: ngx_slab_alloc() failed: no memory Aug 15 11:21:46 Kyber nginx: 2022/08/15 11:21:46 [error] 9999#9999: shpool alloc failed Aug 15 11:21:46 Kyber nginx: 2022/08/15 11:21:46 [error] 9999#9999: nchan: Out of shared memory while allocating message of size 503. Increase nchan_max_reserved_memory. Aug 15 11:21:46 Kyber nginx: 2022/08/15 11:21:46 [error] 9999#9999: *783828 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/disks?buffer_length=1 HTTP/1.1", host: "localhost" Aug 15 11:21:46 Kyber nginx: 2022/08/15 11:21:46 [error] 9999#9999: MEMSTORE:00: can't create shared message for channel /disks Why would I be getting "no memory" errors? Unless it's not really memory but storage, and the storage for my logs is full? In either case, here's my diagnostics: kyber-diagnostics-20220815-1450.zip

Hey guys! I've been playing with Unraid over a year now. I really like it, and don't ever want to use something else. I'm having trouble though, and I can't figure out what's wrong. I've made, or replied to, a post some time ago about my monthly parity checks. At first, my parity checks were coming back perfect with 0 errors. Then I started noticing 200 or 300 errors on a check. Not that big a deal, I was almost positive I knew what had happened. Not knowing what I was doing, I used the Krusader docker to forcibly move data around on my drives; moving data off of one, putting it on another, etc, without allowing the parity process to take place. Lesson learned. A few months go by and my parity checks come back clean again every time. Then, out of nowhere, I started hitting 127k worth of errors a few months ago. I've not changed any of my hardware. Somebody somewhere (it was either in forums or in Discord, or reddit, etc), suggested this type of thing could be a symptom of bad RAM. So I ran memtest for like 4 days (something like 12 passes) and it came back 100% clean with no problems. Nothing seemed to be missing as far as my data, so I allowed the check to go while fixing the errors. Then another 2 months go by with no issues. Now, August 1st, I run the monthly check, and it comes back with about 7k errors again. Nothing has changed. Knowing that I've not done anything new, I had it correct the errors. But this time, after it was done, I ran a 2nd uncorrecting check and verified it was 100%. So I'm good. Fast forward to a couple days ago... I bought some more RAM for the server. It has 4 slots, capable of 128g max. When I first built the server, I bought 2x32g. I went back and bought 2 more of the same model. Shut the server down, then added the new sticks, and ran a memtest on the entire set. Originally set (by default) for 4 passes. I let it go through 3.5, about 2 days, and it came back clean. So I'm 75% sure the memory is not an issue. Booted up Unraid, it said parity was good. But just out of curiosity I started another parity check. Since it's only been about 2 weeks since my last 100% clean check, I didn't expect any issues. But, after about 4 hours, it had already detected 7k (7374 exactly) errors again. I'm so confused. I don't know why this keeps happening. So, I'm running another correction pass now. Prior to doing this, I did a lot of "spring cleaning". I took the server apart. Pulled out all the cards, memory, cpu. Disconnected all the drives. Then blew the thing out with compressed air (not that it needed it). I then put some fresh thermal grease on the CPU, and reconnected everything. Made sure everything was seated right, and booted up. Everything checked out. I did a quick test last night, doing an uncorrecting check, and it errored out again after a couple of hours. So I'm doing that correction pass. I'm not sure what could be causing my problems. My brother, whom I gave my older server to, and bought a license for, etc, has had no issues at all, doing the same thing I am (Plex server, with nzbget docker, etc). The one advantage he seems to have, is the RAM is ECC, whereas mine is not. It makes me pause and think; is ECC RAM necessary for proper Parity? I might have to go back and rebuild my system from scratch again if that's the case, because my motherboard doesn't support it. Something else I've been thinking.. If I have dockers running when a parity check is running, could they be interfering with the process? Like, I mentioned nzbget..if it's downloading while a check is occurring, could it be writing files that aren't getting added to parity? If this is a possibility, is there a way to turn off dockers and vm's while a check is running? I'm really just at a loss of ideas here. With no hardware changes (other than the new ram 2 days ago), why would I suddenly go from 0 errors for months, to over 120k then back to 0 for months, then back up to around 7k? Also... I have a UPS, and it does do it's job. But I've not had any improper shutdowns due to power failures (I've got it timed so I get plenty of time to safely shut down). I'm just looking for any possible reasons. I know how to post a debug log, or whatever it is. I'm hesitant to do it right now because the parity check is taking place. If it would help, let me know and I'll include it. Thanks in advance to whomever feels they want to try and help me!

Ah-ha! I had a feeling it was something like that. Good to know. That's not a bad idea. If it's not able to work don't offer it. But if the boot menu is capable of detecting UEFI vs Legacy, a simple "Not available for UEFI, please download from memtest86.com" flag that displays only in UEFI would be nice. It would at least remind you that it's not going to work and you won't waste your time trying to figure out why the PC keeps rebooting.