Not an issue, a query re password protected drives about ejectify-macos

[nielsmouthaan]

I would expect macOS to ask for a password, similar to how it would work when you manually mount the volume. Obviously, this is annoying so you probably want to store the password in the keychain so it won't ask you for a password (anymore).

[jdswinbank]

I have an encrypted drive attached to my Mac, which I use for Time Machine backups. The password is stored in my keychain; when I plug the machine in, it mounts the drive without prompting.

When I put the machine to sleep, Ejectify correctly unmounts it (hooray!).

However, when I wake the machine up, it doesn't get remounted properly. Poking about in Console.app, I see messages like:

default	15:56:18.507698+0200	authd	Succeeded authorizing right 'system.volume.external.mount' by client '/Applications/Ejectify.app' [516] for authorization created by '/Applications/Ejectify.app' [516] (13,0) (engine 663)
default	15:56:18.543385+0200	authd	Succeeded authorizing right 'system.volume.external.mount' by client '/usr/libexec/diskarbitrationd' [88] for authorization created by '/Applications/Ejectify.app' [516] (2,0) (engine 664)
default	15:56:18.768773+0200	kernel	nx_kernel_mount:1134: disk3 initializing cache w/hash_size 8192 and cache size 32768
default	15:56:18.918466+0200	kernel	nx_kernel_mount:1402: disk3 checkpoint search: largest xid 63145, best xid 63145 @ 254
default	15:56:18.919792+0200	kernel	apfs_mount:24470: Failed to unwrap metadata crypto state: 22
default	15:56:18.919871+0200	kernel	apfs_vfsop_mount:1894: apfs_mount failed, err: 1
default	15:56:18.919872+0200	kernel	apfs_vfsop_mount:2180: apfs_vfsop_mount failed, err: 1
default	15:56:19.104686+0200	kernel	spaceman_iterate_free_extents_internal:2942: disk3 nx_unmount detected while processing dev=0 cib=1 out of 30 cibs
default	15:56:29.227507+0200	kernel	nx_kernel_mount:1134: disk3 initializing cache w/hash_size 8192 and cache size 32768
default	15:56:29.364609+0200	kernel	nx_kernel_mount:1402: disk3 checkpoint search: largest xid 63145, best xid 63145 @ 254
default	15:56:29.368252+0200	diskarbitrationd	unable to mount /dev/disk3s2 (status code 0x0000004D).
error	15:56:29.368268+0200	diskarbitrationd	unable to mount /dev/disk3s2 (status code 0x0000004D).

That certainly looks as though Ejectify is trying to mount it, but it's running into some sort of error because it can't “unwrap metadata crypto state”. I'm not prompted for a password or anything like that; the drive simply doesn't get mounted.

If I head over to Disk Utility and click the “mount” button on the relevant volume, it immediately mounts, with no errors appearing in the Console and no password prompt appearing on screen.

I'm not really sure how to debug that — any suggestions much appreciated!

[nielsmouthaan]

Sounds odd indeed. Have you tried verifying & repairing the volume?

[jdswinbank]

Volume verified fine and didn't need repairing.

After a bit more experimenting, I realised I see the same log message (“Failed to unwrap metadata crypto state: 22”) when I tried to use diskutil mount in the terminal, but that diskutil apfs unlockVolume works fine (after prompting for a passphrase). Maybe that implies that there's some other API call needed for an encrypted APFS volume?

[nielsmouthaan]

Duplicate of this planned enhancement issue.