‹ vmount

Recover data from a corrupted ext4 drive on Mac

When a Linux drive won't mount, your phone is dying, and the data you need to ship a release is sitting on it — vmount on macOS is often the fastest path to "files in Finder again." This guide walks through the recovery flow that works in practice for the most common ext4 failure modes.

Before you start: read-only first, every time. If the drive has a partial failure, writing to it (including a normal mount with journal replay) can make things worse. vmount defaults to read-only mode — keep it there until you've copied what you can.

The recovery flow

Plug the drive in via USB or Thunderbolt (use a USB-to-SATA or USB-to-NVMe enclosure for an internal disk).
Open vmount and select the ext4 partition. Choose "Connect (Read-Only)" from the disk picker.
Try Open in Finder. Many "broken" drives are just dirty — the filesystem is consistent, the journal just wasn't replayed cleanly. If files appear, copy what matters off immediately.
If mount fails or files are missing: open vmount's Repair menu and run fsck.ext4 (read-only check). vmount shows the output live.
If fsck reports unrecoverable damage: open the in-app terminal. The Linux microVM has the full toolkit a Linux recovery USB would — debugfs, extundelete, testdisk, photorec. The AI assistant can guide which tool fits your symptom.
Image the drive first if it's failing physically. If smartctl shows reallocated sectors or read errors, run ddrescue from the in-app terminal to clone to a healthy disk before recovery — every read shortens the dying drive's life.

Common ext4 failure modes & what works

"The drive doesn't show up in Finder"

macOS doesn't read ext4 natively, so it never will. This isn't corruption — it's the wrong tool. Open vmount, the partition will appear in the disk picker. Click Connect.

"Mount failed: filesystem has unsupported features"

ext4 added features like metadata_csum_seed and orphan_file in recent Linux kernels. Older recovery tools (and even macOS Disk Utility) refuse them. vmount's bundled Linux kernel is recent enough that this error is uncommon — try mounting again with vmount.

"Bad superblock"

ext4 keeps backup superblocks at predictable offsets. From the in-app terminal:

dumpe2fs /dev/sda1 | grep -i superblock — list backups
fsck.ext4 -b 32768 /dev/sda1 — try the first backup

"Journal recovery error"

Mount with the journal disabled to see if the data is otherwise OK. From the in-app terminal:

mount -t ext4 -o ro,noload /dev/sda1 /mnt/recover

"Deleted files I need back"

extundelete can recover recently-deleted ext4 files when no overwriting has happened. The in-app terminal has it pre-installed; the AI assistant can guide the exact command for your case (single file vs full directory tree recovery have different flags).

When vmount can't help

Some failures are beyond software recovery:

Drive is physically dead (no SMART data, doesn't spin up, USB enclosure won't see it) — needs a clean-room recovery service.
Encrypted volume with lost passphrase — LUKS-encrypted ext4 needs the key. vmount can't brute-force it.
Drive was zero-filled or fully overwritten — no recovery tool will help.

After recovery

Once you've copied everything you can off, you have two choices:

Discard the drive if it's failing physically (SMART warnings, repeated sector errors).
Reformat with vmount if the corruption was a software fluke (cable yank during write, kernel panic). vmount can mkfs.ext4 from inside the app — give it a fresh filesystem and re-test.

Get vmount

$29 one-time. Apple Silicon, macOS 14+. 14-day refund guarantee — if vmount can't read your drive, you're not out the cost.

Buy vmount — $29 Download