trurl

Yes, syslog-previous (included in diagnostics) are from syslog server writing to flash. If you want it to write to your Media share instead put localhost in Remote syslog server field. You might try rebuild in Maintenance mode just to make sure nothing is accessing the server while rebuilding.

Never heard of self-test starting automatically. Post a screenshot of the Self-Test section

Those logs and SMART report are already included in Diagnostics. Setup Syslog Server Doesn't look like rebuild completed. Are you trying to write a lot to the server while it is rebuilding?

OK, appdata, domains, system all on cache now. Don't know if you are familiar with these: Docker troubleshooting | Unraid DocsThis page offers troubleshooting guidance specifically for Docker containers on Unraid, managed by the Unraid team. For advanced troubleshooting, in-depth technical details, or topics beyond the Unrai

If you are ever in doubt about what to do, ask on the forum with your diagnostics before doing anything. Disturbing connections are a very common reason for problems when replacing disks. Before rebuilding any disk, make sure all disks are shown as mountable. If you rebuild an unmountable disk, the result will be an unmountable disk. If any disk is unmountable, check filesystem to repair it before proceeding with rebuild. During rebuild, you should see writing to the rebuilding disk, reading from all other disks, and zero in the ERRORS column for all disks. If there are errors, the rebuild may not be accurate, which could result in unmountable. Hopefully, the reason for the errors will just be connection problems, and you can shutdown, fix them, and start the rebuild again. Make sure all array disks are healthy. Each disk in the parity array is an independent filesystem that can be read all by itself in any Linux. But, it must reliably read every bit of all disks to reliably rebuild every bit of a disabled/missing disk. Unraid monitors certain SMART attributes and will warn you for those. For each of your WD disks click on it to get to its page and add attributes 1, 200 for monitoring. Do any disks show SMART (👎) warning on the DASHBOARD page? Setup Notifications to alert you immediately by email or other agent as soon as a problem is detected.

Didn't really expect a change. Just wanted to have the latest info to reference. To get the array back in sync, you can rebuild disk9, which would result in an empty disk. Then restore disk9 from backup. Or you can use that disk you repaired outside the array and New Config it back into the array as disk9, and rebuild parity instead. If you use the repaired disk, it will have some lost+found as you have seen, that would probably have to be restored from backup. Either way you will have to restore disk6 from backup.

I don't mean reboot, just Stop and Start.

Attach Diagnostics ZIP to your NEXT post in this thread.

And it is appropriate that Unraid allow those .cfg files to continue to exist, since the reason a share might not currently exist is because the disk the share is on might be currently unmountable. When the disk is made mountable again, the shares will exist, and its .cfg will apply. So, don't CLEAN UP if you have unmountable disks.

When shareDisks.txt says a share doesn't exist, I don't think it will appear on the User Shares page, so it can't be selected or deleted. These are .cfg files in config/shares for shares that no longer exist. If a folder exists at the top level of array or pools, it is automatically a share named for the folder. Even if the folder is empty. If a folder doesn't exist at the top level of array or pools, it isn't a share, but may still have .cfg file in config/shares. The way to clean those up is with the CLEAN UP button on the User Shares page.

For several reasons

Since only disk9 is missing, no other drives are disabled or invalid, and you have single parity, you should be able to start the array in normal mode. Do that and post new diagnostics.

Just to make sure we have the current state of things Attach Diagnostics ZIP to your NEXT post in this thread.

domain and system still on the array. Try restarting the array to refresh the shares, then

Newer versions of Unraid have newer versions of xfsprogs. You might try repair again after upgrading Unraid.

Sometimes repair can't figure out names of files or folders, or which folders a file belongs in. Those are put in lost+found. If you are happy with your backups, restoring both disks from backup might be the simplest solution.

Please post plain text files as plain text, not some format that requires special software to read.

Is there a lost+found folder at the top level of the disk now?

Did you do this? Because

Parity2 calculation is actually more complicated than that, but it is still just an extra bit that allows a missing bit to be calculated from all the other bits.

Parity by itself can rebuild nothing. Parity plus all other disks are read to get the calculated data to write to the rebuilding disk. Since there was dual parity, 2 disks could be recovered, but with 3 missing, there is no way to calculate the data for any disk. Parity is very simple, and it is basically the same concept wherever it is used and however it is implemented. Parity is just an extra bit that allows a missing bit to be calculated from all the other bits. If you are interested, go to this link: https://docs.unraid.net/unraid-os/getting-started/what-is-unraid/ then expand the Software-defined NAS section, then expand the How Parity Works section.

I never do. In maintenance mode you can't tell if your filesystems are mountable. But I mostly consider the server down anyway, file access will slow down rebuild, and rebuild will slow down file access.

Disk7 has disconnected and is now Unassigned Device sdm. SMART for that disk looks OK. Both emulated disks are mounted, disk7 is very full. Shutdown, check connections, all disks, both ends, SATA and power, including splitters. Since you have dual parity you can rebuild both at the same time.

I didn't notice anything currently in the Diagnostics. The drive firmware records CRC error when received data is inconsistent (checksum). It won't necessarily cause an I/O error since the data is resent. And I/O errors won't necessarily cause CRC error since the drive may not receive any data to checksum. That number will never reset. If it continues to increase, especially if it increases rapidly, then you need to figure out why. Could be just a loose connection, or bad cable.