lima-vm/lima · error

finding APFS partition: %w

Error message

finding APFS partition: %w

What it means

Thrown by openContainer when block 0 lacks the APFS NX magic and the fallback GPT scan (findAPFSPartitionGPT) fails. findAPFSPartitionGPT returns an error when the GPT header at LBA 1 is missing ("no GPT header found"), a partition entry cannot be read, or no APFS Container partition GUID is present in the table. The disk is therefore neither a raw APFS container nor a GPT-partitioned disk with an APFS partition.

Source

Thrown at pkg/apfs/chown.go:86

		return nil, fmt.Errorf("open disk: %w", err)
	}
	c := &container{f: f}

	hdr := make([]byte, 4096) // minimum APFS block size
	if _, err := f.ReadAt(hdr, 0); err != nil {
		f.Close()
		return nil, fmt.Errorf("read block 0: %w", err)
	}

	if le.Uint32(hdr[nxMagicOff:]) == nxMagic {
		// Raw APFS container (no partition table).
		c.blockSize = le.Uint32(hdr[nxBlockSizeOff:])
	} else {
		// Look for a GPT partition table and find the APFS partition.
		offset, err := findAPFSPartitionGPT(f)
		if err != nil {
			f.Close()
			return nil, fmt.Errorf("finding APFS partition: %w", err)
		}
		c.baseOffset = offset
		if _, err := f.ReadAt(hdr, offset); err != nil {
			f.Close()
			return nil, fmt.Errorf("read APFS superblock at offset %d: %w", offset, err)
		}
		if le.Uint32(hdr[nxMagicOff:]) != nxMagic {
			f.Close()
			return nil, fmt.Errorf("APFS partition at offset %d has bad magic", offset)
		}
		c.blockSize = le.Uint32(hdr[nxBlockSizeOff:])
	}

	if c.blockSize < 4096 {
		f.Close()
		return nil, fmt.Errorf("invalid block size %d", c.blockSize)
	}
	return c, nil

View on GitHub (pinned to dd909d0973)

Solutions

1. Confirm the image is macOS APFS — raw container or GPT with an APFS Container partition (GUID 7C3457EF-...-00306543ECAC).
2. If the disk uses MBR, re-format/partition as GPT with an APFS partition, or use the raw container image directly.
3. Pass the whole-disk image, not an individual non-APFS partition image.
4. Hex-inspect LBA 0/1 (`xxd -l 1024`) to confirm what partition scheme the file actually has.

Example fix

// before
apfs.Chown("data-ext4.img", ...) // finding APFS partition: no GPT header found
// after
apfs.Chown("macos-apfs.dmg", ...) // a GPT-partitioned APFS (or raw APFS) image

// check LBA1 for GPT signature before calling Chown on non-raw images
f, _ := os.Open(diskPath)
hdr := make([]byte, 8)
f.ReadAt(hdr, 512)
f.Close()
if string(hdr) != "EFI PART" {
    // also not raw APFS? then it is not an APFS disk at all
}

if err := apfs.Chown(diskPath, role, uid, gid, paths...); err != nil {
    if strings.Contains(err.Error(), "finding APFS partition") {
        // wrong filesystem type: re-create image as APFS or use correct image
    }
    return err
}

When it happens

Trigger: apfs.Chown called on a disk formatted with MBR instead of GPT, a non-APFS disk (ext4, NTFS, HFS+), a GPT disk whose APFS partition was deleted, or an arbitrary/corrupt file whose first block doesn't match nxMagic.

Common situations: Passing a Linux-format data disk image to an APFS-specific tool; an image converted between formats losing the partition table; targeting the wrong slice of a disk (e.g. a non-APFS partition device) rather than the whole disk.

Related errors

• resolving filesystem root tree OID %d: %w
• resolving path %#q: %w
• chown inode %d (%#q): %w
• read block 0: %w
• read APFS superblock at offset %d: %w

AI-assisted analysis of lima-vm/lima@dd909d0973 (2026-09-01). Data as JSON: /api/errors/8d4e915afcda82d6. Report an issue: GitHub.