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
slice_0/base to
(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
"passphrase,file:///root/keys/key_0", etc.

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 passphrase.

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

Reply via email to