Hi everyone,

I need some help to decide what to do next.

I have a Terramaster D5-300C with 3 2TB IronWolf HDDs. One is parity, the others data. This DAS is connected via USB to a mini-PC with Unraid 7.3.1 installed on it. Now the following happened:

1. I get a mail that says: array has errors
   Parity disk - (errors 1050)
   Disk 1 - (errors 1050)

2. Kinda panicky tried stopping the array, which didn't work, since something was blocking it

3. shfs was keeping some files open on Disk 2 (some script i have running via user scripts)

4. kill -9 and array finally stopped

5. parity is in "normal operation" disk 1 "disabled", disk 2 also "normal operation"

6. tried smart test, but sdc and sdd not found --> lsblk reveals they are now sdi and sdj

7. Quick Smart Test on partiy (now sdi) and data 2 (now sdj) --> both clean

8. Trying to reassign both sdi (parity) and sdj (data 2) to their proper slots --> GUI just reloads and no change can be made. The original sda and sdb disks stay in the slots.

9. Since i can't change anything i double check if the array is actually fully stopped (had this one a while ago, where GUI says "Array stopped" but want actually fully stopped) --> decide to have a shutdown of both unraid and Terramaster.

10. After shutdown of both, reseat the drives, check cables. Restart Terramaster --> unraid.

11. Now all 3 drives is missing in unraid

12. Another Shutdown, reseated again, this time checked if Terramaster is still set to "single", start terramaster then unraid and all 3 disks appear fine again

13. Disk 1 at this point still "disabled". Parity and disk 2 "normal operation", so i start the array hoping for a rebuild of disk 1

14. Array started with some errors in the logs and disk 1 still disabled, no option to rebuild.

