We’ve been working on recreating our deployments in the new Otto. 100% of our migrations worked in V3. In the new version, it’s impossible to do a migration when the source and destination have two different encryption passwords.
The error is : “(802): Unable to open file [extended error (20414): Encryption key not correct]”.
We’ve tripled checked all the data entered, even by copy pasting the admin password to enter the files, and copy pasting the encryption passwords to open files on the console. There is no chance either is wrong.
OttoDeploy interface actually shows what could be the problem, but I’m thinking what we see is not what is sent because the json seems fine : in edit default file options, both encryptions are different and correct. No file override is used. Pressing “Review & Deploy” shows a screen where both encryption passwords are the one from the source.
We tried :
-Every deployment that was redone from V3 with every server.
-Blank test file that has “abc” as both the source and destination password : everything works fine
-Blank test file that has “abc” in the source and “def” in the destination : same error.
So it’s not about illegal characters either. Has anyone made this type of deployment successfully in V4?
You diagnosed the problem perfectly! We are just putting the source encryption key in for the destination in OttoDeploy. Congrats on being our first person to use a different encryption key on the source and destination. We’ve got a fix put together for this, it will be going out in our OttoDeploy release tomorrow! Thanks for the great report, and welcome to the community.
Currently, the encryption keys cannot be changed during a data migration. So whatever encryption keys your files are encrypted with before the migration will remain after the migration.
In a future version of OttoFMS, we will add the ability to add / remove / change encryption as part of a migration, but that is not what’s being discussed in this thread
Encryption keys are treating like accounts. By default OttoDeploy will tell the DataMigration tool to treat account and encryption keys like data, so they will be moved into the new clone.
So, regardless of the clones encryption key, if your data source key was “abc” before the migration it will still be “abc” after migrattion.