Skip to main content
Question

Encrypted External Backups

  • February 12, 2015
  • 12 replies
  • 15 views
J
Forum|alt.badge.img+13

I'm have an incredibly frustrating problem on my hands and I'm hoping someone has an idea of what direction I should head in. I recently rolled out a large number of Time Machine drives to my company and created a Self Service policy that automatically renames the drive, encrypts it with a randomly generated password from a database, creates a keychain entry for the drive, and sets it as a TimeMachine destination. All is working well in that regard. The problem is that on a seemingly random interval the drive will not unlock for a user via the keychain entry, manual entry, or diskutil cs unlockVolume. If they restart it will unlock automatically with the keychain item no problem until it stops working again.

Here is a snippet of my console log for a failed unlock attempt.

2/12/15 9:09:13.000 AM kernel[0]: CoreStorage: fsck_cs has finished for group "8C309A20-8F6C-4FA0-914C-80DB19FD0192" with status 0x00
2/12/15 9:09:13.000 AM kernel[0]: CoreStorageFamily::unlockVEKs(5F43D311-73D8-469A-B2C7-B7282F304658) VEK unwrap failed. this is normal, except for the root volume.
2/12/15 9:11:37.000 AM kernel[0]: CoreStorage::recover() PV 7029FFDB-BC5A-4CA3-BB18-9FA991562A9C from group "Backup_jesses" (8C309A20-8F6C-4FA0-914C-80DB19FD0192) has been marked missing.
2/12/15 9:11:37.000 AM kernel[0]: CoreStorage: terminating group "Backup_jesses" (8C309A20-8F6C-4FA0-914C-80DB19FD0192)

Here is a successful unlock after reboot

2/12/15 9:34:30.000 AM kernel[0]: CoreStorage: fsck_cs has finished for group "8C309A20-8F6C-4FA0-914C-80DB19FD0192" with status 0x00
2/12/15 9:34:30.000 AM kernel[0]: CoreStorageFamily::unlockVEKs(5F43D311-73D8-469A-B2C7-B7282F304658) VEK unwrap failed. this is normal, except for the root volume.
2/12/15 9:34:30.000 AM kernel[0]: CoreStorageFamily::unlockVEKs(5F43D311-73D8-469A-B2C7-B7282F304658) was successful.
2/12/15 9:34:30.923 AM corestoraged[214]: 0x7fff7a4da300 resumeBackgroundConversion: background conversion started/resumed for lv 60816AC0-B69C-40B3-9369-F37E64EC63C2.
2/12/15 9:34:30.977 AM com.apple.kextd[19]: CoreStorage Volume: unable to get DiskArb info.

Any help would be greatly appreciated as this is becoming a real pain.

    12 replies

    mm2270
    Forum|alt.badge.img+24
    • mm2270
    • Legendary Contributor
    • February 12, 2015

    Quick question - Where is the keychain entry being stored? In the user's login.keychain or a different one?

    J
    Forum|alt.badge.img+13
    • jesseshipley
    • Author
    • Contributor
    • February 12, 2015

    Login keychain. Though again, even when copy pasted using diskutil it won't unlock.

    mm2270
    Forum|alt.badge.img+24
    • mm2270
    • Legendary Contributor
    • February 12, 2015

    OK, well, then I'm not sure what could be happening. I'm not using a setup like this, so I don't have any direct experience. Are you seeing this issue on only one OS version, or on any version of OS X? Just wondering if its some kind of bug in Yosemite for example.

    J
    Forum|alt.badge.img+13
    • jesseshipley
    • Author
    • Contributor
    • February 12, 2015

    Nope, happening on both 10.9 and 10.10

    J
    Forum|alt.badge.img+13
    • jesseshipley
    • Author
    • Contributor
    • February 16, 2015

    Bump on this. Anyone have any ideas?

    davidacland
    Forum|alt.badge.img+18
    • davidacland
    • Valued Contributor
    • February 16, 2015

    I used a similar process in 10.8 for around 200 Macs with no cases of failed mounts. Using: ```
    diskutil coreStorage device -passphrase ...
    ``` and storing the password in the users keychain. Is it the same if you encrypt a disk in the GUI?

    J
    Forum|alt.badge.img+13
    • jesseshipley
    • Author
    • Contributor
    • February 16, 2015

    Yes, the drive just refuses to mount no matter the method I use until the machine is restarted. Then it mounts normally.

    gskibum
    Forum|alt.badge.img+13
    • gskibum
    • Valued Contributor
    • February 24, 2015

    This sounds rather similar to something I encounter from time to time. I rotate encrypted Time Machine drives on several servers. On some servers when I attach a drive I get the password prompt even though the password is already stored in the Keychain. If I hit cancel a few times it will mount on its own anyway. Cleaning up the Keychain of all items for the device then letting the server make a new Keychain item usually clears it up. Even if each Keychain entry has the correct password I still get the prompt.

    So maybe you have extra keychain entries that can be cleaned up?

    J
    Forum|alt.badge.img+13
    • jesseshipley
    • Author
    • Contributor
    • February 24, 2015

    Thanks for the input @gskibum but sadly it is definitely not the keychain. The drive can't be mounted even when there are no entries and I mount the drive through diskutil with a pasted passphrase. I currently have a ticket open with Apple and they have a data capture of what isn't working so I'm hoping the hear back from them this week on it.

    gskibum
    Forum|alt.badge.img+13
    • gskibum
    • Valued Contributor
    • February 25, 2015

    I just had another experience along these same lines. Your ruling out the Keychain seems to be correct.

    When running from a Recovery Partition I was trying to unlock an encrypted drive with Disk Utility. It rejected the password and kept on rejecting the password. Then I realized it had unlocked with the first try and it was lying to me about having entered the password incorrectly.

    Sounds like we may be experiencing different manifestations of the same issue. Hopefully your ticket with Apple will correct my issue as well.

    J
    Forum|alt.badge.img+13
    • jesseshipley
    • Author
    • Contributor
    • February 25, 2015

    I'll keep you posted. Really hope they figure something out.

    J
    Forum|alt.badge.img
    • jsiegers
    • New Contributor
    • June 19, 2017

    We're having the exact same problem with the exact same situation but now on Macs running Mac OS 10.11.6.
    Were you able to solve this?

    Terms & ConditionsCookie settingsAccessibility statement