FileVault and Snow Leopard, after a sparseimage recovery: getting Login window to play nice

[B S Magnet]

It’s late, and I may return to edit this after some rest…

Short story long:

I ran FileVault on a Snow Leopard box for years until the SATA bus on which the FileVault sparseimage had been living started having trouble (the SATA bus, not the drive or volume).

After pulling the drive from the offending SATA bus, I’d decided I’d had enough of FileVault. I cloned all the unlocked sparseimage’s contents — my usual account directory — directly to the /Users/[BSM] directory where said sparseimage lived before. All contents are in place and everything is a cloned match to the contents from within that old sparseimage.

Login window, of course, relies on a setting toggled in the Security prefPane denoting whether the account is using a FileVault sparseimage or not. That flag for my account is still set to FileVault on, even as the account directory no longer is.

My guess is Login window looks to either a plist parameter or something involving, idk, a keychain. Whatever the case, after resolving this SATA bus issue, I’m limited on that volume to logging in to the system as System Admin/root.

This fix is probably really simple, but I can’t brain at this point and figured having a discussion thread for posterity will not only help out now, but also for other people in the future. Cheers.

 

[theMarble]

What about creating a new admin account? Would that not have any FV remains on it?

Another suggestion, while annoying is to try re-enabling FileVault and then disabling it properly.

 

[B S Magnet]

What about creating a new admin account? Would that not have any FV remains on it?

This is going to sound nit-picky: I like all my Macs to have my usual account as user 501. To create and migrate to a new account would complicate this.

Another suggestion, while annoying is to try re-enabling FileVault and then disabling it properly.

Yah. The trouble with this is one cannot make it past the login window, which displays a warning that it’s unable to open the FileVault contents (in this case, because I did away with the sparseimage). When you click “OK”, the login panel shakes the same way it would when a password is incorrect.

Shy of some fresh insight from folks here, what I might end up having to do, in a kind of radical measure, is clone an ancient, but much smaller iteration of the system (still on the original, 2009 OEM 160GB drive) to the internal drive; log in successfully from its temporary home in the (much larger 1TB) internal drive; disable FileVault; and let it move the sparseimage contents to plain accessibility. Then, re-start that Mac in Target Disk mode and clone the current User contents to it from the very recent backups.

The trouble with this, unfortunately, is not knowing the lower-level mechanisms involved with notifying Login window and the system that a user account is or isn’t a FileVault sparseimage, only to find that after all this work, the same problem remains.

The low-level system stuff which transpires during activation/deactivation of FileVault is what I’m here to try to figure out and why I posted this question.

* * *

[A noteworthy reminder, notwithstanding, is it’s probably a good practice to make sure the size of a FileVault sparseimage being dismantled, doubled, isn’t in excess of the hard drive’s capacity – in this case, taking care to keep the account contents’ size to something like less than 400GB, on a 1TB drive. Unfortunately for me, my account directory size is about 600GB.]