How to Run fsck on Mac (Disk Check From Single-User Mode)

You boot your Mac and the progress bar gets to 80% and stops. Or it boots fine, but Finder is throwing weird errors when you try to copy a file. Or dmesg is full of I/O errors. The traditional Unix tool for “check and repair the file system” is fsck, and on macOS it’s still here — but the way you run it, and what it actually does, changed significantly with APFS and Apple Silicon.

Here’s the modern guide.

When to actually use fsck

fsck is for a very specific symptom: file system corruption. Signs:

• Boot hangs before reaching the login screen.
• Apps refuse to launch with “missing file” errors for files that visibly exist.
• File copies fail with I/O errors but the SMART status of the disk is fine.
• Disk Utility’s First Aid finishes but reports errors it couldn’t fix.

If your Mac is just slow, or you’re trying to free up disk space, fsck won’t help. It checks the structure of the file system metadata, not the content of your files.

fsck vs Disk Utility

Disk Utility’s “First Aid” runs fsck under the hood. For most users, First Aid is the right interface — it handles the volume mounting/unmounting, picks the right fsck variant for the file system, and presents results in plain English.

You’d use the command-line fsck directly when:

• You can’t get into the OS to run Disk Utility (boot is stuck).
• You’re SSH’d into a headless Mac.
• You want output more detailed than the GUI shows.
• You’re scripting a fleet check.

The fsck variants

There isn’t one fsck. There are several, one per file system type:

• fsck_apfs — APFS volumes. This is the one you’ll use almost always on a modern Mac.
• fsck_hfs — HFS+ volumes. Still around for legacy external drives.
• fsck_msdos — FAT/FAT32.
• fsck_exfat — ExFAT (large external drives).
• fsck_udf — DVDs.

When you run fsck (no suffix), it figures out which underlying tool to invoke based on the volume’s file system. You can also call them directly.

Single-user mode (Intel only)

On Intel Macs, single-user mode boots the kernel and gives you a root shell with no GUI and no daemons. Hold Cmd+S at startup. You’ll get a bare prompt.

/sbin/fsck -fy

-f forces the check even if the journal says everything’s clean. -y answers yes to every prompt — useful since there’s no shell history if you have to retype anything.

When it’s done:

reboot

If repairs were made, run it again — sometimes one pass uncovers issues a second pass needs to fix.

Apple Silicon: no single-user mode

Apple Silicon Macs don’t have single-user mode. Instead, you boot into recovery mode by holding the power button at startup. From the macOS Recovery menu, choose Utilities → Terminal.

Once in the recovery Terminal:

diskutil list

That shows every disk and partition. You’re looking for entries like disk3s1 (the Macintosh HD volume) and disk3s5 (Macintosh HD - Data).

fsck_apfs /dev/disk3s5

Substitute the actual device path. On Apple Silicon, the boot volume is sealed — you can’t repair it from the OS while it’s running. Recovery mode is how.

On a running Mac (read-only check)

You can run fsck_apfs on a mounted volume in read-only mode. It can detect issues but won’t repair them while mounted:

sudo fsck_apfs /dev/disk3s5

If problems are found, you’ll need recovery mode to actually fix them.

For an external APFS drive, unmount it first (the volume, not the whole disk):

diskutil unmount /Volumes/MyDrive
sudo fsck_apfs /dev/disk4s1

Then remount when done:

diskutil mount /dev/disk4s1

Power users use Sweep tooEven when you know the Terminal commands, Sweep is faster and harder to mess up. Get Sweep free →

fsck_apfs flags worth knowing

fsck_apfs -y     # Answer yes to all prompts.
fsck_apfs -n     # Read-only check; no repairs.
fsck_apfs -l     # Live mode (read-only, mounted).
fsck_apfs -q     # Quick check (returns immediately if state is clean).
fsck_apfs -f     # Force check even if the journal is clean.
fsck_apfs -x     # Extended verbose output.

For routine “just want to check,” use -n on an unmounted volume. For “actually fix things,” use -y.

fsck_hfs for old external drives

If you’ve got a Time Capsule, an old USB drive that was formatted before APFS shipped, or a backup drive set up years ago, it might be HFS+. Same idea, different command:

sudo umount /Volumes/OldBackup
sudo fsck_hfs -fy /dev/disk5s2

fsck_hfs is older and arguably more reliable than fsck_apfs because the HFS+ format itself is simpler. Some “won’t mount” external drives can be brought back to life with this.

If fsck_hfs reports “The volume could not be repaired,” and a backup of the data exists somewhere else, your next step is reformatting. If there’s data on it you need, stop and clone the disk first with dd or a more user-friendly tool — running repairs on a failing disk can finish the job of destroying it.

Cloning before repair

If fsck finds errors, it’s a sign the disk has been struggling. Always image the disk first:

