JorgeB

IMHO not much point now since there are no bad sectors currently.

Get the diags on the console by typing "diagnostics"

You can easily recreate the docker image keeping all settings, make sure to free up some space first.

Previous check: Aug 24 05:45:33 R720XD kernel: md: recovery thread: P corrected, sector=10563312232 Aug 24 05:45:33 R720XD kernel: md: recovery thread: P corrected, sector=10563312240 Aug 24 05:45:33 R720XD kernel: md: recovery thread: P corrected, sector=10563312504 Aug 24 05:45:33 R720XD kernel: md: recovery thread: P corrected, sector=10563312512 Notice the block jump from block ending in sector 240 to the one starting in 504. This last check found all blocks in between those incorrect: Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312248 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312256 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312264 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312272 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312280 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312288 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312296 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312304 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312312 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312320 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312328 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312336 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312344 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312352 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312360 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312368 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312376 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312384 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312392 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312400 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312408 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312416 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312424 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312432 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312440 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312448 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312456 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312464 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312472 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312480 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312488 Aug 25 10:47:52 R720XD kernel: md: recovery thread: P incorrect, sector=10563312496 This to me rules out any RAM issue, which would already not be really a suspect since you are using ECC RAM, next suspect for me would be the controller, any chance you can test with a different one? Ideally one in IT mode, not raid mode as current one.

It might male a considerable difference, especially since Samsung devices appear to be one of the most affected by the alignment issue, also to test use the disk share, not an user share, that also introduces some overhead.

SMART test passed and attributes look fine, though the previous errors are logged as actual disk errors, I would keep it for now but any more similar errors in the near future replace it. You also need to run a correcting parity check since because of those errors parity won't be 100% correct.

That is strange, and no idea why you're still getting spammed but unrelated to your issues, at least docker is back to working correct?

Is the speed better if you copy directly to the array?

Run another check (without rebooting) and then post diags.

It does, if the minimum free space setting is correctly set for that share.

Unfortunately for an x1 slot there are only good options for 2 port controllers, 4 port Marvell 9215 might work ok, anything x1 with more than 4 ports will use port multipliers, at least AFAIK.

Settings -> Network Settings -> Interface Rules Set the gigabit NIC as eth0 and the other one as eth1, reboot is required.

Don't overclock your RAM, it's a known issue with Ryzen, see here.

No, it's not, and again, this will only work if parity is valid, please follow the instructions below carefully and ask if there are any doubts. -Tools -> New Config -> Retain current configuration: All -> Apply -Check all assignments and assign any missing disk(s) if needed, including new disk3 -Important - After checking the assignments leave the browser on that page, the "Main" page. -Open an SSH session/use the console and type (don't copy/paste directly from the forum, as sometimes it can insert extra characters): mdcmd set invalidslot 3 29 -Back on the GUI and without refreshing the page, just start the array, do not check the "parity is already valid" box (GUI will still show that data on parity disk(s) will be overwritten, this is normal as it doesn't account for the invalid slot command, but they won't be as long as the procedure was correctly done), disk3 will start rebuilding, disk should mount immediately but if it's unmountable don't format, wait for the rebuild to finish and then run a filesystem check

Unraid can't mount linux raid disks, since the driver is modified.

This should be plug'n play, please post diags with the LSI.

Also try booting in safe mode, something is preventing the avahi daemon from starting, and it looks like because of that the other services like smb are not started.

In case you still need that you just need to copy the config folder.

There was something reading from disk2 when the diags were saved, any array activity will slow down the parity check.

That's because you're probably using a RAID controller, if parity is valid, and only if that's true, you can use the invalid slot command, to post the instructions I need some more details, what Unraid release are you running and do you have single or dual parity?

I'm sorry, misread your post, Unraid will find the array, it's plug'n play.

No worries, it appears to be working correctly now, sent some beer money your way as a thank you.

Thanks, I'll give it try and report back soon, miss the fan control!

This is usually a flash drive problem, try recreating it.

This would probably be a good option for the nerd pack plugin.