Receiving side shouldn't mount datasets

[zviratko]

By default, if a dataset has canmount=on and mountpoint set, it will get mounted, this is highly undesirable in a backup pool.
I usually worked around thet when making backups by setting canmount=noauto/off on the parent dataset I receive the backup into, but this doesn't work when the source dataset has this set explicitely (not inherited), like FreeBSD zroot datasets. Ouch.

At the very least, zfs-replicate should by default use "zfs recv -u" so that the datasets are not mounted and one can change their properties, even better it should support "zfs receive -o canmount=noauto" (or maybe -x?) from a config file so that it can be safely received by absent minded admin who will forget to change those after the receive is done the first time (which can take some time).

Not sure if there's a better way to do this.

Thanks.

[tschettervictor]

This could probably be solved by adding "ZFS_OPTIONS" as a variable.

Then simply include that after the "zfs recieve"

A default value of -u maybe?

Have you tried simply adding -u to these two variables in the config file?

## Set the pipe to the destination pool. But DO NOT INCLUDE the pipe (|)
## character in this setting. Filesystem  names from the source will be
## sent to the destination. For increased transfer speed to remote hosts you
## may want to customize ssh ciphers or include mbuffer.
## The macro %HOST% string will be substituted with the value of the "@host"
## target in the replication set.
## The default WITH a "@host" option is "ssh %HOST% zfs receive -vFd"
## The default WITHOUT a "@host" option is "zfs receive -vFd".
##
#DEST_PIPE_WITH_HOST="$SSH %HOST% $ZFS receive -vFd"
#DEST_PIPE_WITHOUT_HOST="$ZFS receive -vFd"

[aaronhurt]

I don't think it needs a new variable, modifying the existing pipes should be sufficient.