On 02/18/12 05:12, Roberto Waltman wrote:
Solaris 11 Express 1010.11/snv_151a
I strongly suggest upgrading to Solaris 11 there have been some
important ZFS and specifically ZFS encryption related bug fixes.
They were created with encryption
on, forcing all others to be encrypted.
The keysource for slice_?/base
was set to
while creating the file systems.
Then I stored the keys (one key per
pool) in files in a subdirectory
of home/user1, and set keysource for
(Similarly for the other two pools)
Did you ever export the slice_0 pool and reimport it or reboot the
server ? Basically are you and ZFS both 100% sure you had the correct
passphrases stored in those files ?
So far so good.
Several weeks and several terabytes
of data later, I decided to relocate
the files with the encryption keys
from a subdir of user1 to a subdir
of root. Copied the files and set
slice_0/base keysource to
Exactly how did you do that ?
zfs key -c -o keysource=passphrase,file:///root/keys/key_0
zfs set keysource=passphrase,file:///root/keys/key_0
The first does a key change and actually reencryptes the on disk data
encryption keys using the newly generated AES wrapping key that is
derived from the passphrase. The second only change where to find the
That broke it. After doing that, the base
file systems (that contain no data files)
can be mounted, but trying to mount any
other fs fails with the message:
"cannot load key for 'slice_?/base/fsys_?_?': incorrect key.
Can post some sample output of:
zfs get -r encryption,keysource slice_0
In particular include a few examples of the filesystems you call 'base'
and the fsys ones.
What is important here is understanding where the encryption and
keysource properties are set and where they are inherited.
Darren J Moffat
zfs-discuss mailing list