I just did a clean install off off my MacBook Pro by dd'ing the hard drive, and then installing macOS Catalina from a bootable USB. I formatted the internal ssd using apple filesystem and installed successfully. Now, when trying to enable FileVault via System Preferences>Security & Privacy>FileVault>Turn on FileVault, I get a pop up with both the "Set up my iCloud account to reset my password" and "Create a recovery key and do not use my iCloud account" options greyed out. The "Back" and "Continue" buttons are also greyed out. The only button that is not greyed out is the "Cancel" button. So essentially, I can not enable FileVault via the system preferences pane. See screenshot below.

What in the world is happening, and how do I fix this so that I can enable fileVault via the system preferences pane again?

Cannot Enable FileVault from System Preferences macOS Catalina


Hardware Info:

The model of mac is macbook pro 11,3 15" 2014. OS is **MacOS Catalina 10.15.7.

The internal ssd is the one that came with the macbook pro, and is unmodified.

The SSD is formatted with a GUID partion map and an APFS filesystem.

Other hardware notes:

I bought a second official OEM Apple Samsung SSD on ebay of the exact same type with the exact same model number. Installed it, along with a new mac os, and the same problem occurred on a completely different OEM ssd.


So far, here are the things that I have done and the outcomes from them:

  1. I have tried enabling it throught the command line and according to the command line utility, it succusfully encrypts itself.

    • outcome is that even thought the command line utility says it is encrypted, system preferences stays the same, and does NOT acknowledge any sort of encryption.
  2. Clean installed MacOS Catalina from a bootable catalina usb drive AFTER formatting my mac drive with disk utility.

    • outcome is that the exact same problem occurred. Nothing has changed.
  3. Clean installed MacOS Catalina from a bootable usb drive AFTER dd'ing the entire drive from the terminal in the macos bootable usb.

    • outcome is that the exact same problem occurred. Nothing has changed.
  4. Booted from a "Parted Magic" live usb and used gdisk to erase not only the GPT partition map, but also the MBR (or PMBR) maps. Following this, I also did a secure-erase (after unfreezing the drive from sleep in order to unlock it), with parted magics built in disk erase utility, as well as another erase of the gpt and pmbr partition maps using parted magics built in disk erase utility.

    • outcome was a zeroed intenal mac ssd.
  5. Afterwords, I once again, booted up a mac os bootable usb drive, formatted it with disk utility (GPT partiton map w/ apple filesystem), did a clean install of MacOS again from usb.

    • outcome is that same problem occured.
  6. Did steps 1-5 using MacOS internet recovery instead of using a bootable usb.

    • outcome is that the same problem occured in all cases
  7. Removed original mac ssd, and installed 2nd OEM mac ssd purchased from ebay. Then did a clean install from internet recovery.

    • Outcome, is that the same problem occured.
  8. Before and after steps 1-7, I ran apple hardware test both from the internal drive, as well as the internet hardware test.

    • Outcome, is that no hardware was considered faulty, and all hardware was properly working.
  9. FIXED BUT NOT SOLVED: After doing a final clean install, with internet recovery on the new sdd, I once again tried encrypting from the command line utility. Before the command line utility could start actually encrypting itself, I once again booted from internet recovery, dd'd the drive, and again did a clean install.

    • outcome, the issue has resolved itself in the oddist way. After zeroing the disk before the command line utility could finish encrypting the drive, and then doing a clean install from internet recovery, the problem no longer appeared.

Special notes/hints that could possibly identify the problem:

  1. the only real thing that I can think of that could have somehow caused this is that one time when in was in the mac os recovery drive using the terminal, i accidentally DD's (using /dev/zero) one of the supposedly read-only memory partitions (I believe those partions start at /dev/disk3 or /dev/disk4 and go to /dev/disk13 or higher, depending on the os of the recovery partition you loaded).

As far as I can remember, I have never been able to modify those extra ramdisk partitions that appear in the mac os recovery volume (or internet recovery/bootable usb for that matter), and they have always appeared as read only.

So how I was able to successufully DD one of those partitions (on accident of course) is beyond me.

This is the only possible info that I can imagine might somehow be the culprit into affecting multiple clean installs accross multiple hard drives, by preventing the system preferences panel from enabling filevault.


