itimpi

I assume you meant a User Share in this case looking at the command output posted

That will be because you are encountering the behaviour described here in the online documentations accessible via the ‘Manual’ link at the bottom of the GUI. if you are on 6.10.x or later Unraid release then I would recommend using the Dynamix File Manager plugin to copy/move files/folders as it would protect you from this behaviour.

This is wrong You need to add a folder name to that path (e.g. /mnt/plex_cache/plex) which will end up with a share named after the folder name). You can pick any folder name you want that makes sense to you. After making that change you can manually move the existing contents into that folder and plex will not notice any difference.

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.