Cannot enable FileVault (options greyed out) on macOS Catalina Clean install

Question

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?

UPDATE:

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.

ATTEMPTS TO REMEDY AND SOLVE:

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.

Weird!

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.

Answer 1

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.

• https://apple.stackexchange.com/a/313780/5472

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

• https://derflounder.wordpress.com/2019/02/08/unable-to-enable-filevault-on-macos-mojave/ (a much longer workaround that uses the macOS Recovery resetFileVaultpassword tool)
• https://derflounder.wordpress.com/2019/02/10/re-syncing-local-account-passwords-and-secure-token-on-filevault-encrypted-macs-running-macos-mojave/ (workaround if you have a personal recovery key handy)

Answer 2

As you have already got an answer for most of this question, I've got an answer for a smaller part of it:

You were surprised by the fact that you can "dd" a read-only partition and wonder why that is. I need to clarify that when you write "dd", I assume you mean that you've used the dd command to overwrite the drive with zeroes or random data. dd has many other uses, so just to clarify that part.

The reason why it is actually unsurprising is that you have invoked dd to do work on drives in contrast to working on files in a file system:

When you've listed the mounted volumes, you were actually looking at mounted file systems. File systems can easily be mounted read-only and will appear as such. It is at the file system level that this restriction occurs.

However when you're accessing disks directly, you're entirely bypassing any file system - and thus any read-only mount is not restricting you. This means that it is fully possible to overwrite or trash a read-only file systems, and it is also possible to do so while they're mounted - however that can lead to very unfortunate things happening (obviously).