Reading the ATA error log: UNC, ICRC, ABRT, CCTO, IDNF, AMNF

When smartctl -l error returns entries instead of “No Errors Logged”, the error type field in each entry tells you what failed. The ATA Summary Error Log records individual I/O failure events with the error type, the LBA where the error occurred, the command that triggered it, and a timestamp relative to the current power cycle.

Six common smartctl error type codes are UNC, ICRC, ABRT, CCTO, IDNF, and AMNF. They are not equally serious. UNC means confirmed data loss. ICRC means a cable problem. ABRT may mean nothing at all. Knowing which one you are looking at determines whether you are evacuating data or reseating a cable.

Two structural limitations affect every reading of this log. First, the ATA Summary Error Log holds only five entries. A drive displaying “5 errors” may have logged thousands; older entries are overwritten as new ones arrive. Second, timestamps are power-cycle-relative, formatted as Dd+HH:MM:SS.msec, and wrap after approximately 49 days of continuous uptime (32-bit millisecond counter). If a drive has been running longer than that without a power cycle, timestamps become ambiguous.

What this means

Each error entry has an error type derived from the ATA error register. The type is diagnostic: it tells you which subsystem failed.

UNC (Uncorrectable Error): The drive attempted to read a sector and could not recover the data, even after applying ECC. The data at that LBA is lost. This is the most serious error type. UNC errors correspond to Offline Uncorrectable sectors (SMART ID 198) and typically appear at the LBAs of Current Pending Sectors (ID 197). Treat UNC as confirmed data loss unless you have redundancy (RAID, replication, backups).

ICRC (Interface CRC): A data transfer between host and drive over the SATA or SAS interface failed a CRC check. The drive’s media is fine; the problem is in the physical connection. This corresponds to UDMA CRC Error Count (SMART ID 199). ICRC errors point to cable degradation, loose connectors, failing backplane ports, or EMI. When ICRC appears alongside ABRT, the root cause is frequently a bad SATA cable or failing controller rather than the drive itself.

ABRT (Command Aborted): The drive rejected or aborted a command. Often benign. Some manufacturers log ABRT for unsupported commands, which violates the ATA specification but is common enough to expect. ABRT on a valid command can indicate a firmware issue or thermal protection triggering.

CCTO (Command Completion Timed Out): The drive did not complete a command within the expected time window. On HDDs this points to mechanical problems or firmware hangs; on SSDs it may indicate the drive is overwhelmed by internal garbage collection. In practice, command timeouts typically surface as ABRT entries in the drive’s error log and as I/O timeout messages in kernel logs. Check dmesg for the host-side perspective.

IDNF (ID Not Found): The requested LBA does not map to a known sector. This indicates sector mapping corruption, which can result from firmware bugs or flash translation layer (FTL) metadata corruption on SSDs.

AMNF (Address Mark Not Found): The drive could not locate the address mark on the disk surface. A low-level format error specific to HDDs, indicating servo or surface problems. On SSDs this code should not appear; if it does, suspect a firmware bug.

flowchart TD
    A["Error log shows entries"] --> B["Identify error type"]
    B --> C["UNC, IDNF, or AMNF?"]
    B --> D["ICRC or ICRC + ABRT?"]
    B --> E["ABRT alone?"]
    B --> F["CCTO?"]
    C --> C1["Media or surface failure: replace drive"]
    D --> D1["Transport problem: check cable, backplane"]
    E --> E1["Often benign: verify command was supported"]
    F --> F1["Mechanical or firmware: check dmesg, thermal"]

Common causes

Quick checks

All read-only and safe on a production drive.

# Summary error log (last 5 entries)
smartctl -l error /dev/sdX

# Extended error log (more entries, 48-bit LBA registers)
smartctl -l xerror /dev/sdX

# SMART attributes that corroborate error log entries
smartctl -A /dev/sdX | grep -iE "Reallocated|Current_Pending|Offline_Uncorrectable|UDMA_CRC"

# Kernel-side I/O errors and timeouts
dmesg | grep -iE "I/O error|medium error|reset|timeout|offline" | tail -20
# On systemd hosts, journalctl -k may retain entries beyond dmesg's ring buffer

# Self-test results (cross-reference failure LBAs with error log LBAs)
smartctl -l selftest /dev/sdX

# Full SMART overview including SATA link speed
smartctl -a /dev/sdX

How to diagnose it

1. Pull the extended error log, not just the summary log. The summary log holds only five entries and may hide a much larger error history. Run smartctl -l xerror /dev/sdX to see more entries with 48-bit LBA registers. If an LBA in the extended log looks nonsensical (beyond the drive’s capacity), some drives report it in wrong byte order. smartctl -F xerrorlba /dev/sdX corrects this; drives known to need it are preset from the smartmontools drive database.

2. Identify the error type for each entry. The type code appears in a line like “Error: UNC” within each entry. Group entries by error type. A cluster of UNC errors at nearby LBAs indicates localized media failure. UNC errors scattered across the entire LBA range indicate widespread degradation.

3. Cross-reference the LBA from UNC entries against SMART attributes. If the LBA matches sectors in Current Pending (ID 197) or Offline Uncorrectable (ID 198), the drive is in active media failure. Cross-reference with the self-test log to see if an extended self-test already flagged the same LBA.

4. Check for ICRC entries alongside ABRT entries. ICRC plus ABRT frequently indicates a cable or controller problem, not drive media failure. Look at UDMA CRC Error Count (ID 199). If CRC errors are increasing but reallocated, pending, and uncorrectable sectors are all zero, the problem is the transport layer.

5. Check kernel logs for the host’s perspective. The drive’s error log shows what the drive saw. The kernel log shows what the host saw. Look for “I/O error, dev sdX”, “medium error”, “link reset”, or “task abort” that correlate with the drive’s error log entries. A drive with clean SMART attributes but dirty kernel logs may have a firmware bug or controller issue.

6. Account for the log’s limitations. Timestamps are relative to the current power cycle, not wall clock time. If the drive has been up for more than 49 days, timestamps may have wrapped; use the relative ordering of entries to reconstruct the event sequence. If the log shows “5 errors”, the total may be much higher; use smartctl -l xerror for more history.

Metrics and signals to monitor

Fixes

UNC errors: media failure, evacuate data

UNC means data at the LBA is unrecoverable. If you have redundancy (RAID, ZFS, replication), the data exists elsewhere. If not, that data is gone.

1. Verify redundancy is intact. For ZFS, check zpool status for checksum errors. For mdadm, check cat /proc/mdstat.
2. Begin data migration from the affected drive immediately.
3. Schedule drive replacement. Do not wait for the drive to fail completely.

If UNC errors are isolated to one or two LBAs and the drive otherwise reports clean SMART data, the failure may be contained. In production, treat any UNC as the start of progressive failure. The drive’s spare pool is being consumed, and the next bad sector may not be recoverable. See Current_Pending_Sector non-zero: unreadable sectors and I/O latency spikes.

ICRC errors: check the cable, not the drive

ICRC errors almost never indicate drive failure. They indicate a problem in the physical connection between host and drive.

1. Reseat the SATA or SAS cable at both ends.
2. Swap with a known-good cable.
3. Move the drive to a different port or bay to isolate drive versus infrastructure.
4. Check SATA link speed in smartctl -a. If the current link speed is below the maximum (e.g., 3Gbps on a 6Gbps drive), the link has downshifted due to accumulated errors.

If CRC errors stop after cable replacement, the cable was the problem. Do not replace the drive for ICRC errors unless media errors (UNC, reallocated sectors) are also present.

ABRT errors: determine if they matter

ABRT on unsupported commands is benign and can be ignored. Some drives log these entries despite the ATA specification saying they should not.

