[Help]: [SOLVED] Having an issue on new install of 5.15.24.18, first boot shows Controller Hostname/IP as my tailscale IP

[harryfine]

Controller Version

5.15.24.18

Describe Your Issue or Question

First time docker user, first time using Omada docker version. Running it on a Synology diskstation using Portainer to set it up.
I did a migrate from my OC200 controller which seemed completely successful.
And now I'm logged in and nervous. Nervous because this is my second run at this, the first time it ended up corrupting the container and I had to start over. When I was reviewing the settings, the setting Controller Hostname/IP has my Tailscale IP for the Synology box. So it's working, but that's obviously an issue. I guess it should say 192.168.1.103 which is my Synology IP.

But I'm afraid to change it, as I changed it last time and ended up with corruption. In fairness, don't know if those two things were connected. I did use the restart delay in the container creation this time as I read something about corruption possibilities on Github.

So, I'm waiting here afraid to make the change, restart and log in. So 2 questions.

1. How did it happen, and;
2. What do I do about it

Expected Behavior

I would have expected that the IP I gave on the source side of the migration, 192.168.1.103 would have been in the Controller Hostname/IP field instead of my Tailscale IP.

Steps to Reproduce

Normal install through Portainer and migration from OC200

How You're Launching the Container

Used Portainer

Container Logs

No error yet so none needed

MongoDB Logs

No error yet so none needed

Additional Context

Appreciate any help. BTW, am I save is I simply backup the two folders, data and logs so that I can start over if it gets corrupted>

[mbentley]

Changing the IP there should certainly not cause database corruption. It's getting that IP by picking one from the host's networks so you can change that, no problem. If you're concerned about corruption, take backups or just configure autobackups anyway because it's the easy and safe thing to do but you can manually take a backup before changing the setting and if somehow if the controller gets messed up, it's an easy restore.

The only things that ought to potentially cause corruption would be the container being stopped suddenly (killed) before MongoDB has a chance to shut down cleanly or actual disk low level file corruption. Anything else would be a bug in the controller software.

[harryfine]

Thanks for the quick reply Matt.

[harryfine]

I am a bit confused about the differences between export data, the automatic scheduled backup and what happens when you migrate from another platform. In other words could I have set up the Docker controller as new and then just imported data exported from the OC 200? Or imported from the extracted nightly backup files?

[mbentley]

Technically, you should be able to take a backup either created manually or through auto backup and restore it, given that it meets the backup and restore requirements, which have changed over a few versions on whether it requires the same major.minor or major.minor.bugfix version. Seems like TP-Link recommends migration on the forums from a few times I have searched when moving from an OC200/300 to a software controller.

[harryfine]

By the way, working great. Fast and everything works. Thanks again.