[Help]: Cannot Create New Container

[MachEntertainment]

Controller Version

5.12.7

Describe Your Issue or Question

When attempting to create a new container based off mbentley/omada-controller and starting the container for the first time the container crashes.

Expected Behavior

Docker run should create a working container.

Steps to Reproduce

1. docker pull mbentley/omada-controller
2. docker run -d \ --name omada-controller \ --restart unless-stopped \ --ulimit nofile=4096:8192 \ -p 8088:8088 \ -p 8043:8043 \ -p 8843:8843 \ -p 27001:27001/udp \ -p 29810:29810/udp \ -p 29811-29816:29811-29816 \ -e MANAGE_HTTP_PORT=8088 \ -e MANAGE_HTTPS_PORT=8043 \ -e PGID="508" \ -e PORTAL_HTTP_PORT=8088 \ -e PORTAL_HTTPS_PORT=8843 \ -e PORT_ADOPT_V1=29812 \ -e PORT_APP_DISCOVERY=27001 \ -e PORT_DISCOVERY=29810 \ -e PORT_MANAGER_V1=29811 \ -e PORT_MANAGER_V2=29814 \ -e PORT_TRANSFER_V2=29815 \ -e PORT_RTTY=29816 \ -e PORT_UPGRADE_V1=29813 \ -e PUID="508" \ -e SHOW_SERVER_LOGS=true \ -e SHOW_MONGODB_LOGS=false \ -e SSL_CERT_NAME="tls.crt" \ -e SSL_KEY_NAME="tls.key" \ -e TZ=Etc/UTC \ -v omada-data:/opt/tplink/EAPController/data \ -v omada-logs:/opt/tplink/EAPController/logs \ mbentley/omada-controller:5.12

How You're Launching the Container

docker run -d \
  --name omada-controller \
  --restart unless-stopped \
  --ulimit nofile=4096:8192 \
  -p 8088:8088 \
  -p 8043:8043 \
  -p 8843:8843 \
  -p 27001:27001/udp \
  -p 29810:29810/udp \
  -p 29811-29816:29811-29816 \
  -e MANAGE_HTTP_PORT=8088 \
  -e MANAGE_HTTPS_PORT=8043 \
  -e PGID="508" \
  -e PORTAL_HTTP_PORT=8088 \
  -e PORTAL_HTTPS_PORT=8843 \
  -e PORT_ADOPT_V1=29812 \
  -e PORT_APP_DISCOVERY=27001 \
  -e PORT_DISCOVERY=29810 \
  -e PORT_MANAGER_V1=29811 \
  -e PORT_MANAGER_V2=29814 \
  -e PORT_TRANSFER_V2=29815 \
  -e PORT_RTTY=29816 \
  -e PORT_UPGRADE_V1=29813 \
  -e PUID="508" \
  -e SHOW_SERVER_LOGS=true \
  -e SHOW_MONGODB_LOGS=false \
  -e SSL_CERT_NAME="tls.crt" \
  -e SSL_KEY_NAME="tls.key" \
  -e TZ=Etc/UTC \
  -v omada-data:/opt/tplink/EAPController/data \
  -v omada-logs:/opt/tplink/EAPController/logs \
  mbentley/omada-controller:5.12

Container Logs

INFO: Validating user/group (omada:omada) exists with correct UID/GID (508:508)
INFO: Group (omada) doesn't exist; creating
Cannot open audit interface - aborting.

MongoDB Logs

Not Present

Additional Context

No response

[mbentley]

Could I get some info like docker info and what OS you are running? Seems like a host or container runtime issue where it’s not able to create the group in the entrypoint. I created a new container today in testing so I know it works as of a few hours ago.

[MachEntertainment]

Ubuntu 20.04.6 LTS

Client:
 Version:    24.0.5
 Context:    default
 Debug Mode: false

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 1
 Server Version: 24.0.5
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version:
 runc version:
 init version:
 Security Options:
  apparmor
  seccomp
   Profile: builtin
 Kernel Version: 5.4.0-167-generic
 Operating System: Ubuntu 20.04.6 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 1
 Total Memory: 941.4MiB
 Name: greta
 ID: b96f621f-5a55-460c-9ea0-5bb3db74c757
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: No swap limit support

[mbentley]

Sorry for the delayed response - work has been quite hectic. This looks like a problem that is something at the host OS level that is blocking the operation of creating the user inside the container. Searching for the error Cannot open audit interface - aborting. results in a bit of a variety of possibilities. It could be anything from the kernel, apparmor, etc. Is your system up to date with all of the latest packages and is running the latest kernel (post-reboot after installing a new kernel, if available)?

You can run the container without apparmor to test by adding --security-opt apparmor=unconfined to your run command as that could be a likely culprit. Could be something as simple as an out of date apparmor package too.

[MachEntertainment]

From my research I wasn't able to find a definitive answer and as such I've just reverted the VM to a previous backup.