Editing Encryption

Jump to: navigation, search

Warning: You are not logged in.

Your IP address will be recorded in this page's edit history.
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
Line 1: Line 1:
 
Encryption is now native to ZFS, and it is recommended to use that for greater flexibility and compatibility. See below. However, the core storage documentation will remain here for those who prefer that method.
 
 
== Native ZFS Encryption ==
 
 
On a zpool that supports encryption, encryption may be enabled as follows:
 
 
<code># zpool set feature@encryption=enabled [pool]</code>
 
 
On an zpool that supports encryption, an encrypted zfs dataset may be created as follows:
 
 
<code># zfs create -o encryption=on -o keylocation=prompt -o keyformat=passphrase [dataset]</code>
 
 
This will prompt for the encryption passphrase for this zfs dataset.  Other options for the location of the encryption key and its format can be found in the zfs(1M) manpage.
 
 
An encrypted zfs dataset may be mounted as follows:
 
 
<code># zfs mount -l [dataset]</code>
 
 
This will prompt for the encryption passphrase for this zfs dataset and mount the encrypted dataset; it will not mount any child datasets of the encrypted dataset, but they will be accessible as subdirectories of the encrypted dataset.  If the encryption passphrase is stored in the Keychain as a generic password under the name of the dataset, security(1) may be used to retrieve the passphrase as follows:
 
 
<code># security find-generic-password -a [dataset] -w | zfs mount -l [dataset]</code>
 
 
One common use case for an encrypted volume is a portable backup drive.  Typically the user will create snapshots on the source drive in the computer, and then transmit them to the portable drive using zfs send and receive.  In this scenario it is helpful if the destination dataset on the portable drive is read only, since then there is no need to roll back the destination dataset on the fly to the last valid snapshot.  To make this work with encryption, place the destination dataset as a child dataset of the encrypted dataset in the zpool of the portable drive; because it is a child of the encrypted dataset it, too, will be encrypted.  More importantly, it can be made read-only, whereas it appears that the encrypted parent dataset cannot be read-only (probably so that the key can be stored locally in the parent dataset).
 
 
Additional helpful information about zfs encryption can be found in the [https://blog.heckel.xyz/2017/01/08/zfs-encryption-openzfs-zfs-on-linux/ How-To: Using ZFS Encryption at Rest in OpenZFS (ZFS on Linux, ZFS on FreeBSD, …)].
 
 
 
== Core Storage (File Vault 2) ==
 
== Core Storage (File Vault 2) ==
  
Line 40: Line 13:
  
 
=== Caveats ===
 
=== Caveats ===
You may receive a pop-up claiming the disk isn't readable by this computer. This leads to one step that can be confusing: when unlocking the disk (e.g., on startup), the "bug" will make OS X believe the disk wasn't unlocked, and thus "wiggle," presenting the prompt again.
+
As noted in the article [[suppressing the annoying pop-up]], you will receive a pop-up claiming the disk isn't readable by this computer.
 +
This leads to one step that can be confusing: when unlocking the disk (e.g., on startup), the "bug" will make OS X believe the disk wasn't unlocked, and thus "wiggle," presenting the prompt again.
  
 
Assuming you entered your password correctly, the encrypted volume should now be unlocked, despite the misleading wiggle, and you can safely close the dialog box by clicking "Cancel." You'll know for sure the volume is unlocked when you proceed to import your pool, or you can check directly by looking for <code>Encryption Status: Unlocked</code> in the output of <code>diskutil coreStorage list</code>.
 
Assuming you entered your password correctly, the encrypted volume should now be unlocked, despite the misleading wiggle, and you can safely close the dialog box by clicking "Cancel." You'll know for sure the volume is unlocked when you proceed to import your pool, or you can check directly by looking for <code>Encryption Status: Unlocked</code> in the output of <code>diskutil coreStorage list</code>.
Line 78: Line 52:
  
 
Next, we encrypt the logical volume, our Core Storage disk, disk2:
 
Next, we encrypt the logical volume, our Core Storage disk, disk2:
 
:'''Note: If you choose to use diskutil to do the encryption, it will default to the most secure option, which will take a VERY long time with large disks, optionally use the Disk Util UI and set it up as an encrypted HFS+ volume and under advanced change to least secure (good for new disks)'''
 
  
 
  # diskutil coreStorage encryptVolume /dev/disk2
 
  # diskutil coreStorage encryptVolume /dev/disk2
Line 136: Line 108:
 
</syntaxhighlight>
 
</syntaxhighlight>
  
Also note that you '''don't''' need to worry about changing the partition type in this case to ZFS as described in the [[Suppressing_the_annoying_pop-up|Suppressing the annoying pop-up]] wiki page.
 
  
 
=== Reason to "use latest" ===
 
=== Reason to "use latest" ===
Line 175: Line 146:
 
           Core Storage.
 
           Core Storage.
 
</syntaxhighlight>
 
</syntaxhighlight>
 +
 +
 +
=== Time Machine backups ===
 +
As a follow-up, here's one approach to using ZFS for your Time Machine Backups:
 +
 +
While it has been discussed in heated arguments (e.g., https://github.com/openzfsonosx/zfs/issues/66) I still believe there's at least one ZFS feature I'd like to test with Time Machine: compression.
 +
 +
The hypothesis being:
 +
an HFS+ sparsebundle stored on a compressed (gzip, lz4), deduped dataset should
 +
yield a compression ratio > 1.0.
 +
(previously observed 1.4 with compression=on, dedup=off, FreeBSD network Time Machine drives).
 +
 +
To work around compatible disks for Time Machine, we create an HFS+ sparsebundle, store it on ZFS, and set the mounted image as a backup destination – no "TMShowUnsupportedNetworkVolumes" needed.
 +
 +
1. Create, and mount, a sparsebundle from your ZFS filesystem (e.g., with makeImage.sh).
 +
 +
2. Set your sparsebundle as the (active) backup destination # tmutil setdestination -a /Volumes/Time\ Machine\ Backups

Please note that all contributions to OpenZFS on OS X may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see OpenZFS on OS X:Copyrights for details). Do not submit copyrighted work without permission!

Cancel | Editing help (opens in new window)