itimpi

That looks like the drive has a serious level of corruption, and I would expect that many files would not be properly recovered. Do you have backups of anything important on that drive?

You can create diagnostics from the command line using the ‘diagnostics’ command and the results will be put into the ‘logs’ folder on the flash drive.

Yes - and if it asks for it use -L. The file system should then be mountable when you restart the array in normal mode. I would expect all files to then show up.

File system corruption is different to a drive failure. Until the corruption is fixed no files on the drive are accessible.

Have you tried the steps described here in the online documentation accessible via the ‘Manual’ link at the bottom of the unRaid GUI.

Because they have a habit of dropping disks offline for no obvious reason.

CRC error counts indicate a connection problem - typically the cabling rather than the drive although I must admit I do not think I have ever seen a count that high so I could be wrong. They are occurring on all 3 drives so that suggests to me that there has to be something that is common to all 3 drives that is causing the problem.

You should definitely cancel the parity sync as something is wrong. Which device is /dev/sdd? You are likely to get better informed feedback if you attach your systems diagnostics zip file (obtained via Tools->Diagnostics) to your NEXT post in this thread.

@S80_UK Thanks - that should be enough. The fact that the parity.check.tuning.scheduled file is even present confirms that the plugin got confused There should have been a parity.check.tuning.unscheduled file present instead for a manually initiated check. I may even change the .unscheduled file to be either .manual or .automatic so I can tell the difference between a manually initiated check and an automatic one started by the system after an unclean shutdown. I an adding some consistency checks that will hopefully stop this happening in the first place but if it still does at least make it clearer where things are going wrong. I am also going to add some date/time information to the files created to indicate the check type so that it points to the exact point in the syslog where things went wrong which should also help.

If you are intending to use the Monitor within a VM passing through the graphics card to the VM then it is the VM that is responsible for providing the drivers. Nvidia drivers ARE available in the Unraid 6.9.0-rc2 release (although you have to use a plugin to activate them) if you do not intend to pass the GPU to a VM. Whether they support the specific card you mention I am not sure.

You do not seem to have set the Minimum Frees Space value for the share to stop unRaid selecting a drive when the free space falls below that value. The drive is selected at a point within unRaid where the size of the file is not known and if it does not fit you will get an out-of-space error. Ideally you want that value to be set to a value larger than the largest file you expect to transfer to the share.

It should be just be the drives assigned to the array or a (cache) pool. It does, however, display the serial numbers of any drives it is about to format so you can check they are the ones you expect (to avoid any accidents).

When you give a container it’s own IP address then I think the host port setting is ignored and you can only use the port the container has configured. I could be wrong about that but that is my understanding.

The Shares tab never shows UD mounted drives. If you have enabled sharing the drive under the UD settings for the drive then it should become visible on the network.

You will need to use the 6.9.0-rc2 release to have driver support for your NIIC - the required driver is not included in the 6.8.3 release.

Automated pause/resume is the plugin. Standard unRaid only supports manual pause/resume.

Probably not much point in having it installed if you do not have a parity disk (although it can still be active if you ever run read checks).

Have you tried spinning up the drive first in case the delay is due to needing the drive to be spun up?

I suspect that the problem is the plugin getting confused about whether it is a scheduled check or not but confirmation would be nice. If you do get anything unexpected can you grab the files from the plugins folder on the flash drive (except the .tgz one) as seeing which files are present and what is in them may help with pinning down the cause.

@S80_UK Thanks for that detailed feedback. It does sound as if the temperature handling may now be working as intended although I did not knowingly find and fix a bug in this area. I will look into the unexpected pause. The plugin has some heuristics to try an decide if a check is scheduled or not and it is always possible the sequence of events you describe caused something to not work quite as expected.

I think that at the moment any time you make a change the underlying service gets disabled and you need to re-enable it again. Means you cannot make a change remotely when connected via WireGuard unless you have an alternative way into the server. Whether it is intended to change this I have no idea.

You certainly should not have formatted the drive! As the warning message that comes up says a format will guarantee that the data on the drive is loss. The correct way to handle an unmountable drive would have been to run a file system check/repair

It is a known issue with the firmware on Crucial SSDs that hey have stated they have no intention of fixing.

Also make sure you note down the serial number of the old parity drive (displayed in the unRaid GUI) so you can check you are removing the correct drive.

It is unusual not to get a reply in the forum quite quickly unless your problem is very obscure so that nobody has any idea.