> 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-discu > ss >
We are also tracking ZFS encryption questions here: http://hub.opensolaris.org/bin/view/Community+Group+zfs/encrypt Thanks, Cindy -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