diskutil unmountDisk /dev/disk5
sudo dd if=/dev/disk5 of=~/Desktop/disk5.img bs=4m status=progress

That copies the entire physical disk to an image file. If fsck makes things worse, you can mount the image and recover what’s there. Note: this needs as much free space as the source disk’s total capacity, not just its used space.

A friendlier tool is gnu-ddrescue (from Homebrew: brew install ddrescue), which retries on read errors and produces a log of bad sectors:

ddrescue /dev/disk5 ~/Desktop/disk5.img ~/Desktop/disk5.log

For non-emergency cases, dd is fine.

What fsck actually fixes

In APFS, fsck checks:

• Object map consistency (the index of every inode).
• Per-volume tree integrity.
• Snapshot reference counts.
• File extent consistency.
• Volume superblock checksums.
• The container superblock and space manager.

It cannot:

• Recover a deleted file.
• Repair a physically failing SSD (you’ll get hardware-level errors).
• Fix encrypted volumes whose key you’ve lost (FileVault).
• Repair a volume whose container has been catastrophically damaged.

When fsck reports “The volume appears to be OK”

That’s the success message. It means the file system structures are consistent. It does not mean every file’s contents are intact — a file can have valid metadata pointing to a sector full of garbage. For content-level integrity, you need a tool that verifies checksums.

Conversely, “The volume could not be repaired” means structural damage that fsck can’t navigate. Options at that point:

1. Boot from a different drive and try again.
2. Use a third-party recovery tool (Disk Drill, DiskWarrior).
3. Erase and restore from Time Machine.

Skip the Terminal stackSweep does the same cleanup with a UI and a preview before anything is removed. Download Sweep free →

What fsck output looks like (and how to read it)

A successful APFS check ends with:

** Checking volume.
** Checking the container superblock.
** Checking the EFI jumpstart record.
** Checking the space manager.
** Checking the object map.
** Checking the APFS volume superblock.
** Checking the object map.
** Checking the snapshot metadata tree.
** Checking the extent ref tree.
** Checking the fsroot tree.
** The volume /dev/disk3s5 appears to be OK.

A check that found issues will show specific complaints between sections, and at the end either:

• “Repairing the volume.” (followed by repair output)
• “The volume could not be repaired.”

If fsck is silent for a long time on a “Checking the fsroot tree” line, that’s normal on a large volume — it’s walking every inode.

Live mode caveats

You can run fsck_apfs -l <device> on a mounted volume:

fsck_apfs -l /dev/disk3s5

This is what Disk Utility’s “Verify” does. It’s read-only, so it can find problems but not fix them. Don’t use this on a volume you’re actively writing to — false positives will appear because of in-flight operations.

Scripted regular checks

For a Mac that’s a server or runs unattended, you might want a periodic fsck of an external volume:

#!/bin/bash
DEVICE=/dev/disk5s1
MOUNT_POINT=/Volumes/Storage
LOG=/var/log/fsck-storage.log

diskutil unmount $MOUNT_POINT >> $LOG 2>&1
fsck_apfs -n $DEVICE >> $LOG 2>&1
diskutil mount $DEVICE >> $LOG 2>&1

Wrap that in a launchd job (we cover those in another guide) running weekly. If errors are found, the log will tell you and you can manually run with -y to fix.

What about journaling?

APFS uses copy-on-write rather than the journal model HFS+ used. There’s no journal to “replay” the way you might remember from fsck_hfs. APFS reaches a consistent state at every commit by design. If something goes wrong mid-commit (power cut), the volume rolls back to the last good state automatically.

This is why APFS volumes rarely need fsck on a healthy machine — most “corruption” cases come from underlying hardware issues (failing SSD, bad RAM, kernel panics). Fsck verifies the structure but won’t bring data back from a write that didn’t happen.

Apple Silicon specifics

A few things to know:

• The boot system volume is sealed (read-only with cryptographic verification). You can’t fsck it from the running OS — and you don’t need to, since it never changes after install. The Data volume is what you’d actually check.
• Recovery mode boots from a separate volume (Recovery in the container). That’s why you can run fsck from there even when the main system is unhappy.
• diskutil verifyVolume / on the booted system runs a quick check; for serious investigation, use recovery mode.

There’s a GUI for thatSweep wraps the Terminal cleanup in a UI you don’t have to memorize. Try Sweep free →

Bottom line

For a healthy Mac running APFS, fsck is a once-in-a-blue-moon tool. The OS keeps its own house tidy. When you do need it — boot won’t complete, an external drive won’t mount, files are vanishing — knowing how to drop into recovery mode, list disks, and run fsck_apfs -y against the right device is a genuine save.

Don’t run it as a “maintenance step.” It’s a repair tool, not a tune-up.