Should I run a correcting check right away?

No. Correcting checks write to parity; if a data disk is actually the source of divergence, you can lock in bad data. Run non-correcting first, check SMART, then decide.

How many errors are 'too many'?

Any non-zero count after a clean shutdown deserves investigation. A handful after an unsafe shutdown often resolves once cables and SMART are verified; growing counts across checks always need disk-level triage.

NAS

Unraid parity check errors

Parity errors on Unraid are diagnostic signal, not damage. The wrong response (an immediate correcting check or a disk swap) can lock in bad data. The right response is to read the history, check SMART, and decide before writing.

Best for: Unraid operators who saw 'errors found' in a scheduled parity check or got an email alert from the array.

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

Open Main > Array Devices and confirm the parity disk and all data disks show no red ball, no missing status, and no recent SMART warnings.
Open Tools > Parity History and record the date, duration, error count, and whether the check was correcting or non-correcting.
Open Tools > Diagnostics and download the full bundle before any further action — the bundle is the only place that captures the state if a disk later fails.
Cross-check the syslog for `unsafe shutdown`, `CRC error`, or `mdcmd` lines around the time the errors first appeared.

Decide whether to correct

If the count is small and SMART on all disks is clean, schedule a non-correcting check after fixing any underlying cause (cables, RAM, power) and compare.
If counts are growing across checks, do not run a correcting check yet; check SMART long tests on every disk first.
If a disk shows reallocated/pending sectors, treat that disk as the suspect and follow the replace flow rather than correcting parity.
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.

Evidence from the Unraid admin UI

Reference screenshots from a live Unraid server, captured in 2026-05 with identifying details masked.

Unraid Dashboard parity tile showing parity status, last check date, duration, average speed, error count, and next scheduled check. — Dashboard parity tile: this is the first place to capture the error count and the last check date before any further action.

Unraid Tools menu showing Diagnostics, System Log, Parity History, and Parity Check options. — Tools menu: Parity History records every check; Diagnostics downloads the full evidence bundle before any disk action.

Unraid Settings > Scheduler showing Parity Check frequency, time, and write-corrections-to-parity option. — Settings > Scheduler: confirm whether scheduled checks are correcting or non-correcting. Default scheduled checks should be non-correcting.

Operator snapshotEvidence first

First proof

Open Tools > Parity History.

Screen to open

Tools > Parity History

Expected signal

The history lists each check with date, duration, error count, and whether the check was correcting or non-correcting.

Stop boundary

Stop for heat, swelling, odor, or any electrical safety signal.

Layer path

1Unraid parity is an XOR of all data disks; a sync error means at least one bit disagrees between the parity disk and the computed parity of the data disks.

2A non-correcting check (the default for scheduled checks) reports errors without writing; a correcting check writes parity to match the current data state.

3If a data disk is the divergent side and you run a correcting check, you lock in bad data. Reading SMART and unsafe-shutdown evidence first is non-negotiable.

4Root causes are almost always: recent unsafe shutdown, RAM error, SATA/power cable issue, or a failing disk — not Unraid itself.

Runbook

Step-by-step runbook

Start here. Do each check in order, compare it to the expected result, and stop when the evidence explains the failure or the safe stop point applies.

Capture state without changing anything

Check: the "Parity History review" command below (record counts and type) and Tools > Diagnostics (download bundle, save off-array).

Expected result: You have a saved bundle and a written record of the failing check.

If not: If diagnostics download fails, the UI/server itself may be unstable; treat as a higher-priority issue.

Confirm SMART across every disk

Check: Main > <each disk> > SMART > note Reallocated Sectors, Current Pending, UDMA CRC, Uncorrectable.

Expected result: All counters are zero or stable (not growing).

If not: Any disk with new errors is the suspect; do not start a correcting check.

Address root cause

Check: Re-seat SATA/power cables on powered-down server, verify UPS protects against unsafe shutdowns, run memtest if RAM is suspect.

Expected result: Cabling is firm, UPS shutdown integration is configured, RAM passes memtest.

If not: Without addressing root cause, errors will return.

Safe stop: Stop for heat, swelling, odor, or any electrical safety signal.

Run a non-correcting parity check

Check: Main > Parity Check > Start (uncheck 'Write corrections to parity').

Expected result: Check completes with zero errors during a quiet window.

If not: If errors persist with zero load and clean SMART, the parity disk itself may be the suspect.

Only then consider correcting

Check: Main > Parity Check > Start (with corrections enabled) ONLY if SMART is clean, syslog is clean, and the cause is understood.

Expected result: Correcting check completes; subsequent non-correcting checks return zero errors.

If not: If the correcting check itself finds errors mid-run, stop and capture diagnostics again.

Safe stop: Stop before correcting if any disk shows reallocated/pending sectors.

