On 8/2/2024 at 10:42 PM, DerTom said:

I have a backup of my server that is some weeks old, but thought that it is good enough to get a running omada-controller (old version). I restored the old files under appdata but even with this it is still the 'new controller' that is showing up with all the devices being managed by another device...

Is there anything else I have to do to get this controller up and running?

Likely too late to help but the same happened to me.  Known issue when updating the container:
https://github.com/mbentley/docker-omada-controller?tab=readme-ov-file#controller-upgrades

 

From that link:

Quote

Before performing and upgrade, I would suggest taking a backup through the controller itself. Controller upgrades are done by stopping the existing container gracefully (see the note below on this topic), removing the existing container, and running a new container with the new version of the controller. This can be done manually, with compose, or with many other 3rd party tools which auto-update containers.

I had to completely rebuild my configuration as the database was corrupted after I just clicked the update button in Unraid.

 

-Rob A.

 

Edited December 8, 20241 yr by ffaat

Today I updated Unraid from 7.0.0 to 7.0.1. Everything seemed fine except I noticed I couldn't bring up the login screen for Omada. I did a bit of digging in the logs and here's what I found:

 

INFO: Validating user/group (omada:omada) exists with correct UID/GID (508:508)
INFO: Group (omada) exists; skipping creation
INFO: User (omada) exists; skipping creation
INFO: Time zone set to 'America/New_York'
INFO: Value of 'manage.http.port' already set to 18088 in omada.properties
INFO: Value of 'manage.https.port' already set to 18043 in omada.properties
INFO: Value of 'portal.http.port' already set to 18088 in omada.properties
INFO: Value of 'portal.https.port' already set to 18843 in omada.properties
INFO: Value of 'port.adopt.v1' already set to 29812 in omada.properties
INFO: Value of 'port.app.discovery' already set to 27001 in omada.properties
INFO: Value of 'port.upgrade.v1' already set to 29813 in omada.properties
INFO: Value of 'port.manager.v1' already set to 29811 in omada.properties
INFO: Value of 'port.manager.v2' already set to 29814 in omada.properties
INFO: Value of 'port.discovery' already set to 29810 in omada.properties
INFO: Value of 'port.transfer.v2' already set to 29815 in omada.properties
INFO: Value of 'port.rtty' already set to 29816 in omada.properties
INFO: Value of 'mongo.external' already set to false in omada.properties
INFO: Value of 'eap.mongod.uri' already set to mongodb://127.0.0.1:27217/omada in omada.properties
INFO: Version check passed; image version (5.15.20.18) >= the last version ran (5.15.20.18); writing image version to last ran file...
INFO: userland/kernel check passed
INFO: output of 'java -version':
openjdk version "17.0.14" 2025-01-21
OpenJDK Runtime Environment (build 17.0.14+7-Ubuntu-120.04)
OpenJDK 64-Bit Server VM (build 17.0.14+7-Ubuntu-120.04, mixed mode, sharing)


##############################################################################
##############################################################################
WARN: autobackup directory not found! Please configure automatic backups!
  For instructions, see https://github.com/mbentley/docker-omada-controller#controller-backups
##############################################################################
##############################################################################

