Why Do NAS Scrub Errors Follow One Controller Port Across Different Drives?

Scrub errors that follow one controller port across different drives usually point to the shared path rather than the disks’ recording media.

A scrub reads a broad set of blocks and can expose faults that ordinary daily access never reaches. If different known-good drives develop errors only when connected through the same port, the common components include the controller channel, connector, cable, backplane lane, expander route, power path, firmware, and cooling around that path. The diagnosis must prove that the error follows the port while preserving drive identity, timestamps, and error type.

Confirm That the Error Follows the Port, Not the Drive Name

Record drive serial numbers, stable device IDs, controller port or HBA PHY, cable, bay, pool member, and the read, write, and checksum counters before the next scrub. Do not rely only on changing /dev/sdX names.

The TrueNAS drive troubleshooting flow emphasizes collecting pool and SMART evidence before clearing errors or replacing a device.

After a powered-down swap, ask whether the error follows the drive, bay, cable, or controller port. Change only one component per test so the result remains interpretable.

Separate Scrub Checksum Errors From Drive Read and Write Errors

Save the complete scrub result and per-device counters. A checksum mismatch, command timeout, unreadable sector, and failed write represent different failure layers.

Oracle documents that a ZFS scrub verifies active data checksums, while pool status separately reports read, write, and checksum errors for each device.

If checksum errors rise without media errors and follow one physical path, suspect data corruption between memory and the drive or unstable transport. If read errors follow the drive across ports, the disk becomes more likely.

Map the Disk to the Exact Controller and Link

Trace the stable disk path through the host controller, PCI address, SAS expander or SATA port, enclosure, cable, and bay. Save the mapping before moving hardware.

The lspci device view identifies the PCI storage controller independently of filesystem and pool names, which helps distinguish one failing controller path from a disk that merely received a new device name.

For an HBA, include PHY and expander information when available. Two front bays may share one mini-SAS cable or expander lane even though the UI presents them as separate slots.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Inspect SATA or SAS Link Resets During the Scrub

Monitor the kernel log from the moment the scrub begins. Look for hard resets, COMRESET failures, link-down events, command timeouts, protocol errors, and negotiated-speed changes on the affected path.

The Linux libATA guide describes per-port link reset and error recovery, showing why repeated messages tied to one ATA port are stronger evidence than a generic pool warning.

Preserve the first transport message. Later filesystem errors may only be consequences of the controller losing communication during a read.

Compare Interface CRC and Command-Timeout Counters

Capture SMART attributes and logs for each drive before and after one scrub. Track whether interface CRC or command-timeout counters increase only on the affected path.

Unraid explains that UDMA CRC errors occur between the drive and controller, commonly implicating cables, connectors, routing, or the controller link rather than platter damage.

Historical CRC totals do not identify the current component. Record the raw count, run one bounded test, and check only whether the value increased.

Run Drive Tests Separately From the Scrub Workload

Run supported short and extended SMART tests when the pool is otherwise quiet and the data is protected. Avoid scheduling a full SMART test at the same time as another scrub or rebuild.

The Debian smartctl reference separates drive-internal self-tests and error logs from host-side filesystem verification.

A drive that passes an internal test but produces errors only on one controller port strengthens the path hypothesis. It does not prove the disk is perfect, so continue monitoring after the port is changed.

Swap One Shared Component and Repeat a Bounded Scrub

With backups current and the server powered down, move a known-good drive through the suspect path or replace one cable while keeping the other variables stable. Do not shuffle every disk simultaneously.

The ZimaSpace guide to a dropped disk versus a bad bay provides the adjacent controlled-swap method; this article applies that logic specifically to scrub errors that repeatedly follow one controller port.

Stop the scrub and prioritize data protection if errors rise rapidly, several drives on the same controller reset, the pool degrades, or applications report corrupted files. The issue is resolved only after the same port path completes repeated scrub and normal I/O without new errors.