Decision tree

If: Errors found after a recent unsafe shutdown, all SMART clean.

Then: Likely benign sync drift from in-flight writes during the unsafe shutdown.

Action: Schedule a non-correcting check during a quiet window after fixing whatever caused the unsafe shutdown (UPS, power, kernel panic).

If: Errors growing across multiple consecutive checks.

Then: Hardware is degrading; this is not a one-time event.

Action: Run SMART long tests on every disk individually and replace the disk that fails first.

Safe stop: Stop before running another correcting check until the failing disk is identified.

If: One disk shows reallocated or pending sectors AND errors found.

Then: That disk is the suspect; parity divergence is the symptom.

Action: Treat as a failing disk; follow the SMART triage / replace flow rather than correcting parity.

If: Multiple disks show CRC errors simultaneously.

Then: Controller, cable, or power, not disk-level failure.

Action: Power down, re-seat SATA and power cables, then retest before any rebuild.

Safe stop: Stop before replacing any single disk on the assumption it is failing.

If: Zero errors after re-seating cables and addressing unsafe shutdown.

Then: Original cause was external (power/cable); array is healthy.

Action: Re-enable scheduled non-correcting parity checks and monitor.

Evidence

Evidence table

Symptom	Evidence to collect	Likely layer	Next action
Errors found right after a power outage.	Syslog has 'unsafe shutdown detected' and parity error count is small.	Pending writes flushed inconsistently.	Add UPS protection with safe shutdown; non-correcting check after the next clean reboot.
Errors grow each parity check.	Parity History shows increasing error counts month over month.	Disk or controller failure in progress.	Run SMART long test on every disk; identify the disk with new reallocated/pending sectors.
UDMA CRC errors on a specific data disk.	SMART attribute 199 (UDMA CRC Error Count) is non-zero and rising.	SATA cable, port, or backplane issue.	Power down, re-seat or replace the SATA cable on that disk; retest.
Errors only on one specific scheduled check.	That check ran during a backup or Mover run.	Disk IO contention during the check (rare but possible).	Schedule parity checks outside backup/Mover windows; retest.

Reference

Commands and settings paths

Parity History review

Tools > Parity History

Where: In the Unraid web UI under Tools menu.

Expected: The table lists each check date, duration, error count, and check type (correcting or non-correcting).

Failure means: If history is empty, scheduled checks are disabled; enable them in Settings > Scheduler.

Safe next step: Capture the row(s) showing errors and the check type before any further action.

Diagnostics bundle

Tools > Diagnostics > Download

Where: In the Unraid web UI; downloads <server>-diagnostics-YYYYMMDD-HHMM.zip.

Expected: The .zip contains syslog, SMART reports, mdcmd output, and array state.

Failure means: Without the bundle, evidence is lost if a disk fails or the array is rebuilt.

Safe next step: Save the bundle off-array (Windows PC, separate USB) before changing array state.

SMART long test per disk

Main > <disk> > SMART > Run > Extended (Long) test

Where: In the Unraid web UI for each data disk and the parity disk.

Expected: Long tests complete without 'failure' status; no new reallocated/pending sectors.

Failure means: Any disk that fails the long test or shows growing reallocated/pending sectors is the suspect.

Safe next step: Do not start a correcting parity check or rebuild until every disk passes the long test.

Non-correcting parity check

Main > Parity Check > Start (with 'Write corrections to parity' unchecked)

Where: In the Unraid web UI after addressing root causes.

Expected: Check completes with zero errors.

Failure means: Errors > 0 means the cause is not fully addressed yet; re-read SMART and syslog.

Safe next step: Repeat once more after a known-clean shutdown before considering the array healed.

Hardware boundary

Hardware and platform boundary

Change only when

Replace a disk after a SMART long test fails or reallocated/pending sectors grow across checks; do not replace based on a single parity error count.

Evidence that matters

Disk health (SMART), controller/cable health (UDMA CRC), parity-disk capacity matching the largest data disk, and UPS shutdown integration matter.

Evidence that does not matter

Drive brand reputation and marketing capacity numbers do not matter if SMART evidence is clean.

Avoid

Avoid running a correcting check as the first response to errors; avoid replacing a disk without SMART evidence.

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.

Unraid Docs: ParityUsed for parity-check correcting vs non-correcting behavior, scheduled parity checks, and parity rebuild assumptions.Unraid Docs: Manage the arrayUsed for Unraid array start/stop, parity disk role, data disk role, and read/write behavior assumptions.Unraid Docs: SMART tests and statusUsed for Unraid SMART short/long test execution, reallocated/pending sector interpretation, and disk-health triage.Unraid Docs: Replace a diskUsed for safe Unraid disk replacement, stop-array sequencing, and rebuild-from-parity assumptions.