15. So array stopped again --> set disk 1 to no device --> reassign the proper disk --> start array --> nothing happens (GUI reloads but array doesn't start)

16. Log says: "Tower emhttpd: cmdStart: already started" --> weird

17. mdcmd status | grep -i state --> mdState=STARTED - so GUI says stopped, terminal says started... not that again

18. Tried: mdcmd stop --> device busy

19. fuser -vm /mnt/disk1 --> Cannot stat /mnt/disk1: Input/output error --> oh oh

20. cat /proc/mounts | grep
    disk1 /dev/md1p1 /mnt/disk1 xfs --> disk 1 still mounted?
    umount -l /mnt/disk1 --> now its unmounted and i can properly stop the array

21. mdcmd status | grep -i mdstate --> "stopped" --> phew

22. Start array, hoping for rebuild but only have "Format" and "Check" --> hhhmmm

23. Let's see what the problem actually is: xfs_repair -n /dev/md1p1 --> No such file or directory --> array is stopped, so maybe its sdb and not the emulated md1p1?
    xfs_repair -n /dev/sdb1 --> some bad inodes nothing too bad --> let's try a repair

24. xfs_repair /dev/sdb1 --> "The filesystem has valuable metadata changes in a log which needs to be replayed" --> oh yeah, that would be bad
    mkdir -p /tmp/disk1check

    mount /dev/sdb1 /tmp/disk1check

    umount /tmp/disk1check
    And then: xfs_repair /dev/sdb1

25. Worked fine --> probably when i did "kill -9" in step 4 i did some damage which was now fixed

26. Array start and i get "Unmountable: wrong or no file system" for Disk 1 and still only "Format" and "Check" buttons
    

So, filesystem was repaired and should be okay, disk itself is still marked disabled. So let's try the rebuild again if possible.

27. Stop Array --> Disk 1 "no device" --> Disk 1 proper disk again and Start array --> aaand no changes

28. dmesg -T | tail -30 --> "XFS (md1p1): Corruption of in-memory data (0x8) detected at xfs_trans_cancel+0xd3/0x120 (fs/xfs/xfs_trans.c:977). Shutting down filesystem." --> ah F***

At this time i stopped playing around before i break it even more. My next step would have been "xfs_repair /dev/md1p1" but I'm not sure if it's the right way to fix this situation. I know to not use -L if not necessary, but I'm scared now ^^

As far as i understand: Physical disk (sdb1) is okay and repaired, but the emulated version (md1p1) is now the one throwing corruption errors on mount.

I found this forum post with a similar problem: LINK where the problem seem to be a faulty RAM stick, probably not quite what i have here..
_____________________________________________________________________

So: should i just go with "xfs_repair /dev/md1p1" and hope, or something else?

Thanks so much in advance!

tower-diagnostics-20260815-1714.zip

SHORT_SMART_LOG_ST2000VN003-3CW102_ZWD1FGRT-20260815-2033.txt

Edited Saturday at 06:36 PM3 days by Hasky

The disk was disabled when a write to it failed. That failed write and any subsequent writes are emulated by updating parity. The emulated writes can be recovered by rebuilding. Except the emulated disk is unmountable, so it needs to be repaired before rebuilding. Repair can sometimes leave some files "lost+found", and that might be worse than any writes that were missed.

When you repaired the sd device instead of the md device, parity is no longer in sync with the repaired disk. The repaired disk could be put back in the array with New Config and then parity rebuilt. But it may be missing some writes that were emulated.

If you rebuild the repaired disk, it will be overwritten with the contents of the emulated disk. But the emulated disk is unmountable. The emulated disk must be repaired before rebuilding.

Even though it seems you were using the correct command lines, it is really better to do repair from the webUI.

Do you have any of the output from repairing the physical disk (sd device)?

Since you have already repaired the physical disk filesystem, and it is out of sync anyway, see if you can mount it as an Unassigned Device and check its contents. In particular, look for a lost+found folder at the top level.

And, you might as well go ahead and repair the emulated disk filesystem. Start the array in Maintenance mode and check filesystem on disk1 from the webUI. Post the output.

2 hours ago, Hasky said:

connected via USB

Also, USB not recommended for assigned disks for many reasons.

And, you don't have cache. Does the mini PC not have any ability to use internal drives such as nvme or SSD?

I recommend leaving Docker and VM Manager disabled until everything is working again.

Hi trurl,

Thanks for the infos. So repairing the sd device was a bad idea, lesson learned..

Output of xfs_repair in in the attachment.

I'll try to get it into Unassigned Disk Devices and pull out all the data i can, then try Maintenance Mode and Check Filesystem.

Thanks!

xfs_repair.txt

Hello again,

managed to get it into Unassigned Disk Devices and mounted. Copied some important files off of it, and looked for a lost+found folder, but couldn't find it

I ran Check Filesystem via GUI and: "File system corruption detected.".

The Log in the attachment.

For the other things you wrote:

• I bought a M.2 SSD and will install it into the mini-pc once this ordeal is over and use that for chaching, thanks for the heads up though!

• I disabled docker at step 10 i think and keep it off until all is well^^

• About the USB thing, the TerraMaster D5‐300C only has one USB-C interface, so for now I'm stuck with USB. i thought i could make it work by throttling... Maybe i'll need to switch to different hardware.

xfs_repair_via_gui.txt

3 minutes ago, Hasky said:

I ran Check Filesystem via GUI and: "File system corruption detected.".

The Log in the attachment.

Looks like a lot of corruption was detected. You only ran the check according to the attached log - you did not appear to have run a correction?

5 minutes ago, Hasky said:

managed to get it into Unassigned Disk Devices and mounted. Copied some important files off of it, and looked for a lost+found folder, but couldn't find it

Not having one is a good sign. However that check is one to make AFTER running a xfs_repair in ‘fix’ mode.

Hi itimpi,

yeah just ran the first step, didn't know if i could just run fix. I'll run that now!

Ah okay, didn't know that the folder comes into play after. I'll check once it's done.

Thanks!

Again got dirty logs, can i safely do the
mkdir -p /tmp/disk1check

mount /dev/sdb1 /tmp/disk1check

umount /tmp/disk1check

thing again, like i did with the physical disk?

ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_repair.  If the filesystem is a snapshot of a mounted
filesystem, you may need to give mount the nouuid option. If you are unable
to mount the filesystem, then use the -L option to destroy the log and
attempt a repair.  Note that destroying the log may cause corruption --
please attempt a mount of the filesystem before doing this.

Nope, that won't work.

root@Tower:~# mount /dev/md1p1 /tmp/disk1check

mount: /tmp/disk1check: mount() failed: Structure needs cleaning.

dmesg(1) may have more information after failed mount system call.

Guess the only choice i have is to zero the logs. Any other ideas?

If the disk doesn't mount, the only option is to zero the log; and it's typically fine.

On 8/16/2026 at 7:27 AM, Hasky said:

Again got dirty logs, can i safely do the
mkdir -p /tmp/disk1check

mount /dev/sdb1 /tmp/disk1check

umount /tmp/disk1check

thing again, like i did with the physical disk?

Please use the webUI instead of command line.

Are you trying to run repair on the physical disk or the emulated disk? The commands you have specified will not check either device. Not sure what you had in mind with those commands, since you just mount then unmount without doing anything.

If you run check on the sdb1 device/partition, that will be the physical disk designated sdb. You must check the md device to check the emulated disk.

Please use the webUI instead of command line, whether checking an assigned device or an unassigned device.

Hi JorgeB,

i did and let the Check Filesystem run, thanks for confirming.

trurl: I'm trying to repair the emulated disk, the commands i posted here were the solution to the problem i had earlier "The filesystem has valuable metadata changes in a log which needs to be replayed" where i just mount, wait and unmount to clean the logs. In this case that was not the right way..

The Check Filesystem ran and ended on "File system corruption fixed". So that's good! I then stopped the array and started it normally without maintenance mode to see if the disk would be enabled, but it's still disabled and emulated. I kinda hoped if i start the array normally, that unraid would prompt me to rebuild disk 1 from partiy, but didn't. Do i need to do a partiy-check or rebuild, since i repaired both the disk and the emulated one? If so, how do i force/trigger a rebuild?

Thanks again for the help, much appreciated!

Check Filesystem Status.txt

Edited 11 hours ago11 hr by Hasky

4 hours ago, Hasky said:

Hi JorgeB,

i did and let the Check Filesystem run, thanks for confirming.

trurl: I'm trying to repair the emulated disk, the commands i posted here were the solution to the problem i had earlier "The filesystem has valuable metadata changes in a log which needs to be replayed" where i just mount, wait and unmount to clean the logs. In this case that was not the right way..

The Check Filesystem ran and ended on "File system corruption fixed". So that's good! I then stopped the array and started it normally without maintenance mode to see if the disk would be enabled, but it's still disabled and emulated. I kinda hoped if i start the array normally, that unraid would prompt me to rebuild disk 1 from partiy, but didn't. Do i need to do a partiy-check or rebuild, since i repaired both the disk and the emulated one? If so, how do i force/trigger a rebuild?

Thanks again for the help, much appreciated!

Check Filesystem Status.txt

You will have to rebuild the emulated disk back onto the physical disk after youve corrected the emulated disk filesystem and verified the contents match what you expect. There is no way to re-enable a disabled disk without invalidating parity.

6 hours ago, Hasky said:

The Check Filesystem ran and ended on "File system corruption fixed"

Was this on the emulated disk? That output doesn't look all that good. I think there is probably a lot of lost+found.

You can examine the contents of the emulated disk by starting the array in normal (not maintenance) mode. Then you can decide if the contents of the emulated disk are what you actually want, or if you would be better off with the contents of the physical disk, which you said didn't have any lost+found.

If you want us to take a closer look for you, start the array in normal mode and post new diagnostics.