Why Does Snapshot Replication Skip One Encrypted Child Dataset While Others Transfer?

Replication can skip one encrypted child dataset when its task scope, snapshot set, encryption root, send mode, permission, or destination policy differs from siblings.

Encryption alone does not automatically prevent ZFS snapshot replication, and a raw encrypted send can work even while the key is unloaded. The skipped child often has a separate encryption root, lacks the snapshot name selected by the recursive job, is excluded by the task, requires raw-send permission, or cannot be received under the destination’s current encryption layout. Compare the child with one working sibling property by property.

Confirm That the Child Dataset Is in the Replication Scope

Record the selected source dataset, recursive setting, excluded children, naming filters, destination path, and exact skipped-dataset log message.

TrueNAS remote-replication documentation requires the source and destination scope to be defined explicitly, so one child can be omitted while siblings transfer.

If the child never appears in the task plan, fix selection or exclusion before testing encryption.

Verify That the Child Has the Snapshot Required by the Job

List snapshots recursively and compare the skipped child with a working sibling, including snapshot name, creation time, holds, and incremental base.

The FreeBSD handbook describes snapshots as dataset-specific states, so a parent snapshot name does not prove every independent child has the required snapshot.

Create or align snapshots through the normal task. A mismatched incremental chain may require a new baseline.

Compare Encryption Root, Key Status, and Key Location

Record encryption, encryptionroot, keystatus, keyformat, and keylocation for the skipped child and a working encrypted sibling.

Ubuntu’s ZFS properties reference defines encryption-root and key properties, revealing whether the child inherits its parent’s key or owns a separate root.

An unloaded key does not block every raw send, but it blocks workflows that need plaintext access.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Check Whether the Job Requires a Raw Encrypted Send

Compare raw, non-raw, recursive, property-preserving, compressed, and incremental send options for working and skipped datasets.

Oracle documents that raw encrypted replication has specific requirements for source, target, and encryption context.

If the child was previously received non-raw and the task switches to raw incrementals, the destination history may be incompatible.

Verify Send, Raw-Send, Snapshot, and Key Permissions

Identify the replication user and compare delegated permissions on the parent, skipped child, and working sibling.

OpenZFS documents delegated administration permissions, explaining why access can differ for a child with its own encryption root.

Grant only the missing operation. Broad administrator access hides the true boundary and increases risk.

Check Destination Encryption and Inheritance Rules

Compare the destination parent’s encryption state, whether the target child exists, its encryption root, inherited properties, and receive behavior.

The FreeBSD zfs receive manual explains that raw streams are received as-is, while non-raw streams can follow different encryption inheritance.

A pre-existing incompatible destination child can reject only that dataset while siblings created by the task succeed.

Run a One-Dataset Test and Preserve Working Replication

Pause the schedule, generate a dry-run or verbose send estimate for the skipped child, and compare it with a working sibling.

The ZimaSpace article on encrypted recovery-key warning signs provides the adjacent safety rule: prove key dependencies before deleting the only encrypted copy.

The issue is resolved when the child is in scope, has the required snapshots, uses a compatible send mode, passes permissions, and receives under the intended encryption layout.