Automatically Mount Encrypted Core Storage Volume (10.14.4+)

encryptionfilevaultkeychainmojavemount

Prior to Mojave 10.14.4, macOS would automatically attempt to mount locked Core Storage volumes, and if the necessary password was found in the current user's keychain this would occur automatically.

I've taken advantage of this behaviour until now to allow me to have multiple encrypted volumes that are all mounted automatically by successfully logging in to a user account on my encrypted startup volume.

However, macOS no longer appears to be attempting to mount Core Storage volumes automatically, despite the necessary passwords being in either my user keychain, or the system keychain, forcing me to mount them manually with Disk Utility. This isn't ideal as it ties the volumes to the user account, meaning if I log out the volumes are locked again.

This behaviour differs from encrypted APFS volumes, which mount automatically exactly as before. I know Apple is pushing us to move to APFS, but with still no conversion for AppleRAID (I'm not keen to erase and restore a multiple terabyte volume just to switch), and no use for Time Machine which still doesn't support an APFS backup volume.

Is there a way to restore or securely emulate the previous behaviour such that the volumes are unlocked automatically for all users?

In case the specifics of my setup are useful; my startup volume is an APFS encrypted volume that only my admin account is authorised to unlock, but I use other, standard, user accounts (one for work, one for general use etc.) when actually using my system. I then have an AppleRAID volume of several disks using Core Storage encryption, and a CS encrypted Time Machine disk.

Best Answer

It appears to be a bug that was introduced in macOS 10.14.4. In this discussion some users report that the problem went away by itself, a recent poster found the problem was solved in the latest 10.14.5 beta, and others have resorted to using the third-party app AutoMounter.

In my case, I have a SD drive permanently inserted into the SD card reader. That worked perfectly for years. Since the update it would auto-mount only about 50% of all reboots.

Therefore, it seems your best bet will be to wait for macOS 10.14.5 and report the issue to Apple. Another thing that you could try is to delete and re-enter the passphrase in your Keychain Access.app. Concerning your comment, the necessary steps would be:

Open Keychain Access.app
Find the key by entering the volume's name in the search field
Select & delete the key
Open Disk Utility.app
Mount the volume in question and check the "Save passphrase" box
Go back to Keychain Access.app and locate the volume key again
Drag & drop they volume key into the "System" category in the left sidebar of Keychain Access.app. This step is necessary to enable auto-mounting.

P.S.: I experience another issue, which I suspect is related to this one. Possibly a new UUID is assigned to the drive which could be the reason it is not auto-mounted anymore.

Related Solutions

MacOS – Why does Lion mount a network volume twice at login

AFP mounts are tied to both a path and an authentication.

An exported volume might have multiple paths. For example, an OS X server might export its root, the /Users/ folder, and the /Groups/ folder. Each of these can be mounted separately. In your case, your NAS may be exporting its volume under multiple paths. It might even be exporting the same path multiple times. Check the NAS' settings.

Each AFP mount is tied to a particular authentication (username/password). You can mount the same volume/path multiple times using different authentications. Its possible that the credentials you used in those two different places are subtly different. Depending on the NAS, it might even come down to whether your long username or short username are used. Your NAS might not even require a username (only a password) and might ignore whatever username is given. OS X has no way of knowing that and so two different usernames (long versus short) might produce two different mounts even though they lead to the exact same volume.

Can’t mount (Core Storage) encrypted volume anymore

Not sure if this will be helpful, but I just wrote a script to unlock and mount a core storage Encrypted Disk like yours for myself. I had the same problem where I could get the disk unlocked, but not mounted. I finally realized that I needed a command to mount it after it was unlocked.

In terminal, you first have to unlock the Encrypted Disk and then you can mount it with a separate command. For you, that would look something like this:

diskutil cs unlockVolume E2DB4126-C04C-4AE1-B1AC-CDFF0218D537 -stdinpassphrase

You will be prompted for the password to the Encrypted Disk. After this, your drive will be in an unlocked and unmounted state, so you still need to mount it with this command:

diskutil mount E2DB4126-C04C-4AE1-B1AC-CDFF0218D537

In case you were wondering, E2DB4126-C04C-4AE1-B1AC-CDFF0218D537 is the UUID of the disk you want to mount. I'm no scripting or CoreStorage pro, but your problem seemed similar to mine, so I hope this can help you. I got all this info from the diskutil man page if you run into any problems.

Best Answer

Related Solutions

MacOS – Why does Lion mount a network volume twice at login

Can’t mount (Core Storage) encrypted volume anymore

Related Question