INFO: Starting Omada Controller as user omada
04-05-2025 11:31:07.937 INFO [main] [] c.t.s.o.s.OmadaLinuxMain(): record: start the omada controller
04-05-2025 11:31:07.942 INFO [main] [] c.t.s.o.s.OmadaLinuxMain(): record: set property finished
04-05-2025 11:31:07.963 INFO [main] [] c.t.s.o.s.OmadaLinuxMain(): record: configure log finished
04-05-2025 11:31:07.973 INFO [main] [] c.t.s.o.c.o.a(): Native Image: null
04-05-2025 11:31:07.976 INFO [main] [] c.t.s.o.s.OmadaBootstrap(): record: bootstrap prepare
04-05-2025 11:31:07.980 INFO [main] [] c.t.s.o.s.g.c(): Current dir omadac type is linux
04-05-2025 11:31:07.991 INFO [main] [] c.t.s.o.c.o.c.c(): success to load configuration omada.properties
04-05-2025 11:31:07.991 INFO [main] [] c.t.s.o.c.o.OmadacType(): omadacType: Local Controller
04-05-2025 11:31:07.991 INFO [main] [] c.t.s.o.s.g.c(): Configuration omadacType is linux
04-05-2025 11:31:07.998 INFO [main] [] c.t.s.o.s.g.f(): Start startup message daemon.
04-05-2025 11:31:08.045 INFO [main] [] c.t.s.o.s.OmadaBootstrap(): going to start local mongod.
04-05-2025 11:31:08.047 INFO [main] [] c.t.s.o.m.c.c.d(): FailoverClusterEnable is false
04-05-2025 11:31:22.557 ERROR [main] [] c.t.s.o.s.s.b(): Command execution failed with exit code 14 .
04-05-2025 11:31:22.558 ERROR [main] [] c.t.s.f.c.FacadeUtils(): facadeMsgEnable is not enable, msg: Fail to start mongo DB server with exit code 14
04-05-2025 11:31:22.558 WARN [main] [] c.t.s.o.s.s.b(): Fail to start mongo DB server
04-05-2025 11:31:22.558 WARN [main] [] c.t.s.o.s.s.a(): com.tplink.smb.omada.starter.b.a: Fail to start mongo DB server
com.tplink.smb.omada.starter.b.a: Fail to start mongo DB server
        at com.tplink.smb.omada.starter.server.b.a(SourceFile:201) ~[local-starter-5.15.20.18.jar:5.15.20.18]
        at com.tplink.smb.omada.starter.server.a.e(SourceFile:74) ~[local-starter-5.15.20.18.jar:5.15.20.18]
        at com.tplink.smb.omada.starter.OmadaBootstrap.e(SourceFile:436) ~[local-starter-5.15.20.18.jar:5.15.20.18]
        at com.tplink.smb.omada.starter.OmadaBootstrap.v(SourceFile:625) ~[local-starter-5.15.20.18.jar:5.15.20.18]
        at com.tplink.smb.omada.starter.OmadaBootstrap.a(SourceFile:207) ~[local-starter-5.15.20.18.jar:5.15.20.18]
        at com.tplink.smb.omada.starter.OmadaBootstrap.f(SourceFile:474) ~[local-starter-5.15.20.18.jar:5.15.20.18]
        at com.tplink.smb.omada.starter.OmadaLinuxMain.a(SourceFile:115) ~[local-starter-5.15.20.18.jar:5.15.20.18]
        at com.tplink.smb.omada.starter.OmadaLinuxMain.main(SourceFile:62) ~[local-starter-5.15.20.18.jar:5.15.20.18]

 

So I went in to look at the Mongo log and it seems to be looping through this:

