Not an issue, a query re password protected drives

[popsquirrel]

Downloaded Ejectify as it looks real promising, but before I started using it, I remembered that some of the HDDs I connect to my iMac are password-protected.

I was just looking for reassurance that un-mounting and re-mounting them via Ejectify wouldn't create any problems. (In the past a password-protected HDD that failed to unmount properly got corrupted, so I'm extra careful now!)

Any experience / reassurance you can share?

Thanks.

[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.