MacInTouch Amazon link...

FileVault issues

I repurposed a purchased corporate MacBook Pro for my wife. I created a flash drive High Sierra installer, booted from it, formatted the Mac’s SSD drive as APFS (encrypted) with a passphrase, mounted it, and installed High Sierra.

After the install and migration from her old Mac completed (unspecified error at the very very end, but it booted fine and as expected), I shut down and did a clean restart.

I was asked for the drive passphrase first, then a short time later for my wife’s password.

I went to system preferences and tried to enable FileVault boot for her account, so she wouldn’t have to enter two passphrases/words. I unlocked the Security->FileVault panel and clicked the Enable button. Absolutely nothing happened! No dialog showing users and allowing changes.

I searched Google for a while and found some terminal reference ideas using fdesetup, but they returned error messages. I came across several references to some kind of user security token, but the explanations were incomplete for my purposes.

Ric, I generally followed your suggestion to encrypt a volume via Disk Utility instead of turning FileVault on after the fact, in order to avoid the multi-hour to multi-day encryption process, and from that perspective achieved a total success. In fact, I’d guess that this arrangement is actually more secure than auto unlocking with a user account password, but I think this is making my wife’s experience inconvenient and more complex by making her memorize a second password she’ll only use occasionally.

Does anyone know how I could enable her to startup the MacBook Pro with a single user password?
 
Last edited by a moderator:


Ric Ford

MacInTouch
... I was asked for the drive passphrase first, then a short time later for my wife’s password.
I went to system preferences and tried to enable FileVault boot for her account, so she wouldn’t have to enter two passphrases/words. I unlocked the Security->FileVault panel and clicked the Enable button. Absolutely nothing happened! No dialog showing users and allowing changes.
If her user account is not authorized to unlock the FileVault volume, then, yes, she would see a password to unlock FileVault before boot, then get a password prompt after the computer has booted to access her user account.

And the right thing to do, in your case, is indeed to go to System Preferences > Security & Privacy > FileVault, click the padlock to get access, then click the Enable Users button. At this point, you should be able to click an Enable User button for her account, which (if successful) would let her user account password unlock FileVault before boot.

In Terminal, type:

sudo fdesetup list

then provide your admin password to list the users that are authorized to unlock FileVault.

If Enable Users is simply not working for you, are you doing it from an admin account?
 


I have macOS 10.13.4 on a MacBook Pro Retina mid-2012 that exhibits the infamous graphics chip error - green screen at times, only rebooting helps, occasional crashes of the system. Unfortunately the replacement programme of Apple has a limit of 4 years after purchase date, so I cannot get it replaced for free (needs new logic board). Replacing would set me back USD 500, and with the battery close to USD 900 – probably not justifiable.

On the internal SSD I have APFS. So my question is: With the occasional crash (every week or so, dependent on heat, ie when one of my programmes runs that specifies it needs HighPerformanceGraphic Card all the time), will FileVault be a risk to switch on, in the sense that I might lose access to my data on the internal SSD, and lose more and/or with higher probability than with FileVault not enabled? I do have multiple full backups of the disk that I run daily and which I keep non-encrypted (2xTimeMachine, 2xCarbon Copy Cloner, Tresorit online storage).
 
Last edited by a moderator:


If her user account is not authorized to unlock the FileVault volume, then, yes, she would see a password to unlock FileVault before boot, then get a password prompt after the computer has booted to access her user account.

And the right thing to do, in your case, is indeed to go to System Preferences > Security & Privacy > FileVault, click the padlock to get access, then click the Enable Users button. At this point, you should be able to click an Enable User button for her account, which (if successful) would let her user account password unlock FileVault before boot.

In Terminal, type:

sudo fdesetup list

then provide your admin password to list the users that are authorized to unlock FileVault.

If Enable Users is simply not working for you, are you doing it from an admin account?
In all cases, I'm using an admin account.

In Terminal the sudo fdesetup list command returns nothing; I type in the admin account's password, press return, and simply get the terminal prompt for the next command. I interpret this as no user is authorized to unlock FileVault.

In System Preferences > Security & Privacy > FileVault, the Enable User button is enabled after I unlock the panel, but clicking it darkens the button while I the mouse is pressed but otherwise does nothing.

In terminal, I tried the "add" and "-usertoadd" command options, supplying admin passwords when prompted but I only received error messages as far as I recall.
 


Ric Ford

