High Sierra asking for ‘disk password’ and won’t accept any

i Have an APFS volume high Sierra install and for some reason it rebooted/went to sleep over night.

now it’s asking for a ‘disk password‘ and won’t let me in. I converted a filevault 2 volume from HPFS+ to APFS and everything Was working.

I’ve tried the MacOS password, Apple ID Password, FileVault recovery key, and iCloud recovery key and none let me in. What password does it need?

Post not yet marked as solved Up vote post of trekkie Down vote post of trekkie


as an added note, i can boot into recovery, and mount it with my login password. However I can’t change the password (there Was an error...) if I try. First aid runs clean.

I had the same issue upgrading from an encrypted Fusion drive where no disk password or recovery key was accepted. I booted from the recovery partition and was able to unlock the drive with my disk password. It looks like the APFS conversion of encrypted drives is buggy and fails to create a fully working APFS Preboot area. I did most of the diagnostics using diskutil from the cli as Disk Utility was beachballing. If you run diskutil apfs listcryptousers it didn’t seem to have an entry for the disk password. Also whilst you could initiate decryption with diskutil apfs decryptvolume, it would hang at 0%, presumably something missing from the recovery instance.

I restored from backup leaving the drive unencrypted and retried the upgrade and that worked fine.

Same as my situation, but once I've use diskutil apfs decryptVolume to decrypt volume, but after I enter this command, quickly it crashed my macOS 10.13, then I can't boot my mac and also can't read any files anymore, after I boot into Recovery Mode to unlock the volume with my passphrase, all the encrypted files on the volume can be list and not modified, but they can't decrypt by FileVault2 and let me read raw encrypted data, and I use diskutil to check crypto users, that said I'm in decrypting action but paused state of my volume?

Is there have some way to have to continue decrypting in Recovery Mode? In previous coreStorage can be done this things by manual activating corestoraged in terminal to continue encrypting/decrypting, but in this APFS does have any way to migration successful or revert the state?

-bash-3.2# diskutil apfs listCryptoUsers /dev/disk2s1
Cryptographic users (4 found)
+-- EBC6C064-0000-11AA-AA11-00306543ECAC
|  Type: Personal Recovery
+-- EC1C2AD9-B618-4ED6-BD8D-50F361C27507
|  Type: iCloud
+-- 64C0C6EB-0000-11AA-AA11-00306543ECAC
|  Type: iCloud Recovery
+-- EFBB60F6-DD62-4520-9CBB-D82A9BEE35B9
|  Type: Local Open Directory
Background decryption migration (data on disk becoming plaintext) in progress
Migration type 3 (decrypting); state 1 (paused); pause state 0 (unknown)
Migration progress 0.0%
Migration time remaining 60.0 seconds

I, too, had an encrypted APFS volume that could never be unlocked at the pre-boot Disk Password dialogue.

If you wish to regain use of the volume as a startup volume, without restoring from a backup, your best bet may be Recovery OS to decrypt the volume. After decryption begins, progress may be shown by mounting the volume then running:

diskutil apfs listcryptousers …

If a percentage is not shown, wait then re-run the command. Eventually there will be a sixty second estimate. Ignore that, it's inaccurate. Be patient.

After decryption is complete there should be no reliance upon the pre-boot volume.

After install another macOS 10.13 into another disk, and mount original volume, it starts decrypting, but all data can't read either, waiting for it completed

$ diskutil apfs listCryptoUsers /dev/disk1s1
Cryptographic users (4 found)
+-- EBC6C064-0000-11AA-AA11-00306543ECAC
|  Type: Personal Recovery
+-- EC1C2AD9-B618-4ED6-BD8D-50F361C27507
|  Type: iCloud
+-- 64C0C6EB-0000-11AA-AA11-00306543ECAC
|  Type: iCloud Recovery
+-- EFBB60F6-DD62-4520-9CBB-D82A9BEE35B9
|  Type: Local Open Directory
Background decryption migration (data on disk becoming plaintext) in progress
Migration type 3 (decrypting); state 2 (in progress); pause state 0 (unknown)
Migration progress 0.0%
Migration time remaining 60.0 seconds

