On 23/11/2010 21:01, StorageConcepts wrote:
r...@solaris11:~# zfs list mypool/secret_received
cannot open 'mypool/secret_received': dataset does not exist
r...@solaris11:~# zfs send mypool/plaint...@test | zfs receive -o encryption=on
mypool/secret_received
cannot receive: cannot override received encryption
---
Is there a implementation/technical reason for not allowing this ?
Yes there is, this is because of how the ZPL metadata is written to disk
- it is slightly different between encrypted and non encrypted cases and
unfortunately that difference shows up even in the ZFS send stream.
It is a known (and documented in the Admin guide) restriction.
If we allowed the receive to proceed the result would be that some ZPL
metadata (including filenames) for some files may end up on disk in the
clear, there are various cases where this could happen but it is most
likely to happen when the filesystem is being used by Windows clients
because of the combination of things that happen - but it can equally
well happen with only local ZPL usage too particularly if there are
large ACLs in use.
In the mean time the best workaround I can offer is to use
tar/cpio/rsync, but obviously you lose your snapshot history that way.
--
Darren J Moffat
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
