zfs create -o encryption=on …. Children inherit. Rotate keys on Linux with zfs change-key (not Solaris zfs key -c).

OpenZFS encrypts datasets, not the whole pool. Pool labels and metaslabs stay visible; tank/secret contents do not. This is the TrueNAS / Proxmox / Linux path.

Background: Ars native encryption, ZFS encrypted backups.

Create

1
2

zfs create -o encryption=on -o keyformat=passphrase -o keylocation=prompt tank/encrypted
zfs create tank/encrypted/child1

child1 inherits encryption. Do not set encryption=off on a child: OpenZFS will not let you punch a plaintext hole under an encrypted parent.

Keyfile instead of prompt:

1
2

zfs create -o encryption=on -o keyformat=passphrase \
  -o keylocation=file:///root/zfs.key tank/encrypted

The key file does not live on the encrypted dataset. USB, TPM, or a path on another pool.

Load the key at boot

1
2

zfs load-key tank/encrypted
zfs mount tank/encrypted

Without load-key the dataset exists and zfs list shows it, but it will not mount.

Receive plaintext as encrypted

On the first recv you can set encryption properties:

1
2
3

zfs send tank/test@snap1 \
  | zfs recv -o encryption=on -o keyformat=passphrase \
      -o keylocation=file:///path/to/keyfile tank/encrypted

That receive is without -w. Raw -w copies the source wrapping key: only valid if the source was already encrypted. Details: unencrypted send into encrypted.

Rotate the passphrase (OpenZFS)

On Solaris the command was zfs key -c. On OpenZFS / Linux / TrueNAS:

1
2

zfs change-key tank/encrypted
zfs get keyformat,keylocation,keystatus tank/encrypted

New keyfile:

1

zfs change-key -o keylocation=file:///media/stick/key tank/encrypted

Wrapping-key rekey (does not rewrite every block; rotates the key that wraps master keys) is zfs change-key -i depending on version — read your zfs change-key man page before production.

See also: snapshot holds, off-host backups.

First recv with -o encryption=on (no -w). Destination dataset name is required.

Same bytes, new key. Source stays plaintext; destination is born encrypted. OpenZFS allows this only on the initial receive (dataset that does not exist yet).

Source thread: r/zfs.

Command

1
2
3
4
5
6

zfs snapshot tank/test@snap1
zfs send tank/test@snap1 \
  | zfs recv -o encryption=on \
      -o keyformat=passphrase \
      -o keylocation=file:///path/to/keyfile \
      tank/encrypted

Things that silently break the send:

1. Do not use -w. Raw send replicates the source encryption state. Plaintext in → plaintext out, and -o encryption=… is ignored or errors.
2. Name the destination dataset (tank/encrypted). A recv with no target does not create it.
3. Passphrase vs file: keylocation=prompt is a bad fit across a non-interactive pipe. Use a keyfile.
4. Later incrementals (-i) inherit encryption. Do not pass -o encryption=on again.

Check

1
2

zfs get encryption,keystatus,keyformat tank/encrypted
zfs load-key tank/encrypted   # if keystatus=unavailable

The other direction

Encrypted → encrypted with the same wrapping key: zfs send -w. Encrypted → new wrapping key: send without -w (ZFS decrypts on send; recv encrypts). That needs load-key on the source and is slower.

See also: native encryption.