I have an iMac 2017 with a FusionDrive on which FileVault cannot not be enabled. The situation is summed up in this reddit post. The problem boils down to: I have no admin user who has a secure token and it seems like I cannot get one. This can be confirmed by running:

sysadminctl interactive -secureTokenStatus USER_NAME

for every user. It always comes back with

Secure token is DISABLED for user USER_NAME

The first setup from factory settings did not result in a user with a Secure Token, and I tried to:

  • Delete /var/db/.AppleSetupDone to setup a new admin account. Result: A new admin account that slo does not have a token.
  • Reinstall MacOS High Sierra: First created admin user does not have secure token.

It seems that this is either intentional (because of the Fusion Drive?) or a bug in High Sierra. With exactly the same procedure on a Macbook Pro 2017 I get an admin user with a Secure Token and that user can manage FileVault and give secure tokens to other users.

Since I want to use FileVault, I also tried to reformat the main disk with an encrypted file system, reinstalling MacOS and restoring from time machine backup. This worked, FileVault is enabled, but now I have to enter the disk password every time the computer boots (before the login screen). I don't want this, I want to unlock the disk with a user password.

What can I do to get an admin user with a secure token?

  • How did you format the Fusion Drive: APFS or CoreStorage (APFS shouldn't work though without some hacking)? Is your iMac bound to an AD environment? – klanomath Jan 28 '18 at 19:04
  • @klanomath It is a FusionDrive with HFS+. No AD, this is just a normal iMac, bought from Apple store, unpacked, switched on, local admin user created and there we are. – Thomas Jan 28 '18 at 19:09

Just migrated to a new 2018 MacBook Pro, and somehow my original account (an admin user) was created without a secure token during the migration. I even tried creating a new admin user, logging into that user and trying to run sysadminctl -secureTokenOn justin -password - but getting:

2018-07-30 14:17:56.552 sysadminctl[886:18232] Operation is not permitted without secure token unlock.

So then I tried the following providing adminUser and adminPassword flags as my original user justin:

sysadminctl -secureTokenOn justin -password - -adminUser justin -adminPassword -

Enter password for justin :

Enter password for Justin K :

2018-07-30 14:31:05.262 sysadminctl[998:49031] setSecureTokenAuthorizationEnabled error Error Domain=com.apple.OpenDirectory Code=5101 "Authentication server refused operation because the current credentials are not authorized for the requested operation." UserInfo={NSLocalizedDescription=Authentication server refused operation because the current credentials are not authorized for the requested operation., NSLocalizedFailureReason=Authentication server refused operation because the current credentials are not authorized for the requested operation.}

Essentially it seems since non of my users have a secure token, there is no way to grant a secure token. The only downfall is the following:

  • When I cold start the machine I have to enter a disk decryption password, which results in entering my password twice (once for disk decryption and once for the user account).

  • When I try to turn off FileVault by clicking the button nothing happens. The same behavior when clicking the warning button "Some users are not able to unlock the disk [Enable Users...]" nothing happens.

enter image description here

  • 1
    Exactly like my situation. Install in encrypted volume and wait for an update. (see my answer) – Thomas Jul 31 '18 at 18:04
  • Same exact situation here – Alex Weinstein Sep 3 '18 at 13:49
  • 1
    -adminUser -adminPassword did the trick for me! – Will Gordon Nov 17 '18 at 20:09
  • If you dont have any adminUser and adminPassword (or the ones you have are out of sync with APFS), one thing you can do is use Recovery to remove ;SecureToken; from AuthenticationAuthority of all users (if they have it) using dscl, and then use resetFileVaultpassword to get a shiny new SecureToken for yourself. – ssnobody Jun 22 '19 at 23:40

It does seem you've come across a bug, since you should be granted a secure token when…

  1. Secure Token is automatically enabled for the user account created by Apple’s Setup Assistant.
  2. The Setup Assistant-created user account with Secure Token then creates other users via the Users & Groups preference pane in System Preferences. Those accounts get their own Secure Token automatically.

Secure Token and FileVault on Apple File System - Der Flounder

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.

You'll first be prompted to ‘unlock’ Users & Groups preferences by providing administrator credentials to the GUI dialog, then you'll be prompted for the password to the account you wish to give a token to on the CLI.

  • 3
    Granting a secure token with sysadminctl -secureTokenOn yourusername -password - requires a secure token and admin rights, so it cannot be used to bootstrap the first account with a secure token. – Thomas Jan 28 '18 at 18:42
  • 1
    This is the same situation I am in. My main/only user did not have a secure token and creating a new admin user it has no token either. I have no users with secure tokens. I migrated to a new mac using migration assistant (after a failed Time Capsule restore...). The only sign of trouble was at the end of migration I got an error saying "My Name" could not be created. Weird. – Brendan Moore Mar 25 '18 at 21:03

I was able to make this work. First, diagnoze that you have the same issue. Run:

sysadminctl -secureTokenStatus <username>

If it shows "secure token disabled," and you have no other users on the system that have it enabled, you need to go through this dance.

Force the Apple Setup wizard to run on your next install by running:

sudo rm /var/db/.AppleSetupDone

And restart your computer. After the restart finishes, log in as this new admin and create a new admin user; with that user, go to Settings | Security & Privacy | File Vault, and grant your actual user the privileges to unlock the file system. Run this again, it should now say enabled for your actual user:

sysadminctl -secureTokenStatus <username>
  • Anybody tried this? I am little worried about locking myself out. – Justin Sep 4 '18 at 18:02
  • I did this and it did not work, from what I understand only accounts which have a secure token can enable other accounts – amohr Oct 1 '18 at 17:57
  • This definitely can be made to work (at least on 10.13.6). Remove the .AppleSetupDone file reboot and then create a new account (which will have the token). Reboot and log in as that user. You should then be able to enable the old accounts in 'Security and Privacy -> FileVault'. Reboot. The old accounts didn't come up for me immediately, so I'm not sure which of the following triggered it. Maybe logging in as the old account or maybe running 'fdesetup add --usertoadd <acct>' etc afterwards. But it did work. You should then be able to delete the new account. – Andrew Oct 2 '18 at 21:06
  • Didn't work for me in 10.14.5. – sashk May 17 '19 at 16:03

I found myself in this situation. I think this was because I did a clean OS install while FileVault was enabled, so the users weren't migrated.

Accordingly, System Preferences complained "Some users are not able to unlock the disk" but clicking "Enable Users" did nothing, sysadminctl -secureTokenStatus jrc (my main user) said "DISABLED", and sysadminctl -secureTokenOn ... was useless.

A clue came from the fact that fdesetup list -extended reported a "Unknown User" entry. So I solved the problem by creating a new user, changing the UUID of that user to that of the unknown user, and using that new user to fix up my existing user. This required a trip to recovery mode (or single user mode) as the Directory Services store is protected by System Integrity Protection (SIP).

  1. Note the UUID of the unknown user(s) reported from sudo fdesetup list -extended.
  2. In System Preferences > Users & Groups, create a new administrator user (named admin in this example) using the same password as your main user account.
  3. Boot into Recovery Mode and changing the GeneratedUID of the newly created user to match the above UUID. This can be done by opening Utilities menu > Terminal in Recovery Mode, then running dscl -f "/Volumes/Macintosh HD/var/db/dslocal/nodes/Default" localonly -changei /Local/Default/Users/admin GeneratedUID 1 5BBB4CE0-FEC9-4922-A456-5FE00534C065. Substitute your volume name, username, and UUID as appropriate. Everything is case-sensitive.
  4. Reboot normally. sysadminctl -secureTokenStatus admin should now report "ENABLED". (Yay!)
  5. sudo fdesetup add -usertoadd jrc. When prompted, enter the credentials of the above admin user.
  6. Finally, run diskutil apfs updatePreboot / to fix up the boot graphics.

Some related links that I found helpful:

  • 1
    Thanks. I was able to follow your directions, but I had to add one extra step. After reboot, open Directory Utility, find user admin, append into AuthenticationAuthority following: ` ;SecureToken;` (note space prior to the first ;). After doing this, I got "Secure token is ENABLED for user admin". – sashk May 16 '19 at 17:00
  • This is the only solution that worked for me. I had a similar situation after installing Catalina via a bootable backup and was left with the same "Unknown User". Followed these instructions and things worked like a charm. Thanks! – Reda Lemeden Jan 1 '20 at 2:54

In this answer I will outline my resolution of the situation:

  1. I contacted AppleCare and together we tried various things like reinstalling MacOS High Sierra and trying to enable FileVault before the migration of any user data. This is not successful.
  2. The Internet Recovery on this Mac installs MacOS Sierra and in MacOS Sierra FileVault can be enabled. (This clearly indicates a software issue) One can then update to High Sierra and use Migration assistant to get the user data back. The problem is that in this situation only the users that were created in Sierra can unlock the disk, not any users migrated or created after the migration.
  3. AppleCare tried to reproduced my issue on a similar iMac with Fusion Drive and they could not. They offered to look at it in person, but the next store is quite a drive away, so I did not go for this option.
  4. Since rebooting the computer does not happen so often, I settled for myself with the solution to install High Sierra inside a volume that is encrypted from the start. This works, but leads to the situation where you have to enter the decryption password every time the computer boots.
  5. After installing the latest Supplemental Update, the boot loader was probably rewritten or something, I'm now in a situation where after first boot a screen appears in which both users can log in, or I can unlock the disk. It looks like this: enter image description here On this screen both users can log in and thereby unlock the disk. The third option is to unlock the disk upon which another login screen with only the two users is presented.

That means the problem is basically solved, except that there is this strange login item, but well...

I also confirmed with Apple Support that the Secure Token situation described in the question is most likely irrelevant because Secure Tokens pertain to APFS and this is a Mac with a Fusion Drive.


I have the same issue and removing the AppleSetupDone file and rebooting to force the creation of a new admin account doesn't give the new account a token. The only thing that has worked has been backing up the user profile, flattening the machine and doing a new High Sierra install from a bootable USB, not exactly ideal when I've got loads of Macs to upgrade to the 10.13.

You must log in to answer this question.

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