I’ve migrated servers before and haven’t had an issue, so I’m not sure why I am now. In moving from Ubuntu 18.04 to Ubuntu 18.04, I setup Mailinabox on the new server and ran backup.py on the old server. I downloaded all of the backup files, and I already had my secret_key.txt file. After installing mailinabox on the new server and copying the secret_key.txt file to the new server, I ran the migration functions (Mail-in-a-Box Maintenance Guide)
The following was what I received for an error.
ubuntu@mail:/$ cat /home/test/secret_key.txt
CF5ldaI7q4wJJ4s3G6NtCO43KM8z/i47OtO31quXKGVk6h/7WG3R2asqc0uy+5hO
uKqlpywOJpXBxI5ig+mYzjumKcw8OrwxPKOQ/+X/ZvKn0x+IWOwZAl2TFiGDhqR1
*** pretend this is the rest of the output of the file ***
ubuntu@mail:/$ export PASSPHRASE=$(cat /home/test/secret_key.txt)
ubuntu@mail:/$ sudo -E duplicity --force file:/home/test /home/user-data
gpg: WARNING: unsafe ownership on homedir ‘/home/ubuntu/.gnupg’
Synchronizing remote metadata to local cache…
Copying duplicity-full-signatures.20190623T070004Z.sigtar.gpg to local cache.
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: AES256 encrypted data
gpg: encrypted with 1 passphrase
gpg: decryption failed: Bad session key
gpg: WARNING: unsafe ownership on homedir ‘/home/ubuntu/.gnupg’
===== End GnuPG log =====
I fixed the ownership error by making root the owner, but then I still receive the bad session key error.
@engineertdog
It looks like you possibly skipped a step:
Local backups
If you were using the default backup method, which stores backups on the box itself, then you should have already copied the backup files and encryption key off the old box to somewhere safe. Using any SFTP program like FileZilla (or scp if you know how) copy your backups from wherever you stored them to somewhere on your new machine.
Then restore the files:
export PASSPHRASE=$(cat /path/to/secret_key.txt)
sudo -E duplicity restore --force file:///path/to/backup /home/user-data/
Did you do the export PASSPHRASE step?
I did, I just omitted that in the OP. Here’s a little more clarity.
ubuntu@mail : ~ $ cd /
ubuntu@mail : / $ ls /home/user-data/test
duplicity-full-signatures.20190623T070004Z.sigtar.gpg
duplicity-full.20190623T070004Z.manifest.gpg
duplicity-full.20190623T070004Z.vol1.difftar.gpg
duplicity-inc.20190623T070004Z.to.20190624T070004Z.manifest.gpg
duplicity-inc.20190623T070004Z.to.20190624T070004Z.vol1.difftar.gpg
duplicity-inc.20190624T070004Z.to.20190625T070004Z.manifest.gpg
duplicity-inc.20190624T070004Z.to.20190625T070004Z.vol1.difftar.gpg
duplicity-inc.20190625T070004Z.to.20190626T070004Z.manifest.gpg
duplicity-inc.20190625T070004Z.to.20190626T070004Z.vol1.difftar.gpg
duplicity-inc.20190626T070004Z.to.20190627T070004Z.manifest.gpg
duplicity-inc.20190626T070004Z.to.20190627T070004Z.vol1.difftar.gpg
duplicity-inc.20190627T070004Z.to.20190628T070004Z.manifest.gpg
duplicity-inc.20190627T070004Z.to.20190628T070004Z.vol1.difftar.gpg
duplicity-inc.20190628T070004Z.to.20190629T070004Z.manifest.gpg
duplicity-inc.20190628T070004Z.to.20190629T070004Z.vol1.difftar.gpg
duplicity-inc.20190629T070004Z.to.20190630T070004Z.manifest.gpg
duplicity-inc.20190629T070004Z.to.20190630T070004Z.vol1.difftar.gpg
duplicity-inc.20190630T070004Z.to.20190701T070004Z.manifest.gpg
duplicity-inc.20190630T070004Z.to.20190701T070004Z.vol1.difftar.gpg
duplicity-inc.20190701T070004Z.to.20190702T070004Z.manifest.gpg
duplicity-inc.20190701T070004Z.to.20190702T070004Z.vol1.difftar.gpg
duplicity-inc.20190702T070004Z.to.20190702T181703Z.manifest.gpg
duplicity-inc.20190702T070004Z.to.20190702T181703Z.vol1.difftar.gpg
duplicity-new-signatures.20190623T070004Z.to.20190624T070004Z.sigtar.gpg
duplicity-new-signatures.20190624T070004Z.to.20190625T070004Z.sigtar.gpg
duplicity-new-signatures.20190625T070004Z.to.20190626T070004Z.sigtar.gpg
duplicity-new-signatures.20190626T070004Z.to.20190627T070004Z.sigtar.gpg
duplicity-new-signatures.20190627T070004Z.to.20190628T070004Z.sigtar.gpg
duplicity-new-signatures.20190628T070004Z.to.20190629T070004Z.sigtar.gpg
duplicity-new-signatures.20190629T070004Z.to.20190630T070004Z.sigtar.gpg
duplicity-new-signatures.20190630T070004Z.to.20190701T070004Z.sigtar.gpg
duplicity-new-signatures.20190701T070004Z.to.20190702T070004Z.sigtar.gpg
duplicity-new-signatures.20190702T070004Z.to.20190702T181703Z.sigtar.gpg
secret_key.txt
ubuntu@mail : / $ export PASSPHRASE=$(cat /home/user-data/test/secret_key.txt)
ubuntu@mail : / $ sudo -E duplicity restore --force file:/home/user-data/test /home/user-data/
Synchronizing remote metadata to local cache…
Copying duplicity-full-signatures.20190623T070004Z.sigtar.gpg to local cache.
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: AES256 encrypted data
gpg: encrypted with 1 passphrase
gpg: decryption failed: Bad session key
===== End GnuPG log =====
Is this a new run or the full output of the original run?
In either case … do the following …
Move your backup to A DIFFERENT location. It cannot be in a location that will be overwritten. /home/user-data/test is not going to work. Maybe /home/ubuntu/backup would be a good choice. Place the file secret_key.txt outside of the backup directory, maybe in /home/ubuntu. It would be helpful if you change the ownership of the /home/ubuntu/.gnupg directory back to the user ubuntu. That warning message is a huge clue as to what was going wrong. Then try again.
For the sake of not with more debugging in more posts, I have edited the OP with the new content. I changed .gnupg back to Ubuntu, and moved the files to /home/test which is owned by ubuntu. I still have the same issue.