SUMMARY & FINAL STATEMENT: I suggest leaving this post up because it is definitely different than any other post when you get into specifics, as well as the fact that this occured on two different hard drives. Which tells me its some sort of hardware issue, or possibly, a rootkit, or some sort of other billion dollar virus. But most likely some odd hardware problem that is undetected by apple.

DONT DELETE THIS, IT STILL NEEDS A PROPER SOLUTION: Although the issue is no longer happening, I dont believe a proper solution or REASON as to why this occurred, or how it was solved, has been mentioned. So I would definitely recommend this post being left up, because I can almost 100% guarantee that this will happen to me again, as I am the king of having weird mac problems that google and stack forums have absolutely zero mention of.

Any thoughts?

DEC,31,2020 UPDATE:

I once again dd'd my hard drive, as well as did an erase using the hard drive's firmware from Linux using hdparm. Then, I formatted with a bootable MacOS USB installer again, and reinstalled. The same issue appeared.

I tried the suggested commands in the below answers and got the following output: MacBook-Pro:~ dan$ sysadminctl -secureTokenStatus dan sysadminctl[45304:702359] Secure token is ENABLED for user dan sysadminctl interactive -secureTokenStatus dan Secure token is ENABLED for user dan sysadminctl -secureTokenOn dan -password sysadminctl[32917:677328] Operation is not permitted without secure token unlock. MacBook-Pro:~ dan$ sysadminctl -secureTokenOn dan -password - sysadminctl[51227:713574] Operation is not permitted without secure token unlock. MacBook-Pro:~ dan$ sudo sysadminctl -secureTokenOn dan -password - Password: sysadminctl[51218:713260] Operation is not permitted without secure token unlock.

So it seems, that my secure token is enabled, and working, which eliminates the securetoken assumption being the problem.

Finally I ran sudo fdesetup enable -user dan in which Filevault seemed to start encrypting my drive from the terminal. After the encryption was finished, system preferences now looks normal in the security pane stating "FileVault is turned on for the disk "MacHD"". The option to turn off filevault from system preferences, seems fully functional. I have no tried disableing and then reenabling from system preferences again yet.

  • Can you provide more details concerning your disk? Is it GUID, MBR and HFS or AFS? What is the exact model you are using? Was it modified? – n1000 Nov 23 '20 at 7:46
  • I'm tentatively voting to close as a duplicate of this post, since I'm fairly sure that it's the same situation; however, I'm happy to revoke that if it's not the case. By the way, have you tried enabling it through the command line? – JMY1000 Nov 24 '20 at 9:37
  • 1
    You are right @JMY1000 but there are a lot of answers to wade through over there. I’m going to try to make a new answers that combines the best of the other thread and hopefully can be clearer for someone just coming at this from a GUI perspective and not wanting to use the command line. Great question on a very convoluted issue. – bmike Nov 24 '20 at 13:12
  • @JMY1000 Please dont close this. I will update with much more info in a few days when i have free time. – DanRan Nov 24 '20 at 19:50
  • @DanRan 👍 bmike says open, so it shall be – JMY1000 Nov 24 '20 at 21:56

We have to remediate this at work from time to time. This answer linked below is the best for me to use (and the others in the linked question are good, but not great for my needs). With enough care and patience, you can almost always fix this without an “Apple direct” erase install.

To manually grant a secure token, run

sysadminctl -secureTokenOn yourusername -password -

where yourusername is the username of the user you wish to grant a secure token to. Don't forget the hyphen at the end too! Don't use sudo.

This can fail, and then you want to back up and erase and start over being sure you make a good admin account with a throw away admin user. Only when you’re sure your OS install has a secure token, then run Migration Assistant to reload your apps, settings, actual user data and accounts.

When I say “erase and start over” I mean you want to use internet recovery to do the erase and the install so the erase is clean and the installer downloads from Apple direct - completely fresh and updated.

n.b. This is one of the more bizarre and hard things most mac admins do. Super finicky processes and many different scenarios involved. Luckily with T2 chip Macs, this is far less likely to happen. Fingers crossed it can’t happen with the new M1 hardware ever again.

Some of the story on this journey is told well by Rich Trouton

  • Comments are not for extended discussion; this conversation has been moved to chat. – bmike Dec 15 '20 at 23:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .