Unraid Parity Check Errors: Correcting vs Non-Correcting

I'm here because… (find your section in 30 seconds)

• I just got an email / saw 'errors found' and I want to know if I should panic → start with the next section 'What parity check errors actually mean', then 'Decide whether to correct'. tl;dr: don't run a correcting check yet. Most error reports after an unsafe shutdown are benign — but you have to look at the evidence first.
• The check was scheduled (non-correcting) — what now? → 'Read the evidence before acting'. Open Tools > Diagnostics, download the bundle, check Parity History, check SMART on every disk. Only then decide.
• The check was manual (correcting, by default) and it already wrote — am I in trouble? → 'Read the evidence before acting' + 'Decide whether to correct'. If a data disk was the wrong side, correcting just locked the corruption into parity. Recovery now requires a known-good backup, not parity.
• Errors keep growing across checks → that's the SMART/cable-degradation pattern, not a one-shot parity drift. Cross over to `/nas/unraid-drive-failing-smart-first-steps` for the SMART-evidence flow.
• Recent unsafe shutdown → expected to produce some parity errors; not alarming on its own if SMART is clean across the array. See 'What parity check errors actually mean' for the bound on 'benign' vs 'investigate'.
• A disk is now red-balled / disabled → recovery is a different flow. Stop here, jump to `/nas/unraid-drive-failing-smart-first-steps`. Don't replace or rebuild until you've read the diagnostics.
• I want to know the difference between correcting and non-correcting → 'What parity check errors actually mean' + the `/nas/unraid-parity-cache-pool-setup` page covers the toggle defaults and decision criteria.

What parity check errors actually mean

• An Unraid parity check compares the parity disk to the XOR of all data disks; a sync error means at least one bit disagrees.
• A non-correcting check (default for scheduled checks) reports errors without writing — this is the diagnostic mode you want first.
• A correcting check writes parity to match the current data state, which can lock in corruption if a data disk is actually the wrong side.
• Recent unsafe shutdowns, RAM issues, SATA/power cable faults, and failing disks are the usual root causes — not Unraid itself.

Read the evidence before acting

• Do these in order before any other action — don't skip ahead, don't run another check yet.
• 1) Open Main > Array Devices. Confirm the parity disk and all data disks show no red ball, no missing status, and no fresh SMART warnings. A red-balled disk changes the entire flow — stop here and jump to `/nas/unraid-drive-failing-smart-first-steps`.
• 2) Open Tools > Parity History. Record the date, duration, error count, and whether the check was correcting or non-correcting. A scheduled check is non-correcting by default; a manual check defaults to correcting. This determines whether parity was just measured or already overwritten.
• 3) Open Tools > Diagnostics > Download. Save the bundle before any further action — the bundle is the only place that captures the array's state if a disk later fails. Name it with today's date and the error count, e.g. `diagnostics-2026-05-31-37errors.zip`.
• 4) Cross-check the syslog for context around when the errors appeared. From the UI: Tools > System Log > use the filter box, search for `unsafe shutdown`, `CRC error`, or `mdcmd`. From the CLI (Tools > Terminal): `grep -E 'unsafe|mdcmd|CRC|sync error' /var/log/syslog | tail -100`. Note any unsafe-shutdown line within 48 hours of the errors — that's almost always the root cause and explains benign drift.
• 5) Run a SMART short test on every array disk: Main > click the disk > SMART tests > Short. Takes ~2 minutes per disk and runs in parallel. Wait for results before deciding on next steps.

Decide whether to correct

• Default decision: do NOT run a correcting check yet. A non-correcting re-check after fixing the suspected root cause (cables, RAM, power, recent unsafe shutdown) is almost always the safer next step.
• If the error count is small (<100), SMART is clean across the array, and you've identified an unsafe shutdown as the root cause: a non-correcting re-check that returns 0 errors is your green light. The original errors were benign post-shutdown drift, and parity self-recovered.
• If error counts are growing across consecutive checks (e.g. 5 errors → 50 → 500 over three monthly checks): a disk is degrading. Do NOT run a correcting check — it would write the bad disk's contents into parity. Run SMART long tests on every disk and look for the disk with growing reallocated/pending/UDMA CRC.
• If a disk shows reallocated or pending sectors: that disk is the suspect. Don't correct parity — parity is currently correct and the data disk is wrong. Follow the disk-replace flow (`/nas/unraid-drive-failing-smart-first-steps`) rather than rewriting parity from the failing disk.
• If UDMA CRC errors on any disk are growing: that's a cable or backplane fault, not a disk fault. Power off, reseat the cable on both ends, and run a non-correcting check before doing anything else. UDMA CRC writes through to parity if you correct — same propagation risk.
• Only run a correcting check when you are certain the parity disk (not a data disk) is the divergent one AND all SMART data is clean AND you've ruled out unsafe-shutdown drift. That's a narrow case — usually you don't get here.

Last reviewed

2026-05-07 · Reviewed by HomeTechOps. Reviewed for Unraid parity error triage using Parity History, Diagnostics bundle, per-disk SMART long tests, syslog evidence, and non-correcting vs correcting check sequencing.

Source-backed checks

HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.