2025-04-05T11:34:26.709-0400 I CONTROL  [main] ***** SERVER RESTARTED *****
2025-04-05T11:34:26.711-0400 I CONTROL  [initandlisten] MongoDB starting : pid=614 port=27017 dbpath=../data/db 64-bit host=nekkidverse
2025-04-05T11:34:26.712-0400 I CONTROL  [initandlisten] db version v3.6.8
2025-04-05T11:34:26.712-0400 I CONTROL  [initandlisten] git version: 8e540c0b6db93ce994cc548f000900bdc740f80a
2025-04-05T11:34:26.712-0400 I CONTROL  [initandlisten] OpenSSL version: OpenSSL 1.1.1f  31 Mar 2020
2025-04-05T11:34:26.712-0400 I CONTROL  [initandlisten] allocator: tcmalloc
2025-04-05T11:34:26.712-0400 I CONTROL  [initandlisten] modules: none
2025-04-05T11:34:26.712-0400 I CONTROL  [initandlisten] build environment:
2025-04-05T11:34:26.712-0400 I CONTROL  [initandlisten]     distarch: x86_64
2025-04-05T11:34:26.712-0400 I CONTROL  [initandlisten]     target_arch: x86_64
2025-04-05T11:34:26.712-0400 I CONTROL  [initandlisten] options: { repair: true, storage: { dbPath: "../data/db" }, systemLog: { destination: "file", logAppend: true, path: "../logs/mongod.log" } }
2025-04-05T11:34:26.714-0400 I -        [initandlisten] Detected data files in ../data/db created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.
2025-04-05T11:34:26.714-0400 I STORAGE  [initandlisten] Detected WT journal files.  Running recovery from last checkpoint.
2025-04-05T11:34:26.714-0400 I STORAGE  [initandlisten] journal to nojournal transition config: create,cache_size=31577M,session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),cache_cursors=false,compatibility=(release="3.0",require_max="3.0"),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),statistics_log=(wait=0),verbose=(recovery_progress),
2025-04-05T11:34:42.414-0400 E STORAGE  [initandlisten] WiredTiger error (22) [1743867282:414503][614:0x14c509ae0ac0], txn-recover: Error parsing 'access_pattern_hint=none,allocation_size=4KB,app_metadata=(formatVersion=1),assert=(commit_timestamp=none,read_timestamp=none),block_allocation=best,block_compressor=snappy,cache_resident=false,checkpoint=(WiredTigerCheckpoint.1=(addr="",order=1,time=1714834913,size=0,write_gen=0)),checkpoint_lsn=(1,0),checksum=on,collator=,columns=,dictionary=0,encryption=(keyid=,name=),format=btree,huffman_key=,huffman_value=,id=2038,ignore_in_memory_cache_size=false,internal_item_max=0,internal_key_max=0,internal_key_truncate=true,internal_page_max=4KB,key_format=q,key_gap=10,leaf_item_max=0,leaf_key_max=0,leaf_page_max=32KB,leaf_value_max=64MB,log=(enabled=true),memory_page_max=10m,os_cache_dirty_max=0,os]cache_max=0,prefix_compression=false,prefix_compression_min=4,stlit_deepen_min_child=0,split_deepen_per_child=0,split_pct=90,value_format=u,version=(major=1,minor=1)' at offset 851: New value starts without a separator: Invalid argument
2025-04-05T11:34:42.414-0400 E STORAGE  [initandlisten] WiredTiger error (22) [1743867282:414735][614:0x14c509ae0ac0], txn-recover: Recovery failed: Invalid argument
2025-04-05T11:34:42.419-0400 F -        [initandlisten] Fatal Assertion 28717 at src/mongo/db/storage/wiredtiger/wiredtiger_kv_engine.cpp 394
2025-04-05T11:34:42.419-0400 F -        [initandlisten] 

***aborting after fassert() failure

I did some searching and found all sorts of different possible workarounds, but none seem to be working for me. Anyone have any ideas? I'm sure I'm missing something.
 

New Omada user looking to setup a controller on my Unraid server. I seem to not be able to get the container working on a custom network. Only Host. Anyone experience this or is it a limitation of some sort? Thanks

For what it's worth after having multiple database corruptions and having to rebuild twice from scratch (even having set up backups) I gave up and spent $90Cdn to buy an OC200 controller.  

 

It's been a much more pleasant experience.

 

Rob A.

 

Hello!

 

sorry  for my bad english...

 

I have omada controller docker work well on UNraid

 

Now I'm  trying to integrate omada to Home assistant. But whend I  configure acces I have some error connection. My user/pwd are ok

 

Is it possible it's a problem with https ? Because when I'm connect via chrome https not working:

 

Any idea? 

 

Thank you! 

 

14 hours ago, stefan416 said:

New Omada user looking to setup a controller on my Unraid server. I seem to not be able to get the container working on a custom network. Only Host. Anyone experience this or is it a limitation of some sort? Thanks

I have been running it fine on a custom network. 

 

What's not working for you? Do you have firewall rules and/or vlans between the two networks? 

15 minutes ago, calagan57 said:

Hello!

 

sorry  for my bad english...

 

I have omada controller docker work well on UNraid

 

Now I'm  trying to integrate omada to Home assistant. But whend I  configure acces I have some error connection. My user/pwd are ok

 

Is it possible it's a problem with https ? Because when I'm connect via chrome https not working:

 

Any idea? 

 

Thank you! 

 

I have the Omada integration within HA working. Have you tried unchecking the SSL checkbox? 

Thank you!

 

I made this :

 

I have tried many choice (with or not https,...)

but I still have error (uncheck box appaer again with the error:

 

But I have an error https when I'm connect to omada with  browser like this:

 

Can I desactivate https on unraid/omada or configure https ? 

 

Thank you!

 

 

 

37 minutes ago, calagan57 said:

Thank you!

 

I made this :

 

I have tried many choice (with or not https,...)

but I still have error (uncheck box appaer again with the error:

 

But I have an error https when I'm connect to omada with  browser like this:

 

Can I desactivate https on unraid/omada or configure https ? 

 

Thank you!

 

 

 

Did you try the entering just the IP address and port number, without http://? 

On 4/25/2025 at 2:38 AM, tvojm100 said:

I have been running it fine on a custom network. 

 

What's not working for you? Do you have firewall rules and/or vlans between the two networks? 

SOrry just saw this now.  Everything seems to install correctly. Cant access the webGUI at all. ERR CONNECTION REFUSED is what I get with a custom network. Host works though. Doesnt seem to map IP and PORT when using custom

 

Edited May 1, 20251 yr by stefan416

One thing I might suggest for the template is to update the docker image that is used to include a tag. I just recently added a major version tag so you can specify mbentley/omada-controller:5 With 6.x coming out soon, at least there is a beta version of 6.x, there will be a manual upgrade step that is needed to bring the base OS image and the MongoDB up to a modern version. I am not going to move latest away from the 5.x branch though because I intend on letting the latest tag die eventually and I do not want to cause everyone's deployment to break if it auto-updates.

On 9/8/2025 at 9:47 AM, mbentley said:

One thing I might suggest for the template is to update the docker image that is used to include a tag. I just recently added a major version tag so you can specify mbentley/omada-controller:5 With 6.x coming out soon, at least there is a beta version of 6.x, there will be a manual upgrade step that is needed to bring the base OS image and the MongoDB up to a modern version. I am not going to move latest away from the 5.x branch though because I intend on letting the latest tag die eventually and I do not want to cause everyone's deployment to break if it auto-updates.

i recently just started using the omada sdn controller on my unraid server and have a question about v6. When i pulled down your docker container and specify the "beta" tag, is it still necessary to upgrade the mongodb version manually, within the container, for everything to work properly? or is the mongodb (version 8 for example), already included by default within the beta version of the container? thanks

21 hours ago, clenga said:

i recently just started using the omada sdn controller on my unraid server and have a question about v6. When i pulled down your docker container and specify the "beta" tag, is it still necessary to upgrade the mongodb version manually, within the container, for everything to work properly? or is the mongodb (version 8 for example), already included by default within the beta version of the container? thanks

If you move from v5 to v6, you will need to perform the database upgrade because starting with the v6 images, I've upgraded the base OS and that includes installing MongoDB from the upstream MongoDB package repositories. The previous version was using 3.6.8 which is way out of support at this point. If you try to run the v6 beta version, the entrypoint will detect that you didn't upgrade MongoDB and it will fail to start the controller.

Hey @mbentley

Thanks for the app. Understood about setting a version to avoid calamity.

Starting about two-ish weeks ago, roughly once every 24 hours, Unraid flags that the Omada container has an update available.

But, on triggering the update, it shows no changes. So the container just stops and restarts.

Looking at the docker hub, all current images are being routinely updated, so at least Unraid isn't jumping at shadows.

But can I check what's going on?

This is seen using either the latest, or v5 tag.

Thanks!

I have build pipelines and security vulnerability scanning that can trigger rebuilds of images. Unlike what most people do where they build an image tag once and never update it, I continually make updates to supported tags. If there have been changes to anything that would cause the build cache to be invalidated, the image would be updated and pushed. If there are fixable vulnerabilities in the underlying base image, it will force a rebuild as well so it’s not version bumps but changes and security patches.

Understood, thanks for explaining.

Glad that you're checking the current builds and updating them as necessary, for sure.

But, like I said, builds are being rebuilt / reuploaded daily with no changes - Unraid shows:

IMAGE ID [5]: Pulling from mbentley/omada-controller.
IMAGE ID [dfd139f7c731]: Already exists.
IMAGE ID [009aee103b7f]: Already exists.
IMAGE ID [40e5127fbc58]: Already exists.
IMAGE ID [53f40ed0171f]: Already exists.
IMAGE ID [4f4fb700ef54]: Already exists.
Status: Downloaded newer image for mbentley/omada-controller:5

TOTAL DATA PULLED: 0 B

So the pipeline is currently triggering... unnecessary? rebuilds to certain images and updates that don't appear meaningful.

Edited September 25, 2025Sep 25 by Raboon

On 9/25/2025 at 3:18 AM, Raboon said:

Understood, thanks for explaining.

Glad that you're checking the current builds and updating them as necessary, for sure.

But, like I said, builds are being rebuilt / reuploaded daily with no changes - Unraid shows:

IMAGE ID [5]: Pulling from mbentley/omada-controller.
IMAGE ID [dfd139f7c731]: Already exists.
IMAGE ID [009aee103b7f]: Already exists.
IMAGE ID [40e5127fbc58]: Already exists.
IMAGE ID [53f40ed0171f]: Already exists.
IMAGE ID [4f4fb700ef54]: Already exists.
Status: Downloaded newer image for mbentley/omada-controller:5

TOTAL DATA PULLED: 0 B

So the pipeline is currently triggering... unnecessary? rebuilds to certain images and updates that don't appear meaningful.

The pipelines do run every morning whether there are changes or not. I'm building about 300 images and a number of them have dependencies that may change over time without there actually being changes that directly trigger a rebuild so that's why they get triggered daily. What happens is that I use buildkit's caching mechanism so if nothing has actually changed, it is able to detect this and nothing actually changes to the underlying image layers. The digests stay the same but the multi-arch manifests are rewritten because the logic to see if an image digest has changed is a huge pain in the ass to capture before hand and then after to determine if I need to have it re-create a manifest and rewriting a manifest should be a harmless thing, especially if the underlying image digests do not change. It sounds like however Unraid is detecting new versions, it's doing so in a weird way. It should be using the actual image digests to see if there is a change and triggering off of that but it must be seeing that something in the manifest itself is different.

Any idea if there is some sort of 3rd party tool, like watchtower, that's embedded in Unraid that's doing this detection? I don't have anything that Unraid and I am not familiar with what it is doing exactly but I do know that this has come up before - which is why I can easily recall what is going on.

*edit: never mind, it is watchtower. Here is what is going on: Watchtower compares the manifest digest (the SHA256 hash of the manifest JSON) rather than just the underlying layer digests. When a registry rewrites a manifest - even without changing any actual image layers - the manifest gets a new digest because:

• Timestamps in the manifest may change (this is the trigger in this case)

• Registry metadata gets updated

• The manifest JSON structure might be reformatted

• Multi-architecture manifests can be rebuilt (this is also happening here)

I have no idea if it is possible to have Unraid switch out the tool being used but something like https://github.com/crazy-max/diun might be a good alternative because I believe it actually detects proper changes in the manifests.

Edited September 26, 2025Sep 26 by mbentley

Thanks for looking into this further.

Understood that you don't have an Unraid system for reference.

To explain, the excerpt I sent was after seeing the notification "there's an update to this container! get it!".

If I click update, I see that result.

So, may I check:

Unraid is looking at your docker hub for your images.

https://hub.docker.com/r/mbentley/omada-controller/tags

From there, for example, tag "5" was last pushed to Docker Hub 9 hours ago.

So is it possible that Unraid's logic is:

Unraid knows when the currently running image was pulled.

When a user clicks on the "Apps" tab in Unraid, Unraid checks the date and time of the latest push in Docker Hub.

If the push is after the pull, Unraid says "new image available!"

I don't believe Unraid is looking at any manifests or digests when it flags an update is available.

Only when the user triggers the update does it then state "this is all the same!"

It'd be good to hear that confirmed by an Unraid guru.

So you're saying Unraid should compare the time, and also the digest of an image to be sure a change in Docker Hub is worth being flagged as an update.

And you're unable to suppress "meaningless" (not being rude) updates to the Docker Hub, because you rebuild everything by default, and can't capture "before this rebuild, this image started like this, after the rebuild, it ended up like this" and compare whether an image has changed meaningfully.

19 hours ago, Raboon said:

Thanks for looking into this further.

Understood that you don't have an Unraid system for reference.

To explain, the excerpt I sent was after seeing the notification "there's an update to this container! get it!".

If I click update, I see that result.

So, may I check:

Unraid is looking at your docker hub for your images.

https://hub.docker.com/r/mbentley/omada-controller/tags

From there, for example, tag "5" was last pushed to Docker Hub 9 hours ago.

So is it possible that Unraid's logic is:

Unraid knows when the currently running image was pulled.

When a user clicks on the "Apps" tab in Unraid, Unraid checks the date and time of the latest push in Docker Hub.

If the push is after the pull, Unraid says "new image available!"

I don't believe Unraid is looking at any manifests or digests when it flags an update is available.

Only when the user triggers the update does it then state "this is all the same!"

It'd be good to hear that confirmed by an Unraid guru.

So you're saying Unraid should compare the time, and also the digest of an image to be sure a change in Docker Hub is worth being flagged as an update.

And you're unable to suppress "meaningless" (not being rude) updates to the Docker Hub, because you rebuild everything by default, and can't capture "before this rebuild, this image started like this, after the rebuild, it ended up like this" and compare whether an image has changed meaningfully.

Ah crap - what we are seeing right now is a bug in buildkit: https://github.com/moby/buildkit/issues/6217
There are different configs being generated due to an issue related to the created_by field of the EXPOSE line which is actually causing the configs to be different so they ARE different. I'll see if I can work around this...

*edit: I've been able to revert back to buildkit 0.23.2 for now which solves the issue

Edited September 27, 2025Sep 27 by mbentley

On 9/24/2025 at 6:12 AM, mbentley said:

If you move from v5 to v6, you will need to perform the database upgrade because starting with the v6 images, I've upgraded the base OS and that includes installing MongoDB from the upstream MongoDB package repositories. The previous version was using 3.6.8 which is way out of support at this point. If you try to run the v6 beta version, the entrypoint will detect that you didn't upgrade MongoDB and it will fail to start the controller.

got it... appreciate the response!! beta 6.0.0.23 has been working fairly well in my environment, just as an FYI... omada still has some work to do though with the adoption process... i first tried putting the controller on a different VLAN from the switch but adoption was buggy as a result.... i could get the adoption to work initially but within 48 hours the controller would no longer "find" the switch and become disconnected... just figured i would post in-case anyone runs into adoption issues... appreciate the work you have done providing this container, as its made it so much easier to host the omada controller...

On 9/27/2025 at 2:16 PM, mbentley said:

Ah crap - what we are seeing right now is a bug in buildkit: https://github.com/moby/buildkit/issues/6217
There are different configs being generated due to an issue related to the created_by field of the EXPOSE line which is actually causing the configs to be different so they ARE different. I'll see if I can work around this...

*edit: I've been able to revert back to buildkit 0.23.2 for now which solves the issue

Pardon for not responding sooner, but thank you very much for figuring this out!

Confirming that I'm now seeing legit updates to the container.

On 9/24/2025 at 6:12 AM, mbentley said:

If you move from v5 to v6, you will need to perform the database upgrade because starting with the v6 images, I've upgraded the base OS and that includes installing MongoDB from the upstream MongoDB package repositories. The previous version was using 3.6.8 which is way out of support at this point. If you try to run the v6 beta version, the entrypoint will detect that you didn't upgrade MongoDB and it will fail to start the controller.

I'm currently on version 5.15.24.19 of the omada-controller container (UnRaid v7.2.2). What is the proper way to upgrade to v6?

cc: @hedrinbc

Edited December 1, 2025Dec 1 by Chahk

You'll need to follow the MongoDB upgrade guide: https://github.com/mbentley/docker-omada-controller/tree/master/mongodb_upgrade. The basic process is stop your existing v5 controller, run the upgrade container, update to the v6 image.

Couldn't you just create a new version 6 container and import a config backup ?

Yes, that is one of the upgrade options listed in the upgrade guide.