Enabling FileVault encryption on a restored-from-backup Mac

This might be a niche one. It’s potentially relevant for those restoring a Mac from a Time Machine backup, especially onto a Mac which started life running something older than macOS 10.13.

I just wanted to quickly document my experience with this for future searchers, including myself in 5 years.

Background

Yesterday I went through the following steps:

  • Upgrade my Macbook’s main SSD, in a mid-2012 15″ Pro Retina model. I largely followed this and this with some small ‘modifications’ that became necessary with my choice of parts, which I don’t want to admit to in public are outside the scope of this post.
  • Boot into recovery – ⌘+R during start up.
  • Use the Disk Utility to create a single partition on the new drive with the most suitable available format. I think this was Mac OS Extended (Journaled). Notably it was not APFS, because the version of the recovery tools I was looking at dated from the era when Apple hadn’t yet run out of big cat breeds. (When scoping out the option of doing a clean install first, it offered me OS X 10.8.)
  • Restore from Time Machine to the new partition.
  • Enable TRIM, using trimforce. Bear in mind this might be risky with some SSDs but probably not – do it at your own risk!

So far, so kind-of-OK. I had forgotten about APFS at this stage although I knew the recovery tools were outdated. But the restore had eventually completed and I seemed to have a working system.

Where’s my encryption?

As a moderately paranoid developer with important Client Stuff among the files I just restored, my next step was to look at getting FileVault (2) full disk encryption, the pretty-solid offering built into macOS, enabled on my new primary disk partition.

As expected FileVault was correctly showing the status for the new drive as not encrypted yet.

Slightly less expected, when I tried to enable it (and after it made me write down the recovery code, thanks Apple), I was told my drive format was not compatible, without much detail as to why.

My restored system was claiming to be on macOS 10.13.4 at this point, but the upgrade helpers from its installer had never actually run on this disk yet. This turns out to matter.

Back to ‘real’ macOS 10.13 and APFS

My plan next was to wipe the system, do a clean install from the newer macOS image and then restore on top of this.

Fortunately the first step of just downloading macOS offered me an in-place (re-)install of what I’d just downloaded. This turned out to be the much simpler and quicker solution!

  • Allow time for a reboot and a fairly slow OS upgrade process.
  • Go to the App Store and find macOS. Download it, even if the version is exactly the same as the version your Mac says it’s running.
  • An install process will ensue, with unspecified upgrade & optimise steps which you might remember from the ‘real’ upgrade from 10.12 to 10.13. One of these steps is actually converting your filesystem to APFS. There might be other system changes required for FileVault, like updating or generating synthesised recovery volumes – it’s pretty opaque what the scope of these steps actually is. All I know for sure is that they’re magic and they make FileVault usable.
    Warning: One piece of less exciting magic is that the process resets some system config like Apache virtual hosts, so you may need to manually merge the new stock configs with any custom changes you made, manually getting these from your backups. This is behaviour I’ve seen with normal macOS upgrades before, and is a pretty good argument for using Homebrew in preference to the built-in development tools wherever that works for you.

Once you get back in, Disk Utility should show your primary internal disk is now an APFS Volume. And FileVault should now let you go ahead and set up disk encryption. Easy.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.