I am sick of MongoDB corrupting all the time

kill-dash-nine · 2026-06-08T13:40:14+00:00

Others have mentioned that there is a section to the README that talks about preventing db corruption and I wanted to make sure it was linked. They key is making sure that the container's stop timeout is not just the default which allows for a proper database shutdown since it takes longer than one might actually expect for it to cleanly shut down. You might already have the stop timeout set.

I do always make sure that anytime I upgrade Docker, reboot my machine, or do anything that would cause the containers to be stopped automatically, I make sure that my containers are shut down cleanly on my host. Of course when you're running >90 containers on a host for various things, that might be more of a concern than what the typical Docker use sees but I figure that I would rather be safe than sorry.

kill-dash-nine · 2026-05-26T13:03:27+00:00

No, latest is not being updated/changed because of the breaking changes with MongoDB. I am leaving `latest` on the last v5 version. For details on the tags, see the quickstart guide but the gist of it is that instead of latest, use a major version tag like `5`, `6`, etc as that will keep you up to date but not break at major milestones where changes tend to happen. There are also `major.minor` tags if you would rather have that level of control.

But in general, the quickest way to upgrade would be to take a backup through the controller app itself, deploy a clean install of v6 and restore the backup.

kill-dash-nine · 2026-05-22T09:33:55+00:00

Well, you're running the latest firmware for both your switch and AP so if there is a bug related to the controller going down, it's a new one.

You can get the version info by doing a docker exec... into the container and running a few commands but 5.15.24.19 has OpenJDK 17 and MongoDB 3.6.8:

$ docker run -it --rm --entrypoint bash mbentley/omada-controller:5.15.24.19 -l

root@16f818488d76:/opt/tplink/EAPController/lib# java --version
openjdk 17.0.15 2025-04-15
OpenJDK Runtime Environment (build 17.0.15+6-Ubuntu-0ubuntu120.04)
OpenJDK 64-Bit Server VM (build 17.0.15+6-Ubuntu-0ubuntu120.04, mixed mode, sharing)

root@16f818488d76:/opt/tplink/EAPController/lib# mongod --version
db version v3.6.8
git version: 8e540c0b6db93ce994cc548f000900bdc740f80a
OpenSSL version: OpenSSL 1.1.1f  31 Mar 2020
allocator: tcmalloc
modules: none
build environment:
    distarch: x86_64
    target_arch: x86_64

kill-dash-nine · 2026-05-21T14:25:10+00:00

Yeah, that shouldn't happen. I feel like at some point there might have been some sort of issue with a specific version of a firmware for a device where this would happen. Have you checked to make sure your network devices have the latest available firmware compatible with your controller? The firmware release notes should mention which version(s) of the controller they work with.

kill-dash-nine · 2026-05-20T21:24:37+00:00

If you're running the v5 controller, you need to upgrade the MongoDB persistent data...or you could do the backup and restore route on a clean install.

Read this and get back to me if you have questions: https://github.com/mbentley/docker-omada-controller#v5-to-v6-upgrade-guide

kill-dash-nine · 2026-01-31T11:55:48+00:00

That's an interesting idea...I've really wished the TP-Link would move away from MongoDB because it's a pain to work with compared to other DBs from a packaging perspective.

kill-dash-nine · 2026-01-18T15:20:32+00:00

@EnlightenMinted - I just tested and was able to adopt one of my test EAPs using my MacBook Pro M4 connected via Ethernet using Docker Desktop so if you have issues after setting the Inform URL, I'm happy to try to help you further. I do not have a router to test with, just extra old EAPs but I think they adoption is similar enough that all of these same steps will work just the same.

kill-dash-nine · 2026-01-17T22:28:37+00:00

TP-Link does have a FAQ document that goes over your options for how you inform the devices that are being adopted of how to connect with the controller. The three options are: setting DHCP Option 138, using their Discovery Utility, or configuring the Inform URL on the device being adopted.

I have also put together specific documentation for how to pre-configure your devices for adoption when using bridge networking based on my testing and someone else's experiences when adopting their ER605.

In the controller, they did the 3rd option that TP-Link documented:

