JorgeB

That doesn't look serious, when was the last crash? Nothing obvious in the log.

It's safe to move from one share to another.

Unraid driver is crashing, this happens sometimes to a few users, usually with a specific kernel/hardware combination, try upgrading to v6.10.0-rc7.

Just restart the array, parity is valid.

Disk was already disabled at boot so we can't see what happened, but SMART looks OK, suggest replacing/swapping cables to rule those out if it happens again to the same disk and then re-sync parity. Make sure you enable system notifications so you're notified at once when there's a problem, or it might be too late.

Run it again without -n and without -L, if it didn't finish before and asks for -L again use it.

Chipset still supports 6, so the other ones will always be link down.

Use -L

No need to rebuild since the disk is enable, but you do need to run xfs_repair without -n to fix the current corruptions.

No, there are no drives connected to those ports, those are the onboard SATA ports, only the first two have devices connected: May 9 09:43:30 afterdark kernel: ata1.00: ATA-9: SanDisk SDSSDHII240G, 150366401046, X31200RL, max UDMA/133 May 9 09:43:30 afterdark kernel: ata2.00: ATA-9: Samsung SSD 850 EVO 500GB, S21HNSAG408848P, EMT01B6Q, max UDMA/133 May 9 09:43:30 afterdark kernel: ata3: SATA link down (SStatus 0 SControl 300) May 9 09:43:30 afterdark kernel: ata4: SATA link down (SStatus 0 SControl 300) May 9 09:43:30 afterdark kernel: ata5: SATA link down (SStatus 0 SControl 300) May 9 09:43:30 afterdark kernel: ata6: SATA link down (SStatus 0 SControl 300)

Like itimpi mentioned, you can start a transfer larger than cache as long as everything is configured correctly, also this was incorrect, shared created with cache="yes" if first created in the array, so available space will be correct.

Depends if you add is as parity or data drive.

That's fine, and hopefully worth the trouble to prevent similar issues when it goes stable and more users update.

Controller is not being detected, make sure it's well seated or try a different PCIe slot, you can also try it in a different PC if available to make sure it's working.

Posted logs seem incomplete, is that all it caught or it's just partial, would like to see the beginning of the problem.

Strange but there are no devices on those ports anyway, only on ATA1 and 2, so it's not a problem other than the log spam, you could use those 4 ports to connect some devices, instead of for example using so many USB, more reliable and the spam should stop.

Looks like a power/connection problem, check/replace cables, both power and SATA.

Disk is dropping offline so there's no SMART, but both times it was connected to a Marvell controller, so try it in a different controller, Marvell is not recommended for Unraid.

This will happen if the share only exists on cache, create the share with use cache="yes" and run the mover once and it will also exist in the array.

I'm really bad with scripts, it works for me because I know its limitations, you're better off using for example the snapshots plugin.

Changed Status to Open Changed Priority to Minor

There are several ways, I have a script that takes a snapshot everyday then sends it to another pool.

Yes, I wasn't very clear, I meant related for me, since not saving the cache config was my main problem, don't really care about the name change once it's saved, but if it can be fixed good for anyone else using the same NVMe device, I'll reopen the other one.

That's not unexpected, one of the devices had a bogus large transid, any data that was saved with a transid larger than the actual one would be lost. Can't really help with that, I never used Plex. As for the other docker if the appdata is current they should work, if not they need to be reconfigured, docker image can easily be recreated if needed.

Start here: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=819173