MFA not accepting time codes or back up codes on all accounts after migrating to docker and restoring

For bug reports, provide the steps to reproduce and if possible a minimal demo of the problem: So with the deb installation I had, I had to restart it too often since the service would go down but the vm was live and running. I figured I go with docker for its ability to restart on crash and its OS agnostic. I backed up the old server to AWS S3 and found the machine key. Made a new vm almost the exact same other then ram size. Update & installed everything the same other than this vm I installed docker and extra route rules for ufw with docker. Ran bash workspace-install.sh -ims false -mk key chose docker for install type. Everything came up in docker an I used the same email for admin account. Set up the custom dns an ssl. Then triad to restore right from AWS S3 an it just redirected to the main page. So I reloaded everything an still no files or projects. So I downloaded the back up an restored form the local file. That restore took an I got the restoring portal page. It restored my user account an admin account both work when requesting a new password. Then when it asks for my MFA code it says invalid. So I tried the back up codes an its says those are invalid too. So I switched to my user account, same problem MFA codes or back up codes are invalid. I do have the old server still able to be ran but id really just like to fix this. Then disable MFA, back up and start over. An I’m really good with mySQL and php. So if it’s something I can edit in the database or a command I could run. That be great! Or if I missed a key or something other then the machine key. That’s workable too! Somewhat new to docker but I can get around a bit. Thanks Ace
Community Server/Control Panel version: Current docker images as of time of this post for community version
Type of installation of Workspace (docker, deb/rpm, exe) : Docker
OS: Debian 11
Browser version: current Samsung, Safari and chrome

Hello @MuttAce

It’s a little bit strange. We are going to check described scenario of migration. I will update this thread when we have something to share.

Hello @MuttAce
Sorry for the late reply.
We have reproduced the issue and we added a bug to internal tracksystem (internal number - 59626). We have started working on it.
Thank you for pointing us to this situation!