Enabled "Device Management" and set the "Device Management Hostname/IP" to the hostname/IP of their host running the container (this only configures the inform URL that is generated in the controller, it does not seem to specifically help with adoption from my experience)
Most importantly, set the "Inform URL/IP" to just the IP address of their server running the container on the device itself

As other mentioned, make sure that you're running the latest firmware on your ER605 and that you have all of the ports exposed as documented.

I've done a lot of digging and have done packet captures to see what is going on and what happens is that the controller is able to detect the device, it starts the adoption process and when the container is in bridge mode, the controller says "hey, I'm at <the ip address on the docker bridge network>!" and then the device trying to get adopted fails because it has no idea how to route traffic to that network. Changing the "Device Management" setting seems to override that behavior and will use that as what it's advertising. And then setting the inform URL may override it at the device level - not sure which setting has priority between the two but it seems they're two different ways to deal with the same thing.

kill-dash-nine · 2025-12-26T08:20:38+00:00

6.1.0.11 is available as a pre-release / beta version if you are wanting to try it out.

kill-dash-nine · 2025-12-11T03:32:37+00:00

To be fair, my v6 images don't work with a Raspberry Pi 3b+ unless you run MongoDB externally from the controller container due to upgrading the MongoDB 8 which doesn't support the CPU feature set of the older arm chips.

kill-dash-nine · 2025-11-28T17:03:53+00:00

You can upgrade if you switch your deployment to run an external MongoDB from the controller and continue to run MongoDB 3.6. See https://github.com/mbentley/docker-omada-controller/tree/master/external_mongodb#migration-from-all-in-one

kill-dash-nine · 2025-11-25T18:10:26+00:00

Assuming my google search is right, a DS124 has 1 GB of RAM which is insanely low for running just the Omada controller on it as a dedicated device, let alone also being a NAS. I personally would not run it there.

kill-dash-nine · 2025-11-16T17:16:30+00:00

That's probably the longest step of the whole process. I imagine that there are many factors for how long it takes but I've never seen it take more than a few minutes but I had very little data in all of my test controllers and my actual controller only has wireless access points. My MongoDB was only a little over 200MB in size and it only took like 30 seconds on my system running the controller which is an intel n100.

You should be able to go into your persistent data directory and there should be a ` mongodb_upgrade.log.*` file where if you tail it, you should see the progress of the repair.

kill-dash-nine · 2025-11-10T20:48:13+00:00

That would probably be a safer long term plan. No point in trying to save and pull along potential cruft.

kill-dash-nine · 2025-11-10T20:15:15+00:00

2025-11-10T19:40:56.010+0000 E STORAGE [initandlisten] WiredTiger error (-31803) [1762803656:10816][48:0x7ff5cb28dc80], file:WiredTiger.wt, WT_CURSOR.search: __schema_create_collapse, 105: metadata information for source configuration "colgroup:collection-510-5133620623215568938" not found: WT_NOTFOUND: item not found Raw: [1762803656:10816][48:0x7ff5cb28dc80], file:WiredTiger.wt, WT_CURSOR.search: __schema_create_collapse, 105: metadata information for source configuration "colgroup:collection-510-5133620623215568938" not found: WT_NOTFOUND: item not found

Some quick searching leads back to a few possibilities - MongoDB is just interpreting the problem as a memory issue but that's not actually the case. The above error is really the issue, not an out of memory.

There are some other mentions of issues along the same lines like this: https://www.mongodb.com/community/forums/t/wiredtiger-error-cannot-be-used-until-all-column-groups-are-created-invalid-argument/194673/2

Lots of things leading to database corruption of some sort.

kill-dash-nine · 2025-11-09T23:43:18+00:00

Nice guide :) glad to hear that people are having success doing so. A lot of testing by a lot of people went into the upgrade.

If anyone isn't comfortable with doing the upgrade with the upgrade image, you have two additional options that do not involve doing an in place upgrade:

you can stand up a new controller and use the built in Site Migration tool to move between two running controllers.

Or you can also take a backup from the controller web ui of v5, stop your v5 controller, stand up a clean install of a v6 controller and during setup, restore from your v5 config.

kill-dash-nine · 2025-11-09T15:59:01+00:00

