itimpi

It stores all the configuration information for your VMs

Did you redo any hardware pass throughs to the VM after plugging in the LSI card? It is highly likely that the hardware IDs changed after the LSI card was plugged in.

I am afraid what you are describing sounds like a motherboard/bios issue that is outside Unraid control.

Yes - the check (and repair) will be run against the emulated drive. You want to repair the emulated drive as all a rebuild does is make a physical drive match an emulated drive (including any file system corruption that might be present).

you must not have any of those paths mapped directly to ‘mnt/plex_cache as that is the root of the pool so will cause the symptoms you have been experiencing.

It is not the time to calculate the parity that is the issue, but the disk rotations involved. This is described here in the online documentations accessible via the ‘Manual’ link at the bottom of the GUI.

Do NOT format the drive - that will write an empty file system to the drive and update parity to reflect this resulting in you losing its contents. The correct procedure to follow is documented here in the online documentations accessible via the ‘Manual’ link at the bottom of the GUI.

Missed the fact that Plex had access to the root of the plex_cache drive. You need to add another folder to that path (e.g. /mnt/plex_cache/plex) to get plex to put its working files into a share called ‘plex’ and stop creating top level folders.

Looking at that screenshot, if a container created those folders then only Krusader and Handbrake have a level of access to the host file system that could do it.

All top level folders on any drive are considered to be User Shares. You need to work out what created those folders and correct that. You then need to either move those folders to their correct location or simply delete them.

The SATA cable order is irrelevant as Unraid recognises disks by their serial numbers. If the news card reports serial numbers the same as the old one then everything should ‘just work’. If they are reported differently then s bit more is required (check back here if necessary).

You are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread.

That is the correct way to proceed. the backup should have kept the pool assignments unless they predated them being set up. When you get them set up this time I recommend you click on the flash drive on the Main tab and select the option to create a backup. I try to always do this on my own system whenever I make a configuration change.

It is quite possible that there is nothing wrong with the 'failed' drive. External factors such as cabling, power supply etc are much more common causes of problems that the physical drives failing. After a successful rebuild you can test the 'failed' drive to see if it appears to be OK in which case you can keep it as a spare.

That is very promising - it look like the emulated drive is showing no corruption so I would expect a successful rebuild will result in all your data being intact. Since you have a spare disk then rebuilding to another disk is the right way to proceed.

Just a thought, it might be worth deleting (or renaming) the config/share.cfg file from the flash drive in case it contains any values from an old Unraid release that predates multiple pools that are causing problems. You can then use Settings->Global Share settings to get a new one generated. No idea if it will help but cannot hurt to try it.

Was the disk disabled (had a red ‘x’ showing on the main tab)? If it was then the disk would have been emulated and the file system check run against the emulated disk, whereas if not it was against the real disk. The reason I ask is that the rebuild process simply makes a physical drive correspond to the emulated one (including any file system corruption). If the drive was NOT disabled then it could be worth running the check again this time against the emulated drive to see what that reports. Do you have a spare disk available to rebuild to? This is desirable as it means for the time being you can keep the physical problem drive with its contents intact so you have more recovery options if a rebuild is not completely successful.

It will be put into the logs folder on the flash drive. You can either access that via Unraid or by temporarily plugging the flash drive into a PC/Mac

Make sure the name is UNRAID (I.e. all upper-case).

You are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread.

Possibly a silly question, but have you made sure that the SSD is not mounted in Unassigned Devices when you hit the Add Pool button?

Have you considered whether it is a power supply issue? Installing a GPU could be adding a significant extra load on the PSU.

I do not know of anyway to make the plugin reliably spin down the drives - this is something Unraid still struggles to do reliably for all hardware combinations so it something I have been avoiding. At the moment if you want spindown then you need it set appropriately at the Unraid system level. The plugin does, however, now avoid unnecessarily spinning up drives if a check is in a paused state for temperature related reasons. Having said that I will consider checking if the latest Unraid releases have cracked the problem of spindown in a way the plugin can exploit. It might be worth attempting a spindown when the temperature related pause happens even if it does not work for everybody. If I get this working it will probably have to be exposed as a setting as I could see that not everyone would want their drives forcibly spun down by the plugin.

I hope you find it useful. The plugin has been providing this sort of functionality ever since Unraid 6.7 and the core Unraid system still has some way to go before it catches up with the full functionality offered by the plugin. if you encounter any issues using the plugin feel free to bring these up in the plugin’s support thread.

It is normally recommended that the scheduled checks do NOT automatically correct errors. The reason is that you if you have a drive misbehaving and you are not aware of it you do not want it corrupting parity. If the scheduled check reports anything other than zero errors then it is time to investigate why. Ideally you should always run correcting checks manually after you have fixed any hardware issues.