JorgeB

So it's not partition corruption, it's completely missing, easiest way is to rebuild the disk(s), assuming parity is still valid, partition information is outside parity, and Unraid will recreate the partitions, you can easily test by unassigning one of the disks and start the array, if the emulated disk mounts correctly rebuild on top, then repeat for the other one.

The ones listed above as onboard SATA. By the looks of it you should be able to get most data but there could be some data corruption, but you first need to solve the device dropping issue.

Changed Priority to Other

Sorry, I must have confused your diags with another one, you have two SASLP controllers, there's no LSI, you can still connect the SSDs to the Intel ports though.

You can look, it's in the lsscsi.txt file in the diags, but it was on the same controller: The other SSD device was also there, so that one is now on the LSI. The SSD was on an SASLP, now is on the other one.

If it's a single backplane it's direct connection, you have devices connected to 3 different controllers: These are on an SASLP [1:0:0:0] disk ATA SanDisk SDSSDH31 70RL /dev/sdj /dev/sg9 state=running queue_depth=32 scsi_level=6 type=0 device_blocked=0 timeout=30 dir: /sys/bus/scsi/devices/1:0:0:0 [/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host1/port-1:0/end_device-1:0/target1:0:0/1:0:0:0] [1:0:1:0] disk ATA WDC WD100EMAZ-00 0A83 /dev/sdk /dev/sg10 state=running queue_depth=32 scsi_level=6 type=0 device_blocked=0 timeout=30 dir: /sys/bus/scsi/devices/1:0:1:0 [/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host1/port-1:1/end_device-1:1/target1:0:1/1:0:1:0] These on the onboard SATA ports [2:0:0:0] disk ATA ST10000VN0008-2P SC61 /dev/sdb /dev/sg1 state=running queue_depth=1 scsi_level=6 type=0 device_blocked=0 timeout=30 dir: /sys/bus/scsi/devices/2:0:0:0 [/sys/devices/pci0000:00/0000:00:11.4/ata1/host2/target2:0:0/2:0:0:0] [3:0:0:0] disk ATA WDC WD60EFRX-68M 0A82 /dev/sdc /dev/sg2 state=running queue_depth=1 scsi_level=6 type=0 device_blocked=0 timeout=30 dir: /sys/bus/scsi/devices/3:0:0:0 [/sys/devices/pci0000:00/0000:00:11.4/ata2/host3/target3:0:0/3:0:0:0] [4:0:0:0] disk ATA WDC WD60EFRX-68M 0A82 /dev/sdd /dev/sg3 state=running queue_depth=1 scsi_level=6 type=0 device_blocked=0 timeout=30 dir: /sys/bus/scsi/devices/4:0:0:0 [/sys/devices/pci0000:00/0000:00:11.4/ata3/host4/target4:0:0/4:0:0:0] [5:0:0:0] disk ATA ST8000VN0022-2EL SC61 /dev/sde /dev/sg4 state=running queue_depth=1 scsi_level=6 type=0 device_blocked=0 timeout=30 dir: /sys/bus/scsi/devices/5:0:0:0 [/sys/devices/pci0000:00/0000:00:11.4/ata4/host5/target5:0:0/5:0:0:0] [6:0:0:0] disk ATA WDC WD60EFRX-68M 0A82 /dev/sdf /dev/sg5 state=running queue_depth=1 scsi_level=6 type=0 device_blocked=0 timeout=30 dir: /sys/bus/scsi/devices/6:0:0:0 [/sys/devices/pci0000:00/0000:00:1f.2/ata5/host6/target6:0:0/6:0:0:0] [7:0:0:0] disk ATA WDC WD60EFRX-68M 0A82 /dev/sdg /dev/sg6 state=running queue_depth=1 scsi_level=6 type=0 device_blocked=0 timeout=30 dir: /sys/bus/scsi/devices/7:0:0:0 [/sys/devices/pci0000:00/0000:00:1f.2/ata6/host7/target7:0:0/7:0:0:0] [8:0:0:0] disk ATA WDC WD60EFRX-68M 0A82 /dev/sdh /dev/sg7 state=running queue_depth=1 scsi_level=6 type=0 device_blocked=0 timeout=30 dir: /sys/bus/scsi/devices/8:0:0:0 [/sys/devices/pci0000:00/0000:00:1f.2/ata7/host8/target8:0:0/8:0:0:0] [9:0:0:0] disk ATA ST10000VN0004-1Z SC60 /dev/sdi /dev/sg8 state=running queue_depth=1 scsi_level=6 type=0 device_blocked=0 timeout=30 dir: /sys/bus/scsi/devices/9:0:0:0 [/sys/devices/pci0000:00/0000:00:1f.2/ata8/host9/target9:0:0/9:0:0:0] And these on another SASLP: [12:0:0:0] disk ATA ST10000VN0008-2J SC60 /dev/sdl /dev/sg11 state=running queue_depth=1 scsi_level=6 type=0 device_blocked=0 timeout=30 dir: /sys/bus/scsi/devices/12:0:0:0 [/sys/devices/pci0000:00/0000:00:01.1/0000:02:00.0/host12/port-12:0/end_device-12:0/target12:0:0/12:0:0:0] [12:0:1:0] disk ATA WDC WD100EMAZ-00 0A83 /dev/sdm /dev/sg12 state=running queue_depth=32 scsi_level=6 type=0 device_blocked=0 timeout=30 dir: /sys/bus/scsi/devices/12:0:1:0 [/sys/devices/pci0000:00/0000:00:01.1/0000:02:00.0/host12/port-12:1/end_device-12:1/target12:0:1/12:0:1:0] [12:0:2:0] disk ATA SanDisk Ultra II 00RL /dev/sdn /dev/sg13 state=running queue_depth=32 scsi_level=6 type=0 device_blocked=0 timeout=30 dir: /sys/bus/scsi/devices/12:0:2:0 [/sys/devices/pci0000:00/0000:00:01.1/0000:02:00.0/host12/port-12:2/end_device-12:2/target12:0:2/12:0:2:0] [12:0:3:0] disk ATA ST4000DM000-1F21 CC54 /dev/sdo /dev/sg14 state=running queue_depth=32 scsi_level=6 type=0 device_blocked=0 timeout=30 dir: /sys/bus/scsi/devices/12:0:3:0 [/sys/devices/pci0000:00/0000:00:01.1/0000:02:00.0/host12/port-12:3/end_device-12:3/target12:0:3/12:0:3:0] [12:0:4:0] disk ATA ST10000VN0008-2P SC61 /dev/sdp /dev/sg15 state=running queue_depth=32 scsi_level=6 type=0 device_blocked=0 timeout=30 dir: /sys/bus/scsi/devices/12:0:4:0 [/sys/devices/pci0000:00/0000:00:01.1/0000:02:00.0/host12/port-12:4/end_device-12:4/target12:0:4/12:0:4:0] [12:0:5:0] disk ATA WDC WD60EFRX-68L 0A82 /dev/sdq /dev/sg16 state=running queue_depth=32 scsi_level=6 type=0 device_blocked=0 timeout=30 dir: /sys/bus/scsi/devices/12:0:5:0 [/sys/devices/pci0000:00/0000:00:01.1/0000:02:00.0/host12/port-12:5/end_device-12:5/target12:0:5/12:0:5:0] So I see no reason why you can't connect the SSDs to the Intel ports, it's just a case of swapping things around.

If you can't connect it to the onboard SATA at least connect it to the LSI controller, like the other SSD is, still no trim but at least it's a reliable controller.

It dropped offline again.

Also no issues for me with a ConnectX-3, probably on a old firmware though, since I never updated.

Domains share is set to exclude disk1, and you don't have any other array disks or pools assigned.

Could be related, if something is corrupting the data.

These suggest one of the devices dropped offline in the past: Nov 15 16:44:17 Eden kernel: BTRFS info (device sdk1): bdev /dev/sdj1 errs: wr 29362, rd 138395, flush 0, corrupt 4, gen 0 Nov 15 16:44:17 Eden kernel: BTRFS info (device sdk1): bdev /dev/sdk1 errs: wr 0, rd 0, flush 0, corrupt 4, gen 0 And it dropped offline again: Nov 16 00:49:27 Eden kernel: ata11.00: failed to IDENTIFY (I/O error, err_mask=0x1) Nov 16 00:49:27 Eden kernel: ata11.00: revalidation failed (errno=-5) Nov 16 00:49:27 Eden kernel: ata11.00: disabled Try replacing the cables on that device, and ideally don't use the SASLP controller which is not recommended, or at least connect the SSDs to onboard SATA, or trim also won't work, then run a correcting scrub and see if there aren't any uncorrectable errors.

Because the problem is corruption, not failure, in this case looks like LUKS corruption, filesystem corruption can have similar results, i.e., parity won't help, but you can still try what I posted above, it should work.

On second though, that won't work, since the basic flash drive will be blacklisted, I don't know why you just don't use the existing Pro flash drive, my oldest servers are almost 14 years ols and still using the original flash drives, but you'd still need to contact LT to see if what you want is possible. https://unraid.net/contact

Post the output of: fdisk -l /dev/sdX for both disks.

Then you'll need to contact LT to transfer the basic key first, since it's been less than a year.

You just need to create a new install on the pro key then copy the complete config folder from the other key except the license.

It's not working correctly, it's full of these: Nov 16 10:36:39 Tower rsyslogd: action 'action-1-builtin:omfile' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.2002.0 try https://www.rsyslog.com/e/2027 ] Check config.

If it's not a RAM issue could be corrupt LUKS headers, do you have a backup of those? In any case two simultaneously disable disks is usually not a disk problem, SMART looks OK for both and they are on a SASLP which is not recommended for Unraid and known to drop disks sometimes, so you might want to check if the actual disks mount with UD and if yes re-sync parity instead. Also I wouldn't recommend encryption unless you absolutely needed it, it's just another layer of complexity, but if you keep using it make sure you backup the LUKS headers.

Yes, it's a known issue.

File is too large to open, even with Notepad++, delete/rename that one, start a new syslog server and post that after a crash.

Nov 16 07:19:58 Tower kernel: nvme nvme0: Device not ready; aborting reset, CSTS=0x1 Nov 16 07:19:58 Tower kernel: nvme nvme0: Removing after probe failure status: -19 Device is dropping offline, try a different m.2 slot if available, or a different NVMe device.

This is usually a flash drive issue, backup the config folder and redo it.

Enable the syslog server and post that log after a crash.