JorgeB

No, but the fact that it is not working suggests a device problem, SMART is independent of Unraid. Why? The shelf works with SATA, interposers are preventing you from monitoring SMART for all connected SATA devices.

Then and since nothing relevant was logged it's likely some hardware issue, one thing you can try is to boot the server in safe mode with all docker/VMs disable, let it run as a basic NAS for a few days, if it still crashes it's likely a hardware problem, if it doesn't start turning on the other services one by one.

Assuming you're going to pass-through the NICs to VMs turn both off.

Run a scrub, it should list the affect file(s) in the syslog.

That should not cause data corruption, it might cause filesystem corruption. Delete the corrupt file(s) and restore from backup if available.

But it's using the RAID driver (megaraid), LSI IT driver (mpt3sas) is usually more reliable.

Problem with the RAID controller: Aug 15 09:18:03 unraid kernel: megaraid_sas 0000:01:00.0: FW restarted successfully,initiating next stage... Aug 15 09:18:03 unraid kernel: megaraid_sas 0000:01:00.0: HBA recovery state machine,state 2 starting... Aug 15 09:18:34 unraid kernel: megaraid_sas 0000:01:00.0: Waiting for FW to come to ready state Aug 15 09:18:34 unraid kernel: megaraid_sas 0000:01:00.0: FW in FAULT state, Fault code:0xfff0000 subcode:0xff00 func:megasas_transition_to_ready Aug 15 09:21:53 unraid kernel: megaraid_sas 0000:01:00.0: FW state [-268435456] hasn't changed in 180 secs Depending on the model the LSi might be flashable to IT mode, if yes it would be better for use with Unraid.

The disks will be numbered according to the slots they are assigned, when you do a new config you can reorder the disks, if using parity1 only it will remain valid, if you have parity2 that one will need re-syncing.

Save at least the syslog before rebooting.

Btrfs is detecting data corruption, Ryzen with overclocked RAM like you have is known to in some cases corrupt data, so start there, then also a good idea to run memtest.

If there's no disk1 assigned it's expected.

Enable the syslog server and post that after a crash.

Disk is not even giving a valid SMART report, so looks like a disk problem. though you're suing SAS interposers, you can try without that.

You can acknowledge both, then keep monitoring, disk4 are CRC errors, this is usually a SATA cable problem so if you get a new warning in the future change that, disk6 has some reallocated sectors, not great but not fatal, again monitor for more in the future, if it keeps increasing you might consider replacing it.

Enable the syslog server and post that after a kernel panic.

Yes, the pool is making Unraid crash, cannot see why though, unassign both pool devices, start the array and then see if you can mount them using the recovery options here, if the first options doesn't work best bet is to use btrfs restore.

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

-boot using GUI mode and set the onboard NIC to eth0 (Settings -> Network Settings -> Interface rules), assign the static IP you want and the other settings and reboot, of course link will need to up for it to work.

It would be for testing only, you could then change it back, but if the drives are almost full it won't be a very good test, instead enable disk shares and transfer to cache using the disk share to see if there's any difference.

Nothing obvious, does it happen often in enough that you could try a few safe mode boots to see it it still happens there? P.S. Aug 14 15:41:52 Unraid kernel: BTRFS info (device nvme0n1p1): bdev /dev/nvme0n1p1 errs: wr 35831547, rd 34161914, flush 79147, corrupt 2202550, gen 40 Aug 14 15:41:52 Unraid kernel: BTRFS info (device nvme0n1p1): bdev /dev/nvme1n1p1 errs: wr 2724252, rd 91742, flush 112697, corrupt 2291893, gen 4 All these errors suggest both pool devices dropped offline at some point in the past, likely not together, see here for more info on what to do and how to better monitor the pool.

Try this: https://forums.unraid.net/bug-reports/stable-releases/6100-vm-connect-to-vnc-via-browser-fails-because-of-caching-issue-r1946/?do=findComment&comment=19510

Nope.

You should also post the complete diagnostics here in the forum, attach them to your next post, just to confirm everything else looks good.

Disk2 is disabled, if you add a disk to that slot and start the array Unraid will rebuild disk2, not parity, emulated disk2 is mounting correctly so you can rebuild it at any time, now or after attempting to recover the data from disk1, but don't do both at the same time, both require reading disk1 so performance will be worse.

Aug 14 16:22:13 SVServer kernel: BTRFS error (device md1): parent transid verify failed on 40517632 wanted 83423 found 83421 Aug 14 16:22:13 SVServer kernel: BTRFS error (device md1): parent transid verify failed on 40517632 wanted 83423 found 83421 This error is fatal with btrfs, both metadata copies are on the wrong transition id, this means that the disk lost some writes, i.e., it didn't respect write barriers, it told the OS all writes were done, the btrfs superblock was updated but it turns out not all writes were done, this is usually a controller/disk firmware problem. You can try the first two options here, 1st option is more likely to work if first you update to v6.10.3, still btrfs restore is usually the option with more chances of success for this particular error, if/when the data is recovered the disk will need to be formatted, like mentioned this fs error cannot be fixed, it's fatal.