After migrating my 2018 MacBook Pro from a 2017 MacBook Pro, I found that I could no longer authenticate in the Startup Security Utility on the recovery partition of 10.13 (High Sierra). The 2018 MacBook Pro had FileVault turned on and the 2017 MacBook Pro did not. I investigated some different methods to resolve this, and ultimately did resolve it. I wanted to share how I found the fix and what I learned along the way.
It turns out that AFPS stores authentication credentials in the filesystem. You can see this by running a diskutil command:
MacbookPro:~ tperfitt$ diskutil apfs listusers /
Cryptographic users for disk1s1 (6 found)
|
+– DFB7E1A7-B4CF-410A-9B63-80555D064277
| Type: Local Open Directory User
|
+– 318FBE00-98A2-43B0-B98B-499C349F76CA
| Type: Local Open Directory User
|
+– EB9B296E-4327-4384-B352-D42A303C7B75
| Type: Local Open Directory User
|
+– 8FF42D57-E6D6-454B-A8EE-336C8D15F887
| Type: Local Open Directory User
|
+– 1F46D541-6B44-4CA0-AF01-818ED468AC2F
| Type: Local Open Directory User
|
+– EBC6C064-0000-11AA-AA11-00306543ECAC
Type: Personal Recovery User
Each user on APFS has a UUID that you can find in local Open Directory. For example, my UUID is on my local account is 318FBE00-98A2-43B0-B98B-499C349F76CA, which I found in Directory Utility:
Open Directory keeps these two authentication stores in sync, but when I migrated my data, the APFS credentials did not get updated (different story but Migration Assistant was at 26 hours completed via Thunderbolt 3, and still said it had 26 hours to go–migrating the data on the disk took 2 hours).
Turns out there is a command to force the syncing of the local Open Directory and AFPS credentials store:
diskutil apfs updatepreboot /
However, this didn’t resolve the issue:
It was recommended to run a systemctl command to add manually add the password to AFPS:
sysadminctl interactive -secureTokenOn tperfitt -password –
That command seemed to run successfully yet I could still not authenticate in the Startup Security Utility. When I ran the “diskutil apfs updatepreboot /” command again, I got the same errors.
Noticing the “There are OpenDirectory user(s) but no Recovery user(s)” in the output above, I opened up FileVault pane in Security & Privacy in System Preferences. I didn’t want enable FileVault until I resolved this issue, fearing that I could lock myself out of the filesystem. When I selected the “Allow iCloud to unlock disk”, it didn’t show my user:
I then looked at the “Create a recovery key and do not use my iCloud account” and then cancelled after viewing the key figuring this was a dead end. However, after running “diskutil apfs updatepreboot /” again, the command completed successfully and the Startup Security Utility allow me to authenticate. I also noticed that Personal Recovery User started showing up in “diskutil apfs listusers /”.
Talking to some other admins, it appears what happens is that my local Open Directory users were not “secureToken” users (meaning they didn’t have a secureToken associated with my account in Open Directory). When I created a new user in System Preferences, that new user did not populate the APFS credentials store since the user I used to create the new user was not a secureToken user. Generating a recovery key seemed to have kicked off the process of creating a secureTokens for my existing users, and then I could sync to APFS.
In retrospect, I believe all I needed to do was generate a recovery key by viewing it in the FileVault pane and then running the “diskutil apfs updatepreboot /”.