MacInTouch
In all cases, I'm using an admin account.

In terminal the "sudo fdesetup list" command returns nothing; I type in the admin account's password, press return, and simply get the terminal prompt for the next command. I interpret this as no user is authorized to unlock FileVault.

In System Preferences > Security & Privacy > FileVault, the Enable User button is enabled after I unlock the panel, but clicking it darkens the button while I the mouse is pressed but otherwise does nothing.

In terminal, I tried the "add" and "-usertoadd" command options, supplying admin passwords when prompted but I only received error messages as far as I recall.
I hate to say it, but it sounds like your OS installation is messed up, and the best thing might be reinstalling the OS on top again. Maybe someone else has some ideas?
 


I hate to say it, but it sounds like your OS installation is messed up, and the best thing might be reinstalling the OS on top again. Maybe someone else has some ideas?
Oh, I should add one other thing. I created a second admin user, logged in under it and went to System Preferences > Security & Privacy > FileVault and had the same dead-end Enable Users experience.

From searching around that day, I got the impression that there is some kind of user security token that needs to be present before a user can be added to FileVault unlocking, but I could easily be wrong. I added the second user just to see if that caused the token to be created.

Maybe that's a clue.
 


From searching around that day, I got the impression that there is some kind of user security token that needs to be present before a user can be added to FileVault unlocking, but I could easily be wrong. I added the second user just to see if that caused the token to be created.
This topic was discussed on the old MacInTouch platform and it sounds like you're familiar with that. I haven't experienced this issue, but my memory of the previous discussion is that the opposing viewpoint to "encrypt before restore" was summarized by Bombich Software, maker of Carbon Copy Cloner. The third bullet point in this help topic may contain the explanation for the behavior you're seeing, and if so, you might consider wiping the drive, restoring to the unencrypted drive, then enabling FileVault after booting from the drive.
Bombich Software said:
We generally recommend that people establish a bootable backup on a non-encrypted volume, and then enable FileVault while booted from the destination. Some people have discovered, however, that a pre-encrypted volume can (will usually) function as a bootable device. So why do we recommend the former? There are a couple notable differences between pre-encrypting the disk vs. enabling FileVault after booting from the not-encrypted disk. When you enable FileVault via the Security Preference Pane:
  • You get a sanity check that a recovery volume exists (this avoids spending lots of time copying files only to find out that the volume might not be bootable)
  • You get the opportunity to store a recovery key with Apple
  • You can unlock the disk with selected accounts
  • You get a nicer UI on startup to unlock the disk (e.g. it's similar to the LoginWindow interface), vs. a less-polished looking Unlock Disk interface
 


Ric Ford

MacInTouch
I just remembered another factor I'd forgotten:

Don't format your entire drive as FileVault - that creates problems, because, for example, macOS can't resize a FileVault (Core Storage) partition to make room for a Recovery partition, which is needed for FileVault unlocking. I always create tiny unencrypted partitions for this purpose before FileVault-encrypting the main partition.
 


This topic was discussed on the old MacInTouch platform and it sounds like you're familiar with that. I haven't experienced this issue, but my memory of the previous discussion is that the opposing viewpoint to "encrypt before restore" was summarized by Bombich Software, maker of Carbon Copy Cloner. The third bullet point in this help topic may contain the explanation for the behavior you're seeing, and if so, you might consider wiping the drive, restoring to the unencrypted drive, then enabling FileVault after booting from the drive.
I remember reading that article from a link in a previous MiT discussion. Regarding the bullets:
  • You get the opportunity to store a recovery key with Apple
  • You can unlock the disk with selected accounts
  • You get a nicer UI on startup to unlock the disk (e.g. it's similar to the LoginWindow interface), vs. a less-polished looking Unlock Disk interface
I agree, a) no recovery key with Apple; b) still working on unlocking via user accounts (I seem to remember Ric referring to this issue and describing difficulties setting up user unlocking, but seemed to imply that it was possible); and c) Apple might have improved the UI, it's similar to the user password UI now.
 


I just remembered another factor I'd forgotten:

Don't format your entire drive as FileVault - that creates problems, because, for example, macOS can't resize a FileVault (Core Storage) partition to make room for a Recovery partition, which is needed for FileVault unlocking. I always create tiny unencrypted partitions for this purpose before FileVault-encrypting the main partition.
I'd remembered this and thought to try it like this:

* Create the flash installer
* Boot from the flash installer
* Use Disk Utility in the installer to create the APFS (encrypted volume) (no other special steps here)
* After creating the target volume exit Disk Utility
* Install MacOs (High Sierra)

There was a pause at the beginning of the install process where it was doing something with the volume, then the install began. Since I was concerned about this very issue, i removed the flash drive and tried booting from the recovery partition. Although slow to get going, I definitely booted into recovery mode.

Perhaps somewhere in recent versions, the installer Disk Utility or Install process can now handle creating recovery partitions?
 


Ric Ford

MacInTouch
* Use Disk Utility in the installer to create the APFS (encrypted volume) (no other special steps here)
I think this may be problematic if you format the entire drive as one encrypted partition without first setting aside a small unencrypted partition, before doing a macOS install/migration.

But I'm less familiar with APFS, so maybe there are some special tricks/differences involved there in this regard. (I'm firmly in the macOS Sierra/HFS+ camp currently for stability, reliability and security reasons.)
 


Since I was concerned about this very issue, i removed the flash drive and tried booting from the recovery partition. Although slow to get going, I definitely booted into recovery mode.
Did you boot from the Recovery Partition or from Internet Recovery?
Apple said:
About macOS Recovery
Newer Mac computers and some older Mac computers automatically try to start up from macOS Recovery over the Internet when unable to start up from the built-in recovery system. When that happens, you see a spinning globe instead of an Apple logo during startup.
 


I hate to say it, but it sounds like your OS installation is messed up, and the best thing might be reinstalling the OS on top again. Maybe someone else has some ideas?
Before jumping to conclusions, how about seeing what

sudo fdesetup status -verbose

returns (and, maybe, rather than learning about this piecemeal, "man fdesetup" will tell you all the verbs and options for fdesetup)?
 



Before jumping to conclusions, how about seeing what

sudo fdesetup status -verbose

returns (and, maybe, rather than learning about this piecemeal, "man fdesetup" will tell you all the verbs and options for fdesetup)?
OK, here's what I got:

sudo fdesetup status -verbose
Password:
fdesetup: device path = /
FileVault is On.

Thanks for referring me to "man" (it's been a long time). I had been using "help", which listed everything, but man, of course, provides more explanation. I'll study more when I get the time.
 


I want to switch on FileVault 2 (full disk encryption) in macOS 10.13 High Sierra. If I do it in the System Preferences, it warns me "Recovery key: A recovery key has been set by your company, school or institution." Not that I recall, any of that – it is my own private computer. What gives? And how to get around that? I do have full backups of the internal disks (Carbon Copy Cloner). I want to set the recovery key myself, and do not want any one else to have it. Thank you for any insights and tips.
 


In all cases, I'm using an admin account.
In Terminal the sudo fdesetup list command returns nothing; I type in the admin account's password, press return, and simply get the terminal prompt for the next command. I interpret this as no user is authorized to unlock FileVault.
In System Preferences > Security & Privacy > FileVault, the Enable User button is enabled after I unlock the panel, but clicking it darkens the button while I the mouse is pressed but otherwise does nothing.
In terminal, I tried the "add" and "-usertoadd" command options, supplying admin passwords when prompted but I only received error messages as far as I recall.
Apparently there is a very well-known issue concerning the new "Secure Token" which is required for a number of High Sierra system activities -- including working with FileVault2. I ran into the same issue on a Mac Pro and to get around it, I had to use Carbon Copy Cloner, an external backup, and an external bootable High Sierra installer to:

0. Clone my running High Sierra System
1. Wipe the internal drive entirely.
2. Install a fresh copy of High Sierra without migrating.
3. Create a new dummy user without iCloud or any other linkage to an old identity.
4. Ensure that this new user has a token
sudo sysadminctl -secureTokenStatus [username]
5. If it does not, then repeat 1-4.
6. If it does, then you can run Migration Assistant to restore your old OS. After you do so, login as the dummy account, open System Preferences -> Security. If you don't see the "some users cannot unlock the disk" message, then you probably are okay, but just to be safe you can run
sudo sysadminctl -secureTokenStatus [username]
against your users to make sure they all have tokens. If they didn't get their token, then you need to run this command for each of them:
sudo sysadminctl interactive -secureTokenOn <username> -password -
The dash at the end is very important!

Much more info than you could ever want is [here]:
 


I want to switch on FileVault 2 (full disk encryption) in macOS 10.13 High Sierra. If I do it in the System Preferences, it warns me "Recovery key: A recovery key has been set by your company, school or institution." Not that I recall, any of that – it is my own private computer. What gives? And how to get around that? I do have full backups of the internal disks (Carbon Copy Cloner). I want to set the recovery key myself, and do not want any one else to have it. Thank you for any insights and tips.
I ran into the same issue. It seems that some while ago I turned on FileVault (and then off) on an older computer and this created a couple of files that propagated through migrations, upgrades and restores. The solution was to delete those two files.

/Library/Keychains/FileVaultMaster.cer
/Library/Keychains/FileVaultMaster.keychain
 


I ran into the same issue. It seems that some while ago I turned on FileVault (and then off) on an older computer and this created a couple of files that propagated through migrations, upgrades and restores. The solution was to delete those two files.
/Library/Keychains/FileVaultMaster.cer
/Library/Keychains/FileVaultMaster.keychain
Exactly, worked like a charm for me, thank you so much!
They have survived from 20 Jan 2007 (!). That is Mac OS X 10.5 Leopard …
 


How is this issue reproduced? I'm imaging & wiping / reinstalling OS on new and used High Sierra MacBook Pros in the corporate world and haven't encountered it, despite creating a local admin account for both IT and the user. I've created the IT account first (501) sometimes, and sometimes the user's account first and IT account second. Rebooted them all multiple times, with no issues of either account logging in or accessing the SSD. I've run FV encryption from both accounts, both late and early in the account creation process.

TIA
 


How is this issue reproduced? I'm imaging & wiping / reinstalling OS on new and used High Sierra MacBook Pros in the corporate world and haven't encountered it, despite creating a local admin account for both IT and the user. I've created the IT account first (501) sometimes, and sometimes the user's account first and IT account second. Rebooted them all multiple times, with no issues of either account logging in or accessing the SSD. I've run FV encryption from both accounts, both late and early in the account creation process.
In my case I believe the keychain records were created when I started the process of enabling FileVault but interrupted it just after the recovery key was generated. It was long enough ago that I don't remember why I stopped it or any other details.

Several years later, when I again decided to enable FileVault, I encountered the issue. I did an online search for the text of the warning message and that led me to the solution.
 


Ric Ford

MacInTouch
I just did some tests of FileVault performance impact with some very surprising results....

I'm setting up a macOS 10.12 Sierra hard drive system for use on a 2011 iMac with FireWire. (The iMac has only USB 2, which is too slow to be useful for boot.) I was concerned that enabling FileVault would slow the system down too much, as it's not an SSD. So I set up two partitions on the hard drive, one encrypted and one unencrypted and timed booting up for each.

First time through, the FileVault partition took about 27% longer to boot. But on the second boot test, the FileVault partition actually booted about 17% faster! This seemed quite bizarre, so I ran the test a third time. The unencrypted partition took the same amount of time (a little faster than the first time through), while the FileVault partition was even a bit faster than before.

I'm not sure quite what's causing this, but the bottom line is that FileVault performance does not seem to be an issue in this configuration where I thought it could be.

I'd be interested to know, if others run the experiment, whether they get similar or different results.
 


... But on the second boot test, the FileVault partition actually booted about 17% faster! This seemed quite bizarre, so I ran the test a third time. The unencrypted partition took the same amount of time (a little faster than the first time through), while the FileVault partition was even a bit faster than before. ...
Did you account for FileVault loading a stub OS when it boots? I assume you timed it from the moment you entered your password, correct?

FWIW: I run a couple of Snow Leopard Macs with SSDs and no FileVault. They boot far quicker than my Sierra Macs with FileVault.
 


Ric Ford

MacInTouch
Did you account for FileVault loading a stub OS when it boots? I assume you timed it from the moment you entered your password, correct?
FWIW: I run a couple of Snow Leopard Macs with SSDs and no FileVault. They boot far quicker than my Sierra Macs with FileVault.
I timed from password entry for the FileVault volume and timed from power-on for the unencrypted partition. Both were macOS 10.12 Sierra, and I don't think there were any, or any big, differences between them.

I haven't installed a Recovery HD partition on the hard drive, but there's one on the internal SSD of the 2011 MacBook Pro I'm booting. If some of the boot code is coming from that, maybe that helps explain the speedup.
 


I just did some tests of FileVault performance impact with some very surprising results.... I'd be interested to know, if others run the experiment, whether they get similar or different results.
The take-away: FileVault does not significantly increase boot times. Given that, I conclude that FileVault does not significantly slow down disk access (for most uses, I'm sure there are exceptions).

I used a 128GB SSD from an older MacBook Air in an OWC Envoy Case connected via USB 3. I partitioned the SSD into two equal size partitions, the first with FileVault, the second without. I booted both on my MacBook Pro Retina Early 2013.

I used a mechanical stopwatch that has 10 marks/second. I did five timings for each partition. The FileVault partition's first time was from the beginning of the startup chime until the login appeared. The second was from when I pressed return after typing my password until the Apple in the menu bar appeared.

For the normal partition, the first was from the beginning of the startup chime until the Apple logo appeared. The second was from that time until the Apple in the menu bar appeared.

The FileVault partition took about 11 seconds to get to the login. The normal partition took about 4 seconds to get to the Apple Logo. The FileVault partition took about 22 seconds to get from the login to the Apple menu appearing. The normal partition took about 21 seconds to get from the Apple logo to the Apple menu appearing.

Adding up the times, FileValue took about 33 seconds total, the normal partition about 25 seconds total. This makes sense, since FileVault has to load a stub OS from the Recovery partition to do the login; that's what took the extra 7 seconds for the first timing. The second timings are more significant, because that's where the heavy loading takes place. For that, FileVault was only slightly slower.

My methodology:
  • Boot USB with Sierra installer.
  • Run Disk Utility, partition SSD into two equal parts, both HFS+.
  • Install Sierra onto first partition.
  • Boot first Sierra, change sleep settings and do all updates.
  • Restart a couple of times to stabilize and normalize the system.
  • Restart to internal, clone first partition to second.
  • Restart to first partition, enable FileVault, wait until conversion completes.
  • Restart & login three times to stabilize and normalize the system.
  • Restart and time, repeating five times to allow for caching.
  • Restart to second, set up automatic login.
  • Restart to second three times to stabilize and normalize the system.
  • Restart and time, repeating five times to allow for caching.
 


I turned on FileVault on a 1TB SSD (with about 500GB used) on a 2010 Mac Pro. After over 24 hours, it was not even half done. Then I did a little searching and found that the FileVault conversion process is heavily throttled if the computer is idle. I then tried downloading "Jiggler" by Stick Software to fool the computer into thinking it was not idle. This did the trick. The second half of the encryption took well under an hour.
 


I turned on FileVault on a 1TB SSD (with about 500GB used) on a 2010 Mac Pro. After over 24 hours, it was not even half done. Then I did a little searching and found that the FileVault conversion process is heavily throttled if the computer is idle. I then tried downloading "Jiggler" by Stick Software to fool the computer into thinking it was not idle. This did the trick. The second half of the encryption took well under an hour.
Is that what it is? I had a 8TB external I was using as a Time Machine backup that took three-and-a-half weeks (I kid you not) to fully encrypt. I'll give Jiggler a shot on another 4TB unit slowly grinding away now. Thanks!
 



Is that what it is? I had a 8TB external I was using as a Time Machine backup that took three-and-a-half weeks (I kid you not) to fully encrypt. I'll give Jiggler a shot on another 4TB unit slowly grinding away now. Thanks!
I'd try disabling throttling of low-priority i/o:
Code:
sudo sysctl debug.lowpri_throttle_enabled=0
This lasts until you reboot or reenable with =1.
 


Why is the FileVault conversion throttled if the computer is idle? You'd think it would be the exact opposite.
It's likely Apple didn't want to be "battery shamed" when doing the encryption, so rather than use up power (battery or otherwise) all by itself, it instead "hitches a ride" and does more work while the computer is also busy with other tasks.

It sorta makes sense from an efficiency standpoint, but obviously not from a user experience standpoint.
 


Ric Ford

MacInTouch
This topic was discussed on the old MacInTouch platform and it sounds like you're familiar with that. I haven't experienced this issue, but my memory of the previous discussion is that the opposing viewpoint to "encrypt before restore" was summarized by Bombich Software, maker of Carbon Copy Cloner. The third bullet point in this help topic may contain the explanation for the behavior you're seeing, and if so, you might consider wiping the drive, restoring to the unencrypted drive, then enabling FileVault after booting from the drive.
Apparently there is a very well-known issue concerning the new "Secure Token" which is required for a number of High Sierra system activities -- including working with FileVault2
At least some of my slow startup issues with APFS, where the boot process pauses for an extended period midway through, are apparently related to a bafflingly complex issue that manifested in weird problems trying to change FileVault and Startup Security Settings (to make a very long story short).
...
I only finally managed to recover control over FileVault and Startup Security Utility through complicated command-line work with the sysadminctl program, which I hadn't previously known about.
I just stumbled onto this detailed discussion of the secret secure token FileVault issue in APFS:
Software Tested said:
How to Make FileVault Work Again Without a ‘Secure Token’?
Apple introduced the concept of a Secure Token on top of FileVault with the release of macOS High Sierra. The main purpose is to restrict FileVault encryption conversations and access to only Mac accounts with the appropriate permission.

Here is how the Secure Token feature works:
  • The initial user account you create the first time on a new Mac has a Secure Token.
  • All users with sysadminctl have a Secure Token.
  • Any user account generated with the Users & groups option of the System Preferences has a Secure Token.
  • All Active Directory users do not have a Secure Token.
  • Any user created with dscl doesn’t have a Secure Token.
  • Only users with a Secure Token have permission to activate and deactivate FileVault encryption.
FileVault Problems on Mac

The main challenge, however, is that if no account on your Mac has a Secure Token, it means that the profile cannot enable FileVault.

Some users have complained of experiencing this nightmarish scenario. FileVault operations, such as, migrating, enabling, and adding users, failed on macOS High Sierra and later versions if users did not have a Secure Token enabled for their account.

This issue, amongst many other FileVault problems on Mac, has raised a lot of concern about the value of adding a “Secure Token” on top of FileVault. If you are uninitiated, you are probably asking yourself what does missing a ‘Secure Token’ mean....
#filevault #securetoken #login #boot #encryption #resetFileVaultpassword
 


I did a restore on a 2018 MacBook Pro, and now I'm being asked for a "Disk Password" each time it starts up. I think this has been discussed before, but I couldn't find the post. Does anyone know the best method to eliminate the double password startup?
 


Ric Ford

MacInTouch
I did a restore on a 2018 MacBook Pro, and now I'm being asked for a "Disk Password" each time it starts up. I think this has been discussed before, but I couldn't find the post. Does anyone know the best method to eliminate the double password startup?
I'm not on Mojave at the moment, but you might want to check for something like

System Preferences > Security & Privacy > FileVault > Enable Users... [button]
 


I'm not on Mojave at the moment, but you might want to check for something like
System Preferences > Security & Privacy > FileVault > Enable Users... [button]
Thanks Ric, I forgot about this setting. The FileVault page in System Preferences showed "Some users are not able to unlock the disk." However, after clicking the lock icon and entering my password, the "Enable Users..." button does nothing. Ugh.
 


To follow up again, I thought I would try to just disable and re-enable FileVault. For whatever reason, the "Turn Off FileVault..." button didn't do anything either.
 



Other things to check...
It looks like I do not have a secure token. I tried the following command, shown with result:
Code:
sudo sysadminctl -secureTokenStatus <short name>
Secure token is DISABLED for user <full name>
Using the second link you provided, I then tried the recommended steps to reset the FileVault password to enable the token. Unfortunately, I couldn't run Terminal in Recovery mode. It showed: "Recovery is trying to change system settings. No administrator found".

I suspect this is because FileVault is on with no secure token. The post discussed fixing the token problem when FileVault was off. At this point, I might be in some kind of perverse Apple Catch 22.
 


I was able to create a new user with a secure token by running the setup wizard again using this command in Terminal:
Code:
sudo rm /var/db/.AppleSetupDone
I then restarted and went through the new user setup. When prompted, I didn't sign into iCloud. All I needed to do was enter my disk password, and I now had an account with a secure token. From here, I changed the password of my main account in System Preferences > Users & Groups. (I used the same password I previously had, which is enough to get this procedure to work.) My main account now has a secure token and I only need to login once at startup.
 


I have a new 2019 MacBook Pro, so I set up a bootable backup external disk using Carbon Copy Cloner. Booted to the drive just fine. Created Recovery Partition. Then I turned on FileVault, which said I had to restart, so I did. Now I get "can not verify disk" if I try to boot to the external drive. I can still read the backup drive if I am booted from the internal SSD. Any suggestions?
 


Amazon disclaimer:
As an Amazon Associate I earn from qualifying purchases.

Latest posts