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.
To make sure I understand - you have one external HD for data, plugged into your new computer, that was previously attached to your OLD computer - and you backed up your old computer + this drive to a second Time Machine drive?
Time Machine is not recognizing the old archive because the new machine is a fresh install. So it made a new backup. The data drive (which you state is being seen as a "new drive") would have been part of that old machine backup - Time Machine should recognize things on a per-computer, not per-drive basis. Unless you tell your new machine to inherit the old backup, the existing backup of your data disk will be ignored as well, and a new backup will be created with that disk as part of your current computer backup.
SSDs are great but the lack of cheap internal storage means more people have to use external disks for data. Cloud isn't a good alternative for everyone. Unfortunately the backup systems designed by Apple are not treating externals as separate backups - they are included as part of the internal mounted disk hierarchy of your computer.
Best Answer
Documenting my own solution here, but would be happy to hear whether others have tried this in different ways. There are just a few steps to consider.
Create a dummy user with admin permissions with home directory on the built-in /Users disk
Name your external volume to something, e.g. Home - it would normally then be mounted on /Volumes/Home
Find the Volume UUID for your external disk using
diskutil list /Volumes/Home, let's say the UUID is XYZNow comes the magic, use the
sudo vifscommand to add a line to your (by default empty) fstab file, the line should look like this:Finally, reboot your machine and you are good to go.
Caveat 1: if your external disk is missing or broken you will not have home directories, so do make a backup!
Caveat 2: if your external disk is missing and you do not have a dummy user (step 1 above) you will not be able to log in at all.
After this you may want to restore a time machine backup. However, Migration Assistant tries to outsmart you and checks the amount of available space for the root directory (which is small) rather than the externally mounted /Users directory. To circumvent this you have to use a two-step process:
Restore user details (accounts) but not their data by de-selecting all the data directories when restoring using Migration Assistant, after doing this you will have re-created users without most of their data files.
Using the command line tool tmutil you can restore without the check:
tmutil restore /Volumes/Backup/Backups.backupdb/PreviousMachine/PreviousDisk/Users/{joe,anne} /Users
(please run man tmutil before trying this and use the correct directory names).