lima-vm/lima · error

resolving path %#q: %w

Error message

resolving path %#q: %w

What it means

Thrown by pkg/apfs.Chown when resolvePath cannot walk the given volume-relative path in the on-disk APFS filesystem B-tree. resolvePath looks up each path component's directory record; any missing component, checksum failure, or omap resolution failure is wrapped here with the offending path. It is the APFS-equivalent of ENOENT or a corrupt-tree failure.

Source

Thrown at pkg/apfs/chown.go:40

	if err != nil {
		return err
	}
	defer c.close()

	vol, err := c.findVolume(volumeRole)
	if err != nil {
		return err
	}

	fsRootPhys, err := c.omapLookup(vol.omapTreeAddr, vol.rootTreeOID, vol.latestXID)
	if err != nil {
		return fmt.Errorf("resolving filesystem root tree OID %d: %w", vol.rootTreeOID, err)
	}

	for _, path := range paths {
		inodeNum, err := c.resolvePath(fsRootPhys, vol.omapTreeAddr, vol.latestXID, path)
		if err != nil {
			return fmt.Errorf("resolving path %#q: %w", path, err)
		}
		if err := c.chownInode(fsRootPhys, vol.omapTreeAddr, vol.latestXID, inodeNum, uid, gid); err != nil {
			return fmt.Errorf("chown inode %d (%#q): %w", inodeNum, path, err)
		}
	}
	return nil
}

// container holds the open disk image file, the byte offset where
// the APFS container starts (nonzero for GPT-partitioned disks),
// and the APFS block size.
type container struct {
	f          *os.File
	baseOffset int64 // byte offset of APFS container within file
	blockSize  uint32
}

// volumeInfo holds resolved volume information.

View on GitHub (pinned to dd909d0973)

Solutions

1. Mount the image (read-only) and verify the exact path exists on the target volume.
2. Check the volumeRole argument matches the volume that contains the path (Data vs System).
3. Fix path typos; components are relative to the volume root with no leading slash needed.
4. If the path should exist but doesn't, the image may be truncated or the wrong snapshot — regenerate the image.

Example fix

// before
err := apfs.Chown(disk, apfs.VolRoleData, 501, 20, "Libary/LaunchDaemons/foo.plist")
// after
cerr := apfs.Chown(disk, apfs.VolRoleData, 501, 20, "Library/LaunchDaemons/foo.plist")

// verify paths exist on the target volume before chowning
for _, p := range paths {
    if err := apfs.Chown(diskPath, volumeRole, origUID, origGID); err != nil {
        return fmt.Errorf("pre-check %q failed: %w", p, err)
    }
}

if err := apfs.Chown(disk, role, uid, gid, paths...); err != nil {
    var pathErr part
    if matched, _ := fmt.Sscanf(err.Error(), "resolving path %q", &pathErr); matched {
        // report which component is missing; mount image read-only to inspect
    }
    return err
}

When it happens

Trigger: Passing a path to apfs.Chown that does not exist in the volume (e.g. "Library/LaunchDaemons/foo.plist" when foo.plist was never created or was deleted), using the wrong volume role so a valid path is absent from that volume, or B-tree corruption/omap failures while walking components.

Common situations: Typo or wrong-case path component (APFS lookups here are case handling per directory record, not the mount's case-insensitivity); path assumes files created later by guest boot that are not yet in the image; targeting the System volume role when the file lives on the Data volume.

Understand the failure class

Background: "File not found" and ENOENT errors: why libraries can't find a file that should exist — this error's family across 50 libraries.

Related errors

• resolving filesystem root tree OID %d: %w
• chown inode %d (%#q): %w
• read block 0: %w
• finding APFS partition: %w
• reading container superblock: %w

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