I had this same issue. Of note, I also converted to APFS and have had a working BootCamp Partition setup with Windows 10. I just installed the Creators Update for Win10 and did some work on the WIndows Side, and then used the Apple BootCamp Control Panel utility to set my Apple partition as the startup drive. That brought me almost immidiately to the prompt for the Disk Password. And nothing I entered was working. Not sure what that password would be, e


I was abel to reboot and hold down Option and then select my Apple Drive and it started up normally. BUT, rebooting again brought me to the same prompt for my Disk Password... I did the same, boot up holding down Option, selected my Apple Drive, and then once I was back at my desktop I went to Systemn Preferences / Startup Disk, and saw that nothing was actually selected there. Once I selected my Apple Drive as the Startup Volume, everything was working normally again.

I had the same problem on my 15" MacBook Pro early 2011 with a FV2 encrypted homemade fusion drive after it slept during install. To make matters worse it wouldn't even boot into the recovery partion (although it would boot into the password recovery utility). I ended up creating a bootable USB drive so I could get to an OS 10.13 terminal window.

After some research and a lot of trial and error I came up with a solution that worked for me:

1. Boot into the OS installer/recovery drive.

2. Open a terminal window. Run diskutil apfs list and find your boot volume

$ diskutil apfs list
APFS Container (1 found)
+-- Container disk2 87F8E3F6-28B8-4A98-847A-28C4370E1133
    APFS Container Reference:    disk2 (Fusion)
    Capacity Ceiling (Size):      754964643840 B (755.0 GB)
    Capacity In Use By Volumes:  480886849536 B (480.9 GB) (63.7% used)
    Capacity Available:          274077794304 B (274.1 GB) (36.3% free)
    +-< Physical Store disk0s2 A070CF3A-AFA8-4AFF-81E3-E77D75FD4685
    |  -----------------------------------------------------------
    |  APFS Physical Store Disk:  disk0s2
    |  Size:                      255716540416 B (255.7 GB)
    +-< Physical Store disk1s2 46B2EB23-79BA-43A0-A99F-D50AAC6C66BF
    |  -----------------------------------------------------------
    |  APFS Physical Store Disk:  disk1s2
    |  Size:                      499248103424 B (499.2 GB)
    +-> Volume disk2s1 6AAC9D56-EC44-38B3-9C50-1D6DA3020377
    |  ---------------------------------------------------
    |  APFS Volume Disk (Role):  disk2s1 (No specific role)
    |  Name:                      Macintosh HD
    |  Mount Point:              /
    |  Capacity Consumed:        461711589376 B (461.7 GB)
    |  Capacity Reserve:          None
    |  Capacity Quota:            None
    |  Encrypted:                Yes (Unlocked)
    +-> Volume disk2s2 FA366E2A-B9CD-4822-AC93-3133635BAFD60
    |  ---------------------------------------------------
    |  APFS Volume Disk (Role):  disk2s2 (Preboot)
    |  Name:                      Preboot
    |  Mount Point:              Not Mounted
    |  Capacity Consumed:        18444288 B (18.4 MB)
    |  Capacity Reserve:          None
    |  Capacity Quota:            None
    |  Encrypted:                No
    +-> Volume disk2s3 0E4E73B-B55D-4DEC-94A1-0A3DD20E73EC
    |  ---------------------------------------------------
    |  APFS Volume Disk (Role):  disk2s3 (Recovery)
    |  Name:                      Recovery
    |  Mount Point:              Not Mounted
    |  Capacity Consumed:        518926336 B (518.9 MB)
    |  Capacity Reserve:          None
    |  Capacity Quota:            None
    |  Encrypted:                No
    +-> Volume disk2s4 38451C7D-33AA-42AE-A951-09CB95D25D2C
        APFS Volume Disk (Role):  disk2s4 (VM)
        Name:                      VM
        Mount Point:              /private/var/vm
        Capacity Consumed:        9842118656 B (9.8 GB)
        Capacity Reserve:          None
        Capacity Quota:            None
        Encrypted:                No

2. Now run diskutil apfs unlockvolume on your boot volume. Authenticate with your usual password

$ diskutil apfs unlockvolume disk2s1

3. Finally, run diskutil apfs updatePreboot on your now unlocked boot volume

