itimpi

The file it mentions is definitely corrupt. This is obvious when you try to view its contents as it should contain readable text and it does not. Whether this indicates a problem (or impending problem) with the flash drive is not clear or something else lead to the corruption. I would make sure you have a backup of it (in particular the ‘config’ folder) just in case . You should delete that file and let Unraid generate a fresh copy with default values for that share.

Do you have any idea about how the drives were assigned (and which wad parity1 and which was parity2)? Shares are simply the amalgamation of the top level folders on each drive. Unraid will automatically create share entries for each top level folder it finds and give it default settings.

If that is the case then there is something very wrong as the earliest message in the syslog is at 07:41 and the latest is 07:54

Not clear exactly what you have done. Since you have a failed drive then you effectively start at step 9.

No - it is free for personal use.

Those ‘critical medium error’ messages almost certainly mean that the SSD is faulty.

Those ports WILL be open on the Local LAN as otherwise Unraid cannot operate properly. Are you saying that they show as open when you scan from the internet? If so they are not being blocked by your router

That seems excessive You are likely to get better informed feedback if you post your system’s diagnostics zip file.

By default as long as you do not put Unraid into your routers DMZ it will automatically block access from the internet. the problem comes when users WANT to have Unraid accessible from the internet and open up ports on their router without securing the connection with a VPN (e.g. WireGuard) or an equivalent.

I do not think that Trim applies to HHD devices - it is specific to SSDs

If you are booting in UEFI mode then you need to download a UEFI compatible version from memtest86.com

The diagnostics show continual failures to read from the flash drive. This means it either dropped offline for some reason or is indeed starting to fail. sometime rewriting its contents can fix such an issue if you are lucky. Do you have any up-to-date backups of the flash drive (the contents of the config folder being the important part).

Not quite sure what you are trying to say here? Are you saying the drives DO cool below the resume threshold but you do not get a resume? I am not sure that the drive spin down timeout is relevant, but 15 minutes does seem rather aggressive. Perhaps turning on the Debug (or even better Testing) mode of logging in the plugin’s settings and providing your system’s diagnostics after you think you have a problem would help? Also make sure you are on the current 2022-03-31 release of the plugin as some earlier ones were not handling temperatures correctly. EDIT: Just found that the 2022-03-31 release ended up with the same files as the 20:22-03-31 release which had unintended default settings. Pushed a 2022-04-02 release with correct updated default settings

Do you have the Parity Check Tuning plugin installed? That has an option to continue a parity check from where it was after a shutdown/reboot sequence (which I think is what you are effectively asking for?).

It is described in the documentation that was linked to - if you think that is not clear then mentioning what you found confusing will help with improving the documentation. In simplistic terms it refers to the number of folder levels that are allowed to exist on multiple drives. All further levels are constrained to the drive where the folder at that level is first created. Thus the higher the level the less restrictive.

The 6.10.0 rc versions have been available for many months now via the ‘next’ branch. No idea how long until it reaches ‘stable’ status but I suspect that is getting close.

You may find this section of the online documentations accessible via the ‘Manual’ link at the bottom of the GUI is relevant.

Not much point in continuing the rebuild with errors affecting multiple drives it is likely to be something they share such as the disk controller, or power supply.

Boards can work loose in slots so it is always worth trying a reseat.

I also notice a lot of items appear to be loaded via Nerdpack and it is possible one of them is not compatible with this release. It might be worth running in Safe Mode for a while as this would suppress any plugins runningand if that works it will give you a starting point for further troubleshooting.

A normal reboot will be considered unclean if the array did not get stopped before the shutdown timers activated. it might be worth reading this section of the online documentations accessible via the ‘Manual’ link at the bottom of the GUI.

I do not know myself - hopefully someone else knows the answer and will chime in

You should be good to go. Simplay stop the array; assign it as a parity drive; and restart the array to start building parity on the drive. Strictly speaking the Preclear was unnecessary as building parity writes to every sector on the drive anyway. However it does act as a confidence check on the drive’s health before attempting to use it as a parity drive.

Your syslog seems to be full of messages of the form: Mar 31 21:50:03 Hades kernel: pcieport 0000:00:1d.0: AER: Corrected error received: 0000:0b:00.0 Mar 31 21:50:03 Hades kernel: nvme 0000:0b:00.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) Mar 31 21:50:03 Hades kernel: nvme 0000:0b:00.0: device [c0a9:540a] error status/mask=00000001/00006000 Mar 31 21:50:03 Hades kernel: nvme 0000:0b:00.0: [ 0] RxErr Not sure of the cause and if they explain your issue, but it is possible they do: BTW: your Parity Check Tuning plugin is not the latest version. You want the 2022-03-31 version.

Yes, but what access rights on that mapping.