hedrinbc

Ok, great! Thanks again. Unfortunately I tried to fix this quite some time ago but only changed the paths in the middle of the XML and not the ones at the bottom!

@AnotherITGuy Any easy way to check again? Source file on github is updated. https://github.com/benhedrington/hedrington-unraid-docker-templates/tree/main/hedrington-unraid-docker-templates

@AnotherITGuy Thank you so much for your detailed post. There was an attempt some time ago to change the paths and they were updated in part of the XML. Due to your post looking further at the bottom of the XML I realized the non-standard paths were still in a couple variables at the bottom of the file. I believe I pushed this update just now. I will look into your second idea as soon as possible. Again, thank you much and thank you for the actionable input that will make this docker run better for others. Have a good day, -Ben

Please check the host paths called out in your omada-controller docker's settings. I suspect the paths that are entered are not set to writable paths on your system.

This is just the same Omada software running in docker on unraid. Everything the software would do if installed independently on a server. https://www.tp-link.com/us/business-networking/omada-sdn-controller/omada-software-controller/

@OttawaClimber this one might be over my pay grade on the network side but a couple quick thoughts... If DMZ means "facing the open internet" would say that omada controller should not be in that situation. If your APs are on the LAN that is where omada controller should be. I can't imagine a need for it to be anywhere that the APs are not, this is an internal network service. So maybe knowing what the IP addresses of your APs are can clear this up.

@ddewit Please share settings in your docker configuration page for omada-controller. The most common problem is if you did not set up the file paths to match working locations on your system. Many people's setups can be different depending on if they are using on the array, cache, or unassigned drive. Validating whatever is in those path variables are a real storage location on your server would be my number one thought.

Hello @calagan57, in my opinion running your dockers on the cache drive or an unassigned drive is a good practice as it keeps some of the activity off your array that doesn't need redundancy. I don't run the open files plugin, but it does make sense to me that the omada controller is interacting with files and keeping track of wireless clients consistently. By your screenshot it looks like plugin is seeing the mongodb files where it appears the docker is using as its database. I have never had an issue shutting down or restarting my unraid server based on anything hanging up on any of my docker containers including omada. If you are able you could do a test shut down and restart to see if everything cleanly exits. I believe it will based on using this container in many others for years. I hope this is helpful. -Ben

What is in "config"?

@olco Look around these paths... /mnt/user/appdata ... look for a "docker-settings" folder, any "omada-controller" folder. Settings > Docker... will show "Default appdata storage location" see what that says as well.

@LotF and you take a screenshot or tell us where the file paths are pointed on your docker template? I believe there are three paths that all need to be proper file paths on your box.

@ibphantom I don't know your situation but I believe "disks" is likely incorrect. This is a more standard path... /mnt/user/appdata/docker-settings/[app name] The original setting when you pulled down the template included my "extrassd" which was outside my array (unassigned disk) and could only be accessed through the path /mnt/disks/extrassd. It all matters how your system is set up to set paths. If you go into the console can "cd /mnt" "cd user" etc... You can see what are best paths for you.

@ibphantom Please check that all 3 file paths (Host Path 1, 2, 3) map to working shares on your machine. There is a seperate "logs" share name posibly this is set incorrectly. No idea how this would have worked prior without them set to working shares on your machine.

Made update to my github for the template and notified Squid. Change was to add "--ulimit nofile=4096:8192" (no quotes) to the "Extra Parameters:" field you will see when you toggle to "Advanced View" in your omada-controller template. Please get back if any issues arrise, -Ben

I will set the ulimit as @mbentley guides all users of the docker and get the update out today. Here is the before an after on my container ulimits from testing. root@netserve:~# docker container inspect -f "{{.HostConfig.Ulimits}}" omada-controller [] root@netserve:~# docker container inspect -f "{{.HostConfig.Ulimits}}" omada-controller [nofile=4096:8192]