1. Check what command was aborted. The error entry includes register values showing the command that triggered the abort.
2. If the aborted command is a standard read or write, investigate firmware issues or thermal protection.
3. If the drive is otherwise healthy (clean SMART attributes, no UNC, no CCTO), ABRT entries for unsupported commands are noise.

CCTO errors: investigate mechanical or firmware problems

Command completion timeouts indicate the drive is struggling to respond.

1. Check dmesg for corresponding I/O timeout messages.
2. Check drive temperature. Thermal throttling on SSDs can cause commands to time out.
3. For HDDs, CCTO may indicate the drive is busy with internal retries on bad sectors. Cross-reference with pending and reallocated sector counts.
4. If CCTO errors are frequent and accompanied by increasing latency, plan replacement.

IDNF or AMNF errors: replace the drive

IDNF indicates sector mapping corruption. AMNF indicates a low-level surface or servo problem on HDDs. Both mean the drive’s internal data structures or physical media are compromised.

1. Verify whether a firmware update or unsafe shutdown preceded the errors.
2. Begin data migration immediately.
3. Replace the drive.

Prevention

Use the extended error log. The summary log’s five-entry limit hides the full error history. Incorporate smartctl -l xerror into monitoring to capture more entries and avoid the false reassurance of a nearly empty log.

Correlate error log entries with SMART attributes. UNC errors should track with ID 198 and ID 197. ICRC errors should track with ID 199. If the error log and attributes disagree, investigate why. A non-zero error count with an empty summary log means old entries were overwritten, not that errors stopped.

Schedule periodic extended self-tests. Self-tests proactively surface latent bad sectors before production I/O hits them. An extended self-test that completes with a read failure at a specific LBA gives you the same information as a UNC error in the log, but before data loss affects users.

Monitor kernel I/O errors alongside SMART data. A drive with clean SMART data but kernel I/O errors is a classic firmware or controller problem that SMART-only monitoring misses entirely.

Track the error count as a rate, not just a value. A drive with 3 historical errors that has been stable for months is less concerning than a drive that gained 3 errors this week. Alert on growth from baseline, not absolute count. This matters especially when deploying monitoring on an existing fleet where drives may have historical error counts from before monitoring was in place.

Beware firmware quirks in the error log. Some firmware versions report inconsistent error counts or error log pointers. A warning such as “ATA error count X inconsistent with error log index Y” reflects firmware-log inconsistency, not necessarily drive failure. Since smartmontools 7.5, smartctl -l error no longer prints bogus log entries when the error index is nonzero but the error count is zero.

How Netdata helps

• Per-second I/O latency metrics correlate UNC errors on bad sectors with the multi-second await spikes they cause. When a drive retries a failing read, the latency spike is visible in disk metrics before the SMART attribute updates.
• SMART attribute collection for IDs 5, 197, 198, and 199 runs automatically, providing the corroborating signals that confirm what the error log shows.
• Kernel log monitoring captures the host-side I/O errors, timeouts, and link resets that accompany drive-side error log entries, giving you both perspectives in one timeline.
• ML-based anomaly detection flags the latency signature of a drive entering a bad-sector retry loop, which can precede or accompany error log entries.
• Rate-of-change alerting on SMART counters catches error log growth the moment it starts, rather than waiting for the next manual smartctl check.

Related guides

• Current_Pending_Sector non-zero: unreadable sectors and I/O latency spikes
• Data Units Written vs rated TBW: computing SSD endurance runway
• SMART says PASSED but the drive is failing: why the health check lies
• How S.M.A.R.T. actually works: a mental model for operators
• smartctl disk monitoring checklist: the SMART signals every server needs
• SMART monitoring maturity model: from survival to expert
• NVMe Available Spare below threshold: the spare block pool is running out
• NVMe Critical Warning bits: decoding the health-log bitmask
• NVMe Media and Data Integrity Errors incrementing: confirmed NAND corruption
• NVMe Percentage Used at or above 100%: rated endurance consumed
• NVMe media placed in read-only mode: Critical Warning bit 3
• NVMe NVM subsystem reliability degraded: Critical Warning bit 2