$ diskutil apfs updatePreboot disk2s1
Started APFS operation
UpdatePreboot: Commencing operation to update the Preboot Volume for Target Volume disk2s1 Macintosh HD
UpdatePreboot: The Target Volume's OpenDirectory (non-special kind) user count is 1 and the Recovery (any of 3 kinds) user count is 2
UpdatePreboot: No custom Open Directory path given
UpdatePreboot: Using GivenVolumeMountPointOrNilIfNotMounted as MacOSSearchPath
UpdatePreboot: Using MacOSSearchPath's child dslocal path as OpenDirectorySearchPath
UpdatePreboot: MacOS Search Path = (nil=NotMounted) = /
UpdatePreboot: Open Directory Database Search Path = (nil=MacOSSearchPathNotMounted) = /var/db/dslocal/nodes/Default
UpdatePreboot: Successfully opened Open Directory database; setting AuthODNodeOrNil accordingly
UpdatePreboot: Mounting and ensuring as mounted the related Preboot Volume
UpdatePreboot: Preboot Volume = disk2s2 Preboot
UpdatePreboot: Preboot Volume Target Directory = /Volumes/Preboot/6AAC9D56-EC44-38B3-9C50-1D6DA3020377
UpdatePreboot: Considering APFS Crypto User EBC6C064-0000-11AA-AA11-00306543ECAC
UpdatePreboot: This is the Personal Recovery Key for this Volume
UpdatePreboot: Treating this APFS Crypto User as a Personal Recovery Key User
UpdatePreboot: Before rendering EFILoginUserGraphics user resources for type = EFI Login Personal Recovery Key User
UpdatePreboot: After rendering EFILoginUserGraphics Data=(0=Error)=0x7fb910f24b00=0
UpdatePreboot: Successfully added a Personal Recovery Key User to the building dictionary
UpdatePreboot: Successfully processed APFS Volume Crypto User EBC6C064-0000-11AA-AA11-00306543ECAC
UpdatePreboot: Considering APFS Crypto User 57A79AC6-ED71-4DE5-82BE-6B0ECFC5E2C
UpdatePreboot: Defaulting and requiring that this be an Open Directory User
UpdatePreboot: Treating this APFS Crypto User to be, and requiring to match, an Open Directory User
UpdatePreboot: Correlated APFS Volume Crypto User with Open Directory User 57A79AC6-ED71-4DE5-82BE-6B0ECFC5E2C aka "admin"
UpdatePreboot: All required data for this Open Directory user has been obtained
datePreboot: Writing Admin User Info File to path /Volumes/Preboot/6AAC9D56-EC44-38B3-9C50-1D6DA3020377/var/db/AdminUserRecoveryInfo.plist
UpdatePreboot: Successfully wrote Admin User Info File
UpdatePreboot: Checking for existence of Secure Access Token file /var/db/dslocal/nodes/Default/secureaccesstoken.plist
UpdatePreboot: Before copying Secure Access Token file /var/db/dslocal/nodes/Default/secureaccesstoken.plist into directory /Volumes/Preboot/6AAC9D56-EC44-38B3-9C50-1D6DA3020377/var/db
UpdatePreboot: After copying error=(0=success)=0
UpdatePreboot: Unmounting Preboot Volume
UpdatePreboot: Exiting Update Preboot operation with overall error=(0=success)=0

If it ends with an overall error of 0 then that's it. Done! Reboot and be prepared to wait. The first boot took an an inordinate amount of time for me. I was patient and let it do it's thing and it paid off. Finder finally loaded and everything opened up to it's pre-upgrade status.

If you see errors while updatePreboot is considering the Open Directory User ensure your unlocked APFS volume is mounted and readable. It must have access to the local Open Directory search path (/var/db/dslocal/nodes/Default) to build a list of authorized users (AdminUserRecoveryInfo.plist) and an access token (secureaccesstoken.plist) and copy them onto the Preboot volume (/Volumes/Preboot/6AAC9D56-EC44-38B3-9C50-1D6DA3020377/var/db/).

I suspect it is updatePreboot that causes this problem during install. I have a working theory on why it is happening: The OS Installer reboots the system. After restart the CoreStorage volume is unlocked and converted to APFS after which the OS install process begins. When the install is complete, just before the final reboot, updatePreboot is applied to the FV2 boot volume. We have already shown that updatePreboot will fail if the FV2 volume is locked and I'm fairly sure FV2 volumes lock (or have the encryption keys destroyed) at sleep. Following this logic: if the machine sleeps during (or at the end of) the install process but before updatePreboot runs, the Preboot volume will fail to get updated. The machine then reboots: EFI sees the FV2 boot volume so it looks to the (improperly updated) Preboot volume for authorized users. EFI fails to find any admin users since updatePreboot could not read them from Open Directory on the locked boot volume so it displays the generic "disk password" prompt. This is also why neither the recovery key nor an icloud account will unlock the drive.

