APFS

APFS Container Recovery

Scan before repairing or recreating APFS container structures.

The APFS container holds one or more volumes. When the container metadata is damaged, volumes may vanish or fail to mount even though the device is still visible. Container-level damage is more serious than volume-level issues because it can affect every volume inside.

Refindo guidance for apfs container recovery

First: do not make the source worse

Treat this as a recovery situation before you treat it as a repair task. The priority is to preserve readable data and avoid new writes to the affected device.

  • Do not rebuild or recreate the APFS container before scanning it.
  • Do not repair the container in place, which overwrites the records a scan needs.
  • Do not change the partition map on a disk with a damaged container.
  • Do not save recovered files into the affected container.

Scan and preview first

Refindo is suitable for scan-and-preview recovery from a detectable APFS device. It does not rebuild APFS containers in place.

Likely causes

  • Corrupted APFS container superblocks or volume mapping records.
  • Partition map changes or failed resizing operations.
  • Power loss during writes or system updates.
  • SSD behavior, including TRIM, reducing recovery after deletion.

Read-only recovery workflow

  • Connect the APFS disk to a supported Mac and grant Refindo disk access.
  • Open Refindo and select the physical device holding the damaged container.
  • Run Quick Scan, then Deep Scan to find volumes through alternate superblock copies.
  • Preview the files you need and recover them to a separate drive.

When to stop self-recovery

  • Disk Utility shows the container with no mountable volumes or zero-byte volumes.
  • The container holds the only copy of irreplaceable data.
  • The disk reports hardware errors or disconnects during scanning.
  • Recent deletion occurred on an SSD where TRIM may have cleared blocks.

Related recovery guides

What You Need to Know

APFS Superblock Structure

Each APFS container uses a superblock that stores the container layout, volume count, and checkpoint data. The superblock is written to multiple locations for redundancy. If the primary superblock is corrupted, recovery tools may locate an older checkpoint copy and use it to map surviving volumes and their file trees.

Do Volumes Survive Container Damage?

Volume data blocks are stored independently of the container superblock. If the container metadata is damaged but the underlying storage is intact, individual file data may still be recoverable through signature-based scanning. The volume records are lost, but the raw file content often persists on the device.

Container Recovery vs Rebuild

Repairing a container modifies its metadata in place, which risks overwriting the very records a scan needs. Rebuilding creates an entirely new container, erasing old metadata completely. Neither approach preserves the original state, so scanning before either operation gives the best chance of recovering files.

Frequently Asked Questions

What is an APFS container?

It is the APFS structure that stores and manages APFS volumes on a disk or partition.

Can I repair the container first?

If files matter, recover first. Repair attempts can change the structures a scan would otherwise inspect.

Can Refindo recover folder names?

Folder names depend on remaining metadata. Deep Scan can find file content even when folder structure is incomplete.

How do I know if my APFS container is damaged?

Disk Utility may show the container with no mountable volumes, or diskutil list may display the container with zero-byte volumes or error annotations.

Can a damaged APFS container affect my other partitions?

No. Container damage is limited to the APFS partition. Other partitions on the same physical disk, such as an EFI or bootcamp partition, are not affected.