[Share] [Warning/Solution] Faulty hard drives (even unformatted) can block RAID/Volume boot sequences
Posted: 28 Jul 2026, 23:38
[Warning/Solution] Faulty hard drives (even unformatted) can block RAID/Volume boot sequences 
Hello everyone,
I wanted to share a technical experience that recently blocked my NAS, in case it happens to someone else.
The Scenario:
My TerraMaster NAS (Model: F6-424 Max, running TOS Version: 7.0.0791) displayed "Volume Corrupted" errors on a large-capacity volume (TRAID / RAID 5 with LVM) after every reboot. The mdadm process kept consuming 95% CPU at startup, preventing the system from mounting the volumes, even though the array was physically healthy.
The Discovery:
After analyzing the system logs (dmesg) via SSH, I detected constant I/O errors (DID_ERROR) on a 4 TB hard drive installed in a bay. This drive was physically failing and, although it was not part of any storage pool nor had any formatted volume, the Linux kernel kept trying to interrogate it during the boot process.
These read failures on the faulty drive caused bus timeouts (exceeding 30 seconds per command). As a result, the TOS startup service abandoned the assembly of the sub-RAID arrays (leaving them in an inactive state due to lack of response time), making the main volume inaccessible and triggering the false corruption warning.
The Solution:
Physically remove the faulty drive from the bay.
Conclusion:
If you have a failing drive in a bay, physically remove it before writing off a volume or suspecting a failure in your main RAIDs. The mere presence of a device with hardware I/O errors can collapse the Linux boot sequence and make the system think healthy volumes are corrupt.
I hope this saves other users some troubleshooting time. Best regards!
Hello everyone,
I wanted to share a technical experience that recently blocked my NAS, in case it happens to someone else.
The Scenario:
My TerraMaster NAS (Model: F6-424 Max, running TOS Version: 7.0.0791) displayed "Volume Corrupted" errors on a large-capacity volume (TRAID / RAID 5 with LVM) after every reboot. The mdadm process kept consuming 95% CPU at startup, preventing the system from mounting the volumes, even though the array was physically healthy.
The Discovery:
After analyzing the system logs (dmesg) via SSH, I detected constant I/O errors (DID_ERROR) on a 4 TB hard drive installed in a bay. This drive was physically failing and, although it was not part of any storage pool nor had any formatted volume, the Linux kernel kept trying to interrogate it during the boot process.
These read failures on the faulty drive caused bus timeouts (exceeding 30 seconds per command). As a result, the TOS startup service abandoned the assembly of the sub-RAID arrays (leaving them in an inactive state due to lack of response time), making the main volume inaccessible and triggering the false corruption warning.
The Solution:
Physically remove the faulty drive from the bay.
Conclusion:
If you have a failing drive in a bay, physically remove it before writing off a volume or suspecting a failure in your main RAIDs. The mere presence of a device with hardware I/O errors can collapse the Linux boot sequence and make the system think healthy volumes are corrupt.
I hope this saves other users some troubleshooting time. Best regards!