I hope this helps anyone with this issue. Also, please feel free to correct any glaring mistakes I may have made.


Had the same symptoms, but for when I tried this I found that in my case dslocal is missing from /Volumes/MacHD/var/db. Is all lost then?

Hi Scot!

You've saved me a load of time, this solution worked great! Shouldn't of put my faith in the GM build... it's still riddled with bugs.

Thanks so much!!


Scot, In my case this fails because it is unable to load the open directory with the list of users. Similarly I also tried to “resetpassword” which failed for the same reason - no users found... Any idea?

I just upgraded my 2013 Macbook with the final High Sierra and had this same issue. Your fix worked perfectly for me!

Hello, thank you for the work you‘re doing!

I Experience an issue with the „Treating this APFS Crypto user to be, and requiring to match...“.

Everything before that works fine, the disk is unlocked and mounted, the Error for this processed user was -69569.

Any idea what to do? Would really appreciate help!

Thanks croaker! I am updting my Macbook Pro from Sierra to High Sierra. I left it upgrade overnight and I am stuck at the Disk Password page where none of my passwords works. I had filevault encryption on before the update.

A simplified version of croaker's answer worked for me.

diskutil apfs list

When I run the above command, the output info is similar to croaker's answer, however the disk2 is not mounted. "diskutil apfs unlockvolume disk2s1" failed. So I tried to mount the disk.

diskutil mountDisk /dev/disk2

The mount didn't work, complaining cannot mount stuff. So I check

diskutil list

and realize there are three disks. 0 --> AFS something; 1--> HFS something; 2--> the apfs disk2 that showed up in my "diskutil apfs list" commnad.

I have one SSD. Yet both disk0 and disk2 point to the same physical disk. So I tried to unmount disk0 and mount disk2. The unmount was successful and mount failed again. I update the preboot anyways.

diskutil apfs updatePreboot disk2s1

It ended with error=0, which was very promising. After I reboot and a long wait (5min), I am in the new macOS.

Thanks to coraker for the sharing and analysis. I don't know why in my case it worked without unlocking the volume...

I ran into this last night, while upgrading Sierra to High Sierra on my new MacBook Pro (15", 2017), having never installed a beta. My scenario is slightly different than croaker's in that I have two users (with admin privileges, for what it's worth), and one could not be decrypted with the

command, resulting in errors. Haraguroicha Hsu did give me the idea to decrypt the main volume, which took about 16 hours (100 GB of storage). But after the decryption completed, I restarted, the installation proceeded, and after about 30 minutes High Sierra was installed and running normally. So if running

diskutils apfs updatePreboot <disk-id>

doesn't work, I suggest decrypting the disk:

diskutils apfs decryptVolume <disk-id>

And then (after many, many hours) restarting. Be sure to turn FileVault back on when installation completes.

Similar story with some variation. Two of my laptops upgraded fine. But on the third one download was taking forever (around 15 minutes each on the first two vs. third one was showing an estimate of 10 hours). I suspect this is Apple server overloaded because I did a speed test on my local network and it showed 100Mbs download same as when the first two upgraded in under 15 minutes. So I left this third one downloading overnight and it is now stuck in this situation.

In my case too, from terminal during recovery mode, disk2 was not mounted. But "diskutil apfs unlockvolume disk2s1" succeeded but it mounted it to "/Volumes/Macintosh HD" and not to "/".

I then tried "diskutil apfs updatePreboot disk2s1". It failed with -69569 error because it was unable to open Open Directory database from: "/Volumes/Macintosh HD/var/db/dslocal/nodes/Default". The path "/var/db/dslocal/nodes/Default" does it exist. Tried running some "diskutil unmountDisk" commands on disk0, disk1 and disk2 but they all failed. Debating if I should make a symbolic link. May also try recovery USB to boot into it to see if it changes anything. Not sure how unencryptvolume (and long wait) will help here as the issue seems to be a mounting problem.

Anyone else have any other thoughts to get out of this situation please let me know.