JorgeB

This is only a problem when using user and disk shares at the same time.

Usually it works with any two connections, you can also check if it's linked with single or dual link: cat /sys/class/sas_host/host1/device/port-1\:0/sas_port/port-1\:0/num_phys Output of 4 indicates single link, 8 dual link, command might need to be adjusted to correct host#, post diags if the above doesn't work.

That suggests a hardware issue.

Always possible, difficult to say without any other info, enable the syslog server and post it once it crashes or try running the server in safe mode without any docker/VMs for a few hours, if it still crashes like that it's likely a hardware problem.

Lets start with the basics, what model is the m.2 device?

No, the SATA controller stops responding. There are plenty of similar posts, not much more info except most users confirming that upgrading to latest stopped the issues. Just upgrading should be enough, but if don't need IOMMU disabled it, then re-sync parity.

Yes, all disks dropped, and Unraid only disabled the two (with dual parity), but you need to reboot to regain access to the other ones.

Don't really understand what you ere trying to do, but please post diags. P.S. about to go log out for the rest of the day, might only reply tomorrow.

And it also crashed with beta24? You can always downgrade by manually copying the bz* files from the v6.8.3 zip overwriting the existing ones.

Next time please attache the complete zip. It is the Ryzen controller issue, most users report no more issues after upgrading to the latest beta, likely because it uses a much newer kernel, you can also disable IOMMU if not needed.

Auto parity check after an unclean shutdown is non correct, you now did a correcting check, so next one should find 0 errors.

If the update was done using the GUI then you can go to Tools -> Update OS -> Unraid OS (previous) -> Restore

Please post the complete diagnostics, looks like the typical Ryzen controller problem but I need to see the hardware used among other things.

This is not really a recommended HBA, doesn't mean it won't work correctly, just that we usually recommend LSI since they are used for many users and the driver is usually solid, but not sure if the HBA is the problem: Aug 13 10:44:36 FancherData kernel: hpsa 0000:01:00.0: handle_ioaccel_mode2_error: device is gone! Aug 13 10:44:36 FancherData kernel: sd 7:0:6:0: [sdg] tag#851 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00 first it was disk6 then all the other disks: Aug 13 10:44:36 FancherData kernel: hpsa 0000:01:00.0: handle_ioaccel_mode2_error: device is gone! Aug 13 10:44:36 FancherData kernel: sd 7:0:1:0: [sdb] tag#856 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00 Aug 13 10:44:36 FancherData kernel: sd 7:0:1:0: [sdb] tag#856 CDB: opcode=0x88 88 00 00 00 00 03 6f da b4 c8 00 00 00 08 00 00 Aug 13 10:44:36 FancherData kernel: print_req_error: I/O error, dev sdb, sector 14761505992 Aug 13 10:44:36 FancherData kernel: md: disk2 read error, sector=14761505928 Aug 13 10:44:36 FancherData kernel: hpsa 0000:01:00.0: handle_ioaccel_mode2_error: device is gone! Aug 13 10:44:36 FancherData kernel: sd 7:0:3:0: [sdd] tag#861 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00 Aug 13 10:44:36 FancherData kernel: sd 7:0:3:0: [sdd] tag#861 CDB: opcode=0x88 88 00 00 00 00 03 6f da b4 c8 00 00 00 08 00 00 Aug 13 10:44:36 FancherData kernel: print_req_error: I/O error, dev sdd, sector 14761505992 Aug 13 10:44:36 FancherData kernel: md: disk1 read error, sector=14761505928 Aug 13 10:44:36 FancherData kernel: hpsa 0000:01:00.0: handle_ioaccel_mode2_error: device is gone! Aug 13 10:44:36 FancherData kernel: sd 7:0:4:0: [sde] tag#867 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00 Aug 13 10:44:36 FancherData kernel: sd 7:0:4:0: [sde] tag#867 CDB: opcode=0x88 88 00 00 00 00 03 6f da b4 c8 00 00 00 08 00 00 Aug 13 10:44:36 FancherData kernel: print_req_error: I/O error, dev sde, sector 14761505992 Aug 13 10:44:36 FancherData kernel: md: disk3 read error, sector=14761505928 Aug 13 10:44:36 FancherData kernel: hpsa 0000:01:00.0: handle_ioaccel_mode2_error: device is gone! Aug 13 10:44:36 FancherData kernel: sd 7:0:5:0: [sdf] tag#868 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00 Aug 13 10:44:36 FancherData kernel: sd 7:0:5:0: [sdf] tag#868 CDB: opcode=0x88 88 00 00 00 00 03 6f da b4 c8 00 00 00 08 00 00 Aug 13 10:44:36 FancherData kernel: print_req_error: I/O error, dev sdf, sector 14761505992 Aug 13 10:44:36 FancherData kernel: md: disk0 read error, sector=14761505928 Aug 13 10:44:36 FancherData kernel: hpsa 0000:01:00.0: handle_ioaccel_mode2_error: device is gone! Aug 13 10:44:36 FancherData kernel: sd 7:0:7:0: [sdi] tag#869 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00 Aug 13 10:44:36 FancherData kernel: sd 7:0:7:0: [sdi] tag#869 CDB: opcode=0x88 88 00 00 00 00 03 6f da b4 c8 00 00 00 08 00 00 Aug 13 10:44:36 FancherData kernel: print_req_error: I/O error, dev sdi, sector 14761505992 Aug 13 10:44:36 FancherData kernel: md: disk29 read error, sector=14761505928 Aug 13 10:44:36 FancherData kernel: hpsa 0000:01:00.0: handle_ioaccel_mode2_error: device is gone! Aug 13 10:44:36 FancherData kernel: sd 7:0:8:0: [sdj] tag#870 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00 Aug 13 10:44:36 FancherData kernel: sd 7:0:8:0: [sdj] tag#870 CDB: opcode=0x88 88 00 00 00 00 03 6f da b4 c8 00 00 00 08 00 00 Aug 13 10:44:36 FancherData kernel: print_req_error: I/O error, dev sdj, sector 14761505992 Aug 13 10:44:36 FancherData kernel: md: disk5 read error, sector=14761505928 Aug 13 10:44:36 FancherData kernel: md: recovery thread: multiple disk errors, sector=14761505928 Aug 13 10:44:36 FancherData kernel: sd 7:0:7:0: [sdi] tag#857 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00 Note that when this happens Unraid disables as many devices as there are parity disks, which devoices get disabled is luck of the draw. Now all disks dropping at the same time could be a connection problem, power problem or the HBA, but basically you need to start testing one thing at a time.

If there were no unclean shutdowns there could be a hardware issue, like bad RAM, btrfs is very sensitive to memory errors.

Parity sync pause doesn't survive a reboot.

There were call traces during the sync, updating to v6.8 should fix that, then try again.

There are reports that it helps, in some cases by a lot. This.

That's normal with emulated disks, but they wouldn't be available with unmountable disks, emulated or not.

Yes, AFAIK not easy (or even possible) to enter the ssh password with a script

Try this, it might catch something.

Diags are just after rebooting so not much to see.

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

oh, and forget to delete the extra folder, at some point in the future Unraid will be updated and that would overwrite it.

Everything should be fine, you can look for a lost+found folder on that disk, any lost/partial files would be there, but since it was a superblock issue there probably won't be any.