## TL;DR
Btrfs incremental send needs a parent snapshot that is read-only, present on the sender, and already present with the same UUID on the receiver. A parent mismatch means the named parent was deleted, was not read-only, or the receiver copy differs. List snapshots on both sides, pick a genuinely common parent, or do a full send to re-establish the chain.

```text
btrfs send failed parent subvolume mismatch
```

## Use this when
- btrfs send with a parent fails with parent mismatch or cannot find parent errors.
- The parent snapshot was cleaned up on one side by retention.
- A full send works but every incremental fails.

## Not for this skill when
- Receive fails from a full or corrupt stream mid-transfer. Different stage.
- ZFS replication checksum errors. Different filesystem.

## Steps
1. List subvolumes and snapshot UUIDs on sender and receiver and compare them for the intended parent. Verify: the parent presence and UUID on both sides are checked
2. Confirm the parent snapshot is read-only on the sender; a writable parent cannot be used for send. Verify: the read-only property is set
3. If no common parent exists, perform a full send of the newest snapshot to re-seed the receiver. Verify: the full send receives cleanly
4. Align retention on both sides so parents needed for the next incremental are not deleted early. Verify: retention keeps at least the last common snapshot
5. Run the next incremental send with the verified parent and confirm receive completes. Verify: incremental replication works again

## Variant phrasings
### btrfs send parent not found incremental
The not-found phrasing.
### btrfs receive parent uuid mismatch
The UUID variant.
### btrfs incremental send failed parent deleted
The deletion wording.

Compatibility: Btrfs on Linux kernel 6.x with btrfs-progs 6.x, send and receive between local or SSH-connected filesystems.

## Why it happens
Incremental send is a diff against a parent the receiver must already hold identically, identified by UUID. Aggressive snapshot cleanup, a parent converted back to writable, or a receiver rebuilt from a different seed all break that shared reference. The protocol cannot guess a substitute, so it refuses rather than sending an unusable diff.

## Edge cases / pitfalls
- Keep parent snapshots read-only from creation. Converting them invites this failure.
- Snapshot cleanup tools must know which snapshots are replication parents. Coordinate both retentions in one place.
- A full send after mismatch is normal recovery, not data loss. Budget its time and bandwidth.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fK2rzR7Vp0u3J9_vSqOTsQ