daylight8306

That's what I'm currently fearing, not everything was backed up (I know that's my fault). But if that's the case, what would random damage both drives like that? Make me doubtful for trusting Unraid as my os.

> cryptsetup --debug luksDump /dev/sda1 # cryptsetup 2.7.5 processing "cryptsetup --debug luksDump /dev/sdb1" # Verifying parameters for command luksDump. # Running command luksDump. # Installing SIGINT/SIGTERM handler. # Unblocking interruption on signal. # Allocating context for crypt device /dev/sdb1. # Trying to open and read device /dev/sdb1 with direct-io. # Direct-io is supported and works. # Initialising device-mapper backend library. # Trying to load any crypt type from device /dev/sdb1. # Crypto backend (OpenSSL 3.4.1 11 Feb 2025 [default][legacy][threads][argon2]) initialized in cryptsetup library version 2.7.5. # Detected kernel Linux 6.6.78-Unraid x86_64. # Loading LUKS2 header (repair disabled). # Acquiring read lock for device /dev/sdb1. # Opening lock resource file /run/cryptsetup/L_8:17 # Verifying lock handle for /dev/sdb1. # Device /dev/sdb1 READ lock taken. # Trying to read primary LUKS2 header at offset 0x0. # Opening locked device /dev/sdb1 # Verifying locked device handle (bdev) # Trying to read secondary LUKS2 header at offset 0x4000. # Reusing open ro fd on device /dev/sdb1 # Trying to read secondary LUKS2 header at offset 0x8000. # Reusing open ro fd on device /dev/sdb1 # Trying to read secondary LUKS2 header at offset 0x10000. # Reusing open ro fd on device /dev/sdb1 # Trying to read secondary LUKS2 header at offset 0x20000. # Reusing open ro fd on device /dev/sdb1 # Trying to read secondary LUKS2 header at offset 0x40000. # Reusing open ro fd on device /dev/sdb1 # Trying to read secondary LUKS2 header at offset 0x80000. # Reusing open ro fd on device /dev/sdb1 # Trying to read secondary LUKS2 header at offset 0x100000. # Reusing open ro fd on device /dev/sdb1 # Trying to read secondary LUKS2 header at offset 0x200000. # Reusing open ro fd on device /dev/sdb1 # Trying to read secondary LUKS2 header at offset 0x400000. # Reusing open ro fd on device /dev/sdb1 # LUKS2 header read failed (-22). # Device /dev/sdb1 READ lock released. Device /dev/sdb1 is not a valid LUKS device. # Releasing crypt device /dev/sdb1 context. # Releasing device-mapper backend. # Closing read only fd for /dev/sdb1. > sudo dd if=/dev/sdb1 count=20 | hexdump -C 00000000 46 b8 44 48 27 78 98 f1 94 39 37 55 48 b4 27 41 |F.DH'x...97UH.'A| 00000010 16 24 7e a0 b8 6b ef 71 ed 7e e5 9f e8 13 31 62 |.$~..k.q.~....1b| 00000020 22 6c 30 9b a2 86 d6 b6 87 87 eb a0 e4 af 0d d4 |"l0.............| 00000030 89 69 87 5c 80 3f e2 b9 42 19 aa e6 72 49 c3 ca |.i.\.?..B...rI..| 00000040 8e 62 f5 7f e2 57 72 41 81 ce 27 75 8b d6 81 9c |.b...WrA..'u....|

Hello This morning it seems to be a critical problem with my Unraid server, and would greatly appreciated help getting working again. System Information: Unraid Version: 7.0.1 Hardware: ThinkCentre M70q (i5-11400T, 32GB DDR4 RAM) Pool Drives: 2 x 18TB Seagate HDD connected via USB Enclosure (ICY BOX IB-3740-C31) My ZFS pool was working last night. This morning, I found the system unresponsive – the WebUI was inaccessible so I did a hard reboot. Since the reboot, the pool fails to mount. The UI says "Unmountable: Bad or No System File System". Partitions are detected: > lsblk sda 8:0 0 16.4T 0 disk └─sda1 8:1 0 16.4T 0 part sdb 8:16 0 16.4T 0 disk └─sdb1 8:17 0 16.4T 0 part blkid /dev/sdX1 only returned a PARTUUID for both, no filesystem TYPE. cryptsetup isLuks /dev/sdX1 ; echo $? Returns 1 zpool import no pools available to import I have tried the drives on a different Ubuntu computer and get the same results. marvin-diagnostics-20250427-1056.zip