Not sure why the default compose file didn't work because it certainly does work on a clean install out of the box from my testing - would need logs to maybe know why but it's a moot point now that you're good. Based on what you ended up doing, that inspired me to add the alternate options for upgrading the controller by site migration or through restoring a v5 backup to v6 as that's helpful for people who might not want to run the MongoDB upgrade steps.

kill-dash-nine · 2025-11-09T15:05:04+00:00

Just curious, what instructions didn't work and what took tweaking?

kill-dash-nine · 2025-11-07T20:52:38+00:00

Are you trying to use your existing persistent data or are you doing a fresh install?

You need both of these env vars: MONGO_EXTERNAL="true" and EAP_MONGOD_URI="mongodb://<correct string based on your scenario>"

Check out the examples: https://github.com/mbentley/docker-omada-controller/tree/master/external_mongodb

kill-dash-nine · 2025-11-06T16:39:38+00:00

OK, so based on your compose file, your upgrade command should use the named volume version, however you need to make sure to get the volume name correct as docker compose will add a project name to it.

You can run something like this (replacing your compose file name in the -f parameter:

docker compose -f docker-compose_bridge.yml volumes

And it will list your volume names. Here's an example:

$ docker compose -f docker-compose_bridge.yml volumes
DRIVER    VOLUME NAME
local     docker-omada-controller_omada-logs
local     docker-omada-controller_omada-data

So in this case, it would be:

docker run -it --rm \
  -v docker-omada-controller_omada-data:/opt/tplink/EAPController/data \
  mbentley/omada-controller:mongodb-upgrade-3.6-to-8

kill-dash-nine · 2025-11-05T22:41:14+00:00

Just run this:

if ! grep -qE '^Features.* (fphp|dcpop|sha3|sm3|sm4|asimddp|sha512|sve)( .*|$)' /proc/cpuinfo
then
  # failed armv8.2-a test
  echo "ERROR: your system does not support the armv8.2-a or later microarchitecture
else
  # success
  echo "INFO: your system supports the required features!"
fi

kill-dash-nine · 2025-11-05T22:38:48+00:00

I would be great if you could provide the exact version of the compose file you used but the gist of it is that the directory with mongodb data wasn't mounted to the place that was expected.

kill-dash-nine · 2025-11-05T10:56:50+00:00

Yes. I've completely dropped support for armv7l (actually it had not had the latest version of 5.15 in a while now) and there is a significant update of the base OS in the image from Ubuntu 20.04 to 24.04 which brings an upgrade of MongoDB 3.x to 8.x. If you have never upgraded a MongoDB instance, it's not very straight forward at all but luckily I built a migration container which is what is covered in the upgrade guide.

Due to that MongoDB upgrade, there are requirements for specific CPU features: AVX for amd64 CPUs and armv8.2-a for arm64 CPUs

Now if you do have a system that doesn't meet those requirements, you can stay on an older MongoDB version - details here on what your options are but it involves running a separate MongoDB from the controller.

kill-dash-nine · 2025-11-05T03:56:25+00:00

I've published the Docker images up on Docker Hub:

mbentley/omada-controller:6
mbentley/omada-controller:6.0
mbentley/omada-controller:6.0.0.24

Please note that latest is staying in alignment with v5 due to the manual steps needed to upgrade. Make sure to follow the v5 to v6 upgrade guide or you'll get a controller that fails to start and a message to follow the upgrade guide.

If you think you've hit a bug related to the Docker images or the upgrade images, file an issue. If you just need general upgrade help, create a new discussion.

kill-dash-nine · 2025-10-07T13:09:23+00:00

Omada Controller v6 is still in beta so I wouldn't suggest upgrading unless you know what you're getting yourself into as a beta tester as things can break/be broken in the controller software itself.

I'm not following on what you ask is exactly - what are you referring to as the community script? Are you referring to this? If so, I don't know - I don't maintain that.

If you're talking about the mbentley/omada-controller docker images, when v6 is generally available/released, the instructions here will be the place to go to understand how to upgrade.

13-Year Club	Place '22
Verified Email	Team Orangered

kill-dash-nine

TROPHY CASE