Zfs send | zfs receive overwriting mountpoints

TrueNAS General
1

I nearly had an aneurysm today when I did my normal backup, but for the first time choosing to send encrypted datasets as raw, with a command like:

zfs send -v -R -w tank@backup-2025-06-27 | zfs receive -v -F -o readonly=on backuptank/backup

The aneurysm formed as I went to mount my home directory and got an error that it didn’t exist…

zfs list -t fs -r backuptank showed:

NAME                                USED  AVAIL  REFER  MOUNTPOINT
backuptank                          2.55G  10.8T    96K  /mnt/backuptank
backuptank/backup                   2.55G  10.8T   112K  /mnt/tank
backuptank/backup/home              2.55G  10.8T   304K  /mnt/tank/home
backuptank/backup/home/evan         2.55G  10.8T   312K  /mnt/tank/home/evan

Note that backuptank/backup mounted itself onto /mnt/tank where tank is supposed to be…

I worked out that I can zfs receive -u to not mount the received dataset, and therefore can fix this after the backup completes, but is this supposed to happen and is there a better way to avoid?

Best wishes,

Evan

2

Things will workout a lot simpler, if you try the same with a tool like syncoid.

3

Thank you for the idea! Syncoid doesn’t seem to mention encrypted datasets or raw mode? I don’t want the data re-encrypted (so I can use the same keys to open it as the original) or re-compressed (one of the encrypted datasets is large and manages 1.57x with zstd-6 and 1.0x with lz4…, whereas the rest of the datasets are best with lz4).

4

Just to add: zfs receive -x mountpoint did not help – the mountpoint was still copied from the source.

5

syncoid does work with encrypted datasets, and replicate in raw mode

use "–sendoptions=w " with syncoid to achieve this

(note : it starts with two - but appears as a long dash here)

6

Perfect – thank you! It uses zfs send/receive underneath. What does it do differently to not munge the mountpoints?

7

I think syncoid author Jim Salter is the best person to explain this. checkout

8

The issue still occurs with syncoid but syncoid helped me find it, and syncoid behaves slightly different in a way that is less dangerous.

zfs send -R implicitly sets -p – Include the dataset’s properties in the stream. This includes mountpoint. syncoid does its own method of --recursive that does not automatically include --preserve-properties, but I need --preserve-properties, and enabling it also sends the mountpoint. However, syncoid sends the mountpoint as /mnt/mnt/tank which at least does not conflict with /mnt/tank! That will be fine. :slight_smile:

I wasn’t aware of syncoid previously – thank you!

For those interested in syncoid: it needs a perl module Capture::Tiny. I downloaded syncuid and Capture::Tiny .pm files from GitHub, and installed like this into /mnt/tank/local:

export PREFIX=/mnt/tank/local
export PERL5LIB=$PREFIX/lib/perl5
mkdir -p $PERL5LIB/Capture
cp Tiny.pm $PERL5LIB/Capture
cp syncoid $PREFIX/bin

and set PERL5LIB in .zshrc.

9

Also I found the order of command line options mattered. With —sendoptions=w somewhere in the middle it errored with source/destination dataset not found, but worked when put last.

10

I submitted a PR for syncoid syncoid: add capability to preserve inherited properties by evan314159 · Pull Request #1013 · jimsalterjrs/sanoid · GitHub

  • not set excluded properties when preserving properties (like mountpoint)
  • add new option --preserve-inherited-properties to copy properties that were inherited at the source but would not be inherited at the destination
1 Like