ryansch / docker-unifi-rpi

Unifi Controller for Raspberry Pi 3+ and x86

Overview

Docker images for running Ubiquiti's UniFi Controller software.

Supported tags and respective Dockerfile directory links

• 7.4.162, 7.4 (v7.4.162/7.4)
• 7.5.187, 7.5, 7 (v7.5.187/7.5)
• 8.0.7, 8.0, 8, latest (v8.0.7/8.0)

Versions

⚠️ This project is transitioning from MongoDB 2.4 to 3.6. Direct upgrades are not possible! ⚠️

I've added a check in the entrypoint that will prevent the Network Application (controller) from starting if the database files are from mongo 2.4 and need to be upgraded. This will allow you to rollback to the container version you were using without issue. You can then schedule the upgrade when it's convenient.

Upgrade instructions are here: #95

Ubiquiti releases 'unstable', 'testing', and 'stable candidate' versions as part of its beta group release structure. These releases are included here. Only stable releases are tagged with their general version (ex: 5.6 for the 5.6.30 stable release) or with latest.

Supported Architectures

Architecture	Available	Tag
amd64	✅	<version tag>-amd64
arm64v8	✅	<version tag>-arm64v8
arm32v7	❌

Note: arm32v7 is no longer supported due to a lack of upstream support for mongodb <= 3.6 for arm32/armhf

Configuration

As of 7.5.x, this container image supports unifi's standard configuration utilities.

You can supply a system.properties file at /var/lib/unifi/system.properies (in the container) or set any of the following environment variables:

Environment Variable	Description	Default
JVM_INIT_HEAP_SIZE	Initial Java heap size in MiB	None
JVM_MAX_HEAP_SIZE	Maximum Java heap size in MiB	1024
JAVA_ENTROPY_GATHER_DEVICE	Path to entropy gathering device	None
UNIFI_JVM_EXTRA_OPTS	Additional JVM options	$JAVA_OPTS

Additionally, -XX:+UseParallelGC is used by default but can be changed with the unifi property unifi.G1GC.enabled.

Usage

Documentation is in the wiki.

Building

• ./build.sh -v <docker version> -u <unifi version> [-t <additional docker tag> ...]

Example: ./build.sh -v 5.9.29 -u 5.9.29-04b5d20997 -t 5.9 -t 5 -t latest

Publishing

• ./publish.sh -v <docker version> -u <unifi version>

Example: ./publish.sh -v 5.9.29 -u 5.9.29-04b5d20997

Tagging a stable release

• ./tag.sh -v <docker version> -u <unifi version> [-t <additional docker tag> ...]

Example: ./tag.sh -v 5.9.29 -u 5.9.29-04b5d20997 -t 5.9 -t 5 -t latest

docker-unifi-rpi's Issues

move to openjdk-8-jdk from oracle jdk

I and others have recently experienced issues with the oracle jdk on bare metal, and before moving over to your docker setup, I was able to easily make this switch, based on these recommendations:

https://www.reddit.com/r/Ubiquiti/comments/au52p8/a_few_lessons_i_learned_creating_a_raspberry_pi/?st=JSK22ZE2&sh=241980c2

Does this make sense to do?

The second recommendation in that article is to installed the haveged package to help speed things up. Another addition, maybe?

SSL problem

i have this really strange problem where the container ran fine for a couple of days now and out of sudden I got this error code from firefox when trying to connect to the unifi controller:

SSL_ERROR_RX_RECORD_TOO_LONG

After googling around a bit, i got it "solved" by setting up firefox to not use TLS 1.3 (about:config/security.tls.version.max=3) --> not a good solution

googling more i found that after disabling ipv6 on the pi i can now acess the unifi controller without modifying the tls.version.max, but only when using private mode...
I am now completely lost what the causes of the problems are but I figured it may be at least in part a container configuration topic because the container should be able to run fine on a standard raspbian buster install... maybe something wrong with the way certificates are created in the container?

Any hints welcome...

Use another container for mongo

Auto Backup Dir Env Variable in Docker-Compose.yml

Any way to add this as an environment variable per: https://help.ubnt.com/hc/en-us/articles/226218448-UniFi-How-to-Configure-Auto-Backup? Or at least can you provide me with the {data.dir}/backup/autobackup docker path so I can create a bind mount on my host?

[Minor Bug]Java Warnings On Creation

Just a small bit of feedback - I'm seeing some 'Connection refused' error messages for 'java.net.Connect' and a 'Java HotSpot Client' warning, when launching the image on a fresh stretch-lite install (copy from log attached).

The container still starts and seems to run fine, but seems there's some sort of disconnect/timeout problem and/or http>https issue it's encountering during the initial configuration that needs a tweak or poke etc! :-)

Cheers,

Richy.
Java_Warning_Log.txt

"latest" tag not updated

Contrary to the documentation, the latest tag still points to 5.13.32. Thus, using the latest tag it's not possible to update the UniFi instance to the actual latest version.

New Version 5.11.46 available

Just want to notify you that a new version is available. Could you please upload a new image version?

Thanks in advance

Possible Rename (reflecting multiarch support)

Now that multiarch support has landed on master for current stable and future releases, unifi-rpi isn't a great name.

Options:

• unifi
• unifi-multiarch
• your suggestion here

I'll keep pushing to unifi-rpi on docker hub as well as whatever new name we pick.

Add let's encrypt support

5.8.23 & 5.8.24 doesn't work

I had an issue with upgrade from 5.7.23 to 5.8.24, after upgrade I've got empty page in Firefox and HTTP 400 error in Chrome.

The same behavior with clean install of both 5.8.23 & 5.8.24.
I'm tried on Raspberry Pi 2 & 3 with Docker 18.03 and 18.05.

re-adopting after every docker restart?

Hi, just installed your docker on my pi3b+ but I keep having some problems. Every time my pi/docker container restarts (for development reasons) I need to re-adopt all my devices before I can control them. They stay on adopting otherwise after a restart of the container. I need to ssh into my devices to inform them of my new docker controller.
It seems some important settings are not persisted. Any thoughts?

I use a minor adjusted version from your compose file:

version: '2'
services:
  unifi:
    container_name: unifi
    image: ryansch/unifi-rpi:latest
    ports:
      - '3478:3478/udp'
      - '10001:10001/udp'
      - '6789:6789/tcp'
      - '8080:8080/tcp'
      - '8880:8880/tcp'
      - '8443:8443/tcp'
      - '8843:8843/tcp'
    volumes:
      - /opt/unifi/varlib:/var/lib/unifi
      - /opt/unifi/logs1:/usr/lib/unifi/logs
      - /opt/unifi/logs2:/var/log/unifi
      - /opt/unifi/run1:/usr/lib/unifi/run
      - /opt/unifi/run2:/run/unifi
      - /opt/unifi/work:/usr/lib/unifi/work
    restart: on-failure
    environment:
      - TZ=Europe/Amsterdam

Unable to load '/data/system.properties' after building new image and importing

I used build.sh to build v5.14.18-arm32v7 and it appears to complete successfully. After performing "docker save ..." to export the image as a tar, transfer to my pi4 and import using "docker load ...", I get the following message when trying to run it.

Unable to load '/data/system.properties' - /usr/lib/unifi/data/system.properties
(No such file or directory)

I'm running using "docker run -i -t 5.14.18" (I had tagged it with this). I'm probably missing something obvious, but wanted to see if this was a Unifi specific problem and I need to do some manual steps when upgrading.

Having issues with the image tags

I pulled your compose file down directly. No matter what tag I us, even leaving it alone as 'latest' I get a manifest error.

ERROR: no matching manifest for unknown in the manifest list entries

Docker Compose - Missing Folders/Volumes

Firstly my apologies in advance if this is simply user error! :-)

I am having some issues with my ubiquiti switch and/or access point not retaining settings and commands issued via the controller. To help troubleshoot I wanted to format the SD card and rebuild docker/try another controller etc.

Having attempted to obtain the 'backup configuration file' from within the controller, it simply spins and hangs without offering a .unf file to save ((tried a couple of different times with a couple of browsers))

So I thought I would instead grab a copy out of the volume(s) from within the container. Jumping into WinSCP and navigating the paths shown in the docker-compose file and there doesn't appear to be any of the directories listed. Using Putty and cd/ to the directories also seems to show that they are missing.

Screenshot attached:

Could it be a permissions issue and either the docker-compose failed to create them to begin with or perhaps that they are hidden from the 'pi' user?

Appreciate any pointers.

Richy.

Docker not starting

Hi,

I installed the latest controller on RPi3, yet the docker container is not starting. Error below:

pi@raspberrypi:/opt/unifi $ sudo systemctl status unifi.service
● unifi.service - Unifi Controller
Loaded: loaded (/etc/systemd/system/unifi.service; enabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: exit-code) since Tue 2017-09-19 17:52:40 CEST; 3s ago
Process: 15371 ExecStop=/usr/local/bin/docker-compose stop unifi (code=exited, status=203/EXEC)
Process: 15369 ExecStart=/usr/local/bin/docker-compose up --force-recreate unifi (code=exited, status=203/EXEC)
Process: 15366 ExecStartPre=/usr/local/bin/docker-compose rm -f unifi (code=exited, status=203/EXEC)
Process: 15347 ExecStartPre=/usr/local/bin/docker-compose kill unifi (code=exited, status=203/EXEC)
Main PID: 15369 (code=exited, status=203/EXEC)
CPU: 19ms

Sep 19 17:52:40 raspberrypi systemd[1]: unifi.service: Control process exited, code=exited status=203
Sep 19 17:52:40 raspberrypi systemd[1]: unifi.service: Unit entered failed state.
Sep 19 17:52:40 raspberrypi systemd[1]: unifi.service: Failed with result 'exit-code'.

Can you kindly advise?

Thanks!

unifi standard_init_linux.go:207: exec user process caused "exec format error"

Running inside a docker container with BalenaOS on a RaspberryPi B+ it refuses to start responding with

unifi standard_init_linux.go:207: exec user process caused "exec format error"

followed by

Service exited 'unifi sha256:[long string]

It then restarts.
The logs contain no other information. Please direct me to anywhere I could get more detailed logs so I can figure this out.

Host networking: Add comment about firewall ports

I see you're using host networking in your docker-compose file. Can you update the README.md to include some text about opening the necessary ports on your device's firewall? It may not be obvious to new users that these ports need to be opened. For example, maybe add a step 5 here.

1. mkdir unifi && cd unifi
2. curl -O https://raw.githubusercontent.com/ryansch/docker-unifi-rpi/master/docker-compose.yml
3. (Optional) Edit docker-compose.yml to point to a different tag if you don't want latest.
4. sudo docker-compose up -d
5. (Optional) If you're running a firewall (e.g., ufw, iptables, etc...) on your Docker host, open the following ports: 8080/tcp 8443/tcp 8843/tcp 8880/tcp 3478/udp

In contrast, I have been using your container (awesome, btw!) with the default bridge networking, so I have to specify the ports I want to expose, but Docker takes care of all the firewall stuff for me.

version: '3'
services:
  unifi:
    container_name: unifi
    image: ryansch/unifi-rpi:5.12.66
    restart: unless-stopped
    networks:
      - unifi
    ports:
      - '8080:8080/tcp'  #Device and controller communication
      - '8443:8443/tcp'  #Web GUI
      - '8843:8843/tcp'  #HTTPS portal redirect
      - '8880:8880/tcp'  #HTTP portal redirect
      - '3478:3478/udp'  #STUN
    volumes:
      - 'unifi_config:/var/lib/unifi'

networks:
  unifi:

volumes:
  unifi_config:
    driver: local

Imported backup but can't sign in

Hello Ryan, first let me say: thanks for your work on this docker solution.

I'm coming from another setup, also on a Pi, but not in docker. I have exported my config and then imported into the new setup that runs on your docker solution.
But now I can't sign in. I'm getting the form, but my old credentials don't work.

Login error. Invalid username and/or password.

Also can't get a reset via email. The mail isn't sent. Maybe because smtp setting is incorrect.

Any idea on how I can fix this? I would either need to fix the smtp setting, or reset the account manually. I've found solutions to 'reset' the password in the mongo database, but I'm not sure if that's possible via docker.

I know a bit of docker, but I don't know where to find the local folders the volumes are mapped to.

Use Github Actions to test/build

Credentials Invalid

Running into an ongoing issue here. Seems like every couple days UniFi will stop accepting my credentials. For a little while I can still access via Cloud but not local. I can even create a new user and or reset existing users passwords. However, credentials still do not work. I can rebuild the container and restore the config and all will be good for a while. Can’t see anything apparent in the logs and haven’t seen anything out of the ordinary. Any ideas?

Issue with Updating to newer version

I have a pi3 running v5.6.22, but when I run the command to pull the 5.6.29 I see the files being pulled onto the Pi, but the newer version is not activated - I still see 5.6.22 in the web GUI.

Command I am using is "docker pull ryansch/unifi-rpi:5.6.29"
Also tried with :latest for the version number.
I'm not really familiar with using docker so I may be doing something completely wrong!
Bill.

cannot login after migration new sdcard rpi3b+

Hi, I just installed a new sd in my raspberry (3B+) and tried to restore my unifi installation. I backed up my opt/ folder and restored in on the new sd card. I created new images and containers for all my running docker applications. Unfortunately I cannot login to unifi, I get a:

Login error
Invalid username and/or password.

My compose file looks like this:

version: '2.1'
services:
  unifi:
    container_name: unifi
    image: ryansch/unifi-rpi:latest
    network_mode: "host"
    ports:
      - '3478:3478/udp'
      - '10001:10001/udp'
      - '6789:6789/tcp'
      - '8080:8080/tcp'
      - '8880:8880/tcp'
      - '8443:8443/tcp'
      - '8843:8843/tcp'
    volumes:
      - /opt/unifi/varlib:/var/lib/unifi
      - /opt/unifi/logs1:/usr/lib/unifi/logs
      - /opt/unifi/logs2:/var/log/unifi
      - /opt/unifi/run1:/usr/lib/unifi/run
      - /opt/unifi/run2:/run/unifi
      - /opt/unifi/work:/usr/lib/unifi/work
    restart: on-failure
    environment:
      - TZ=Europe/Amsterdam

Any ideas why my credentials are rejected? I already tried the default ubnt/ubnt but without luck

Back to older version

A week ago I was running docker-unifi v5.7.23. Yesterday I have upgrade my version to v.5.8.30. Because of some problems with this version, I have tried to go back to v5.7.23. However when I was running v5.7.23 again and I tried to visit unifi in my browser, I get next message:
We do not support upgrading from 5.8.30.
It looks like the docker container see some old data. What can I do?

MongoDB does not start

When I try to start Unfi (via docker-compose) nothing happens. After some investigating I found that MongoDB does not start.

server.log

2020-03-21T06:27:55,832] <localhost-startStop-1> INFO  system - ======================================================================                                                      
[2020-03-21T06:27:55,835] <localhost-startStop-1> INFO  system - UniFi 5.12.35 (build atag_5.12.35_12979 - release/release) is started                                                       
[2020-03-21T06:27:55,835] <localhost-startStop-1> INFO  system - ======================================================================                                                      
[2020-03-21T06:27:55,838] <localhost-startStop-1> INFO  system - BASE dir:/usr/lib/unifi                                                                                                     
[2020-03-21T06:27:56,018] <localhost-startStop-1> INFO  system - Current System IP: 172.22.0.1                                                                                               
[2020-03-21T06:27:56,020] <localhost-startStop-1> INFO  system - Hostname: pifour
[2020-03-21T06:27:57,647] <localhost-startStop-1> INFO  db     - waiting for db connection...
[2020-03-21T06:27:59,488] <db-server> INFO  db     - DbServer stopped
[2020-03-21T06:28:03,598] <db-server> INFO  db     - DbServer stopped
[2020-03-21T06:28:07,709] <db-server> INFO  db     - DbServer stopped
[2020-03-21T06:28:11,821] <db-server> INFO  db     - DbServer stopped
[2020-03-21T06:28:15,931] <db-server> INFO  db     - DbServer stopped
[2020-03-21T06:28:20,046] <db-server> INFO  db     - DbServer stopped
[2020-03-21T06:28:24,152] <db-server> INFO  db     - DbServer stopped
[2020-03-21T06:28:28,261] <db-server> INFO  db     - DbServer stopped
[2020-03-21T06:28:32,368] <db-server> INFO  db     - DbServer stopped
[2020-03-21T06:28:36,472] <db-server> INFO  db     - DbServer stopped
[2020-03-21T06:28:40,580] <db-server> INFO  db     - DbServer stopped

When I exec into the container and try to start MongoDB manually I get:

root@pifour:/var/lib/unifi/logs# mongod --dbpath /var/lib/unifi/db/                            
2020-03-21T06:42:34.312+0000 I CONTROL  [initandlisten] MongoDB starting : pid=1139 port=27017 dbpath=/var/lib/unifi/db/ 64-bit host=pifour
2020-03-21T06:42:34.312+0000 I CONTROL  [initandlisten] db version v3.2.11
2020-03-21T06:42:34.312+0000 I CONTROL  [initandlisten] git version: 009580ad490190ba33d1c6253ebd8d91808923e4
2020-03-21T06:42:34.312+0000 I CONTROL  [initandlisten] OpenSSL version: OpenSSL 1.0.2t  10 Sep 2019                                          
2020-03-21T06:42:34.312+0000 I CONTROL  [initandlisten] allocator: system
2020-03-21T06:42:34.312+0000 I CONTROL  [initandlisten] modules: none                                                                                                                        
2020-03-21T06:42:34.312+0000 I CONTROL  [initandlisten] build environment:
2020-03-21T06:42:34.312+0000 I CONTROL  [initandlisten]     distarch: arm64
2020-03-21T06:42:34.312+0000 I CONTROL  [initandlisten]     target_arch: arm64
2020-03-21T06:42:34.312+0000 I CONTROL  [initandlisten] options: { storage: { dbPath: "/var/lib/unifi/db/" } }
2020-03-21T06:42:34.312+0000 I -        [initandlisten] Assertion failure getrlimit(RLIMIT_NOFILE, &limit) == 0 src/mongo/util/net/listen.cpp 609
2020-03-21T06:42:34.321+0000 I CONTROL  [initandlisten] 
 0x5593bceaf8 0x5593b75b04 0x5593b613b8 0x5593b7d0e0 0x5593b7d1d0 0x5593b7f4d8 0x559314e084 0x55931019a0 0x7f8b188364

Clean shutdown

The Unifi Controller doesn't appear to get shut down cleanly and I'm concerned about database corruption (like happens on the 1st gen cloudkey).

It looks like docker-compose just sends a SIGTERM followed by a SIGKILL 10 seconds later:

$ cat /var/log/syslog

Jan  5 01:57:15 unifi systemd[1]: Stopping Unifi Controller...
Jan  5 01:57:16 unifi docker-compose[6503]: Stopping unifi ...
Jan  5 01:57:26 unifi dockerd[393]: time="2020-01-05T01:57:26.250480054Z" level=info msg="Container 33380a717b98da76c73954c9022a635b6a8897bfec930b6c31c976875b25a402 failed to exit within 10 seconds of signal 15 - using the force"
Jan  5 01:57:26 unifi containerd[390]: time="2020-01-05T01:57:26.656711911Z" level=info msg="shim reaped" id=33380a717b98da76c73954c9022a635b6a8897bfec930b6c31c976875b25a402
Jan  5 01:57:26 unifi dockerd[393]: time="2020-01-05T01:57:26.668748233Z" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Jan  5 01:57:26 unifi systemd[732]: var-lib-docker-containers-33380a717b98da76c73954c9022a635b6a8897bfec930b6c31c976875b25a402-mounts-shm.mount: Succeeded.
Jan  5 01:57:26 unifi systemd[1]: var-lib-docker-containers-33380a717b98da76c73954c9022a635b6a8897bfec930b6c31c976875b25a402-mounts-shm.mount: Succeeded.
Jan  5 01:57:26 unifi systemd[732]: var-lib-docker-overlay2-abd455ad565f14aec98c22906042cb0dcbeb5a3e02de6754169849e78c956605-merged.mount: Succeeded.
Jan  5 01:57:26 unifi systemd[1]: var-lib-docker-overlay2-abd455ad565f14aec98c22906042cb0dcbeb5a3e02de6754169849e78c956605-merged.mount: Succeeded.
Jan  5 01:57:26 unifi docker-compose[6267]: #033[36munifi exited with code 137
Jan  5 01:57:27 unifi docker-compose[6503]: #033[1A#033[2K#015Stopping unifi ... #033[32mdone#033[0m#015#033[1B
Jan  5 01:57:27 unifi docker-compose[6267]: #033[0mGracefully stopping... (press Ctrl+C again to force)
Jan  5 01:57:27 unifi systemd[1]: unifi.service: Succeeded.
Jan  5 01:57:27 unifi systemd[1]: Stopped Unifi Controller.

The upstream unifi init script goes through a multi-phase shutdown process, starting with jsvc, then creating /var/run/unifi/server.stop if jsvc fails, then finally killing ace.jar and telling mongodb to shut down. I've attached unifi.init (extracted from the .deb) since I can't find it anywhere else online.

This project does it a slightly different way:
https://github.com/jacobalberty/unifi-docker#multi-process-container
https://github.com/jacobalberty/unifi-docker/blob/master/docker-entrypoint.sh#L9

Everything does exit cleanly if I run:

docker-compose exec unifi /usr/bin/java -Xmx512M -jar /usr/lib/unifi/lib/ace.jar stop

Port 8080 not available (RPI 3B)

Worked fine until last month.

pi@rpiCloudkey:~/unifi $ docker ps
CONTAINER ID        IMAGE                      COMMAND                  CREATED             STATUS              PORTS               NAMES
24d62ed70723        ryansch/unifi-rpi:latest   "/sbin/tini -g -- /d…"   11 months ago       Up 5 seconds                            unifi
pi@rpiCloudkey:~/unifi $ 

pi@rpiCloudkey:~/unifi $ docker port 24
pi@rpiCloudkey:~/unifi $ 

pi@rpiCloudkey:~/unifi $ docker inspect 24 | grep IP
            "LinkLocalIPv6Address": "",
            "LinkLocalIPv6PrefixLen": 0,
            "SecondaryIPAddresses": null,
            "SecondaryIPv6Addresses": null,
            "GlobalIPv6Address": "",
            "GlobalIPv6PrefixLen": 0,
            "IPAddress": "",
            "IPPrefixLen": 0,
            "IPv6Gateway": "",
                    "IPAMConfig": null,
                    "IPAddress": "",
                    "IPPrefixLen": 0,
                    "IPv6Gateway": "",
                    "GlobalIPv6Address": "",
                    "GlobalIPv6PrefixLen": 0,
pi@rpiCloudkey:~/unifi $ 


pi@rpiCloudkey:~/unifi $ docker logs 24
OpenJDK Client VM warning: You have loaded library /usr/lib/unifi/lib/native/Linux/armv7/libubnt_webrtc_jni.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
org.tuckey.web.filters.urlrewrite.UrlRewriteFilter INFO: destroy called
OpenJDK Client VM warning: You have loaded library /usr/lib/unifi/lib/native/Linux/armv7/libubnt_webrtc_jni.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
org.tuckey.web.filters.urlrewrite.UrlRewriteFilter INFO: destroy called
Exception in thread "Thread-13" org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'requestMappingHandlerMapping' defined in org.springframework.web.servlet.config.annotation.DelegatingWebMvcConfiguration: Initialization of bean failed; nested exception is java.lang.IllegalStateException: BeanFactory not initialized or already closed - call 'refresh' before accessing beans via the ApplicationContext
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:584)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:498)
	at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:320)
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:318)
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:199)
	at org.springframework.beans.factory.config.DependencyDescriptor.resolveCandidate(DependencyDescriptor.java:273)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.addCandidateEntry(DefaultListableBeanFactory.java:1455)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.findAutowireCandidates(DefaultListableBeanFactory.java:1419)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveMultipleBeans(DefaultListableBeanFactory.java:1310)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1197)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1166)
	at org.springframework.beans.factory.support.ConstructorResolver.resolveAutowiredArgument(ConstructorResolver.java:855)
	at org.springframework.beans.factory.support.ConstructorResolver.resolvePreparedArguments(ConstructorResolver.java:802)
	at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:143)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1308)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1143)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:538)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:498)
	at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:320)
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:318)
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:199)
	at org.springframework.beans.factory.config.DependencyDescriptor.resolveCandidate(DependencyDescriptor.java:273)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.addCandidateEntry(DefaultListableBeanFactory.java:1455)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.findAutowireCandidates(DefaultListableBeanFactory.java:1419)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveMultipleBeans(DefaultListableBeanFactory.java:1310)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1197)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1166)
	at org.springframework.beans.factory.support.ConstructorResolver.resolveAutowiredArgument(ConstructorResolver.java:855)
	at org.springframework.beans.factory.support.ConstructorResolver.resolvePreparedArguments(ConstructorResolver.java:802)
	at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:143)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1308)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1143)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:538)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:498)
	at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:320)
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:318)
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:199)
	at org.springframework.context.support.DefaultLifecycleProcessor.getLifecycleBeans(DefaultLifecycleProcessor.java:289)
	at org.springframework.context.support.DefaultLifecycleProcessor.stopBeans(DefaultLifecycleProcessor.java:195)
	at org.springframework.context.support.DefaultLifecycleProcessor.stop(DefaultLifecycleProcessor.java:116)
	at org.springframework.context.support.AbstractApplicationContext.stop(AbstractApplicationContext.java:1331)
	at com.ubnt.service.B.õÒ0000(Unknown Source)
	at com.ubnt.ace.Launcher$2.run(Unknown Source)
Caused by: java.lang.IllegalStateException: BeanFactory not initialized or already closed - call 'refresh' before accessing beans via the ApplicationContext
	at org.springframework.context.support.AbstractRefreshableApplicationContext.getBeanFactory(AbstractRefreshableApplicationContext.java:177)
	at org.springframework.context.support.AbstractApplicationContext.getBeansOfType(AbstractApplicationContext.java:1212)
	at org.springframework.beans.factory.BeanFactoryUtils.beansOfTypeIncludingAncestors(BeanFactoryUtils.java:340)
	at org.springframework.web.servlet.handler.AbstractHandlerMapping.detectMappedInterceptors(AbstractHandlerMapping.java:318)
	at org.springframework.web.servlet.handler.AbstractHandlerMapping.initApplicationContext(AbstractHandlerMapping.java:293)
	at org.springframework.context.support.ApplicationObjectSupport.initApplicationContext(ApplicationObjectSupport.java:124)
	at org.springframework.web.context.support.WebApplicationObjectSupport.initApplicationContext(WebApplicationObjectSupport.java:77)
	at org.springframework.context.support.ApplicationObjectSupport.setApplicationContext(ApplicationObjectSupport.java:78)
	at org.springframework.context.support.ApplicationContextAwareProcessor.invokeAwareInterfaces(ApplicationContextAwareProcessor.java:120)
	at org.springframework.context.support.ApplicationContextAwareProcessor.postProcessBeforeInitialization(ApplicationContextAwareProcessor.java:96)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:419)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1737)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:576)
	... 45 more
OpenJDK Client VM warning: You have loaded library /usr/lib/unifi/lib/native/Linux/armv7/libubnt_webrtc_jni.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
OpenJDK Client VM warning: You have loaded library /usr/lib/unifi/lib/native/Linux/armv7/libubnt_webrtc_jni.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
OpenJDK Client VM warning: You have loaded library /usr/lib/unifi/lib/native/Linux/armv7/libubnt_webrtc_jni.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
OpenJDK Client VM warning: You have loaded library /usr/lib/unifi/lib/native/Linux/armv7/libubnt_webrtc_jni.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
OpenJDK Client VM warning: You have loaded library /usr/lib/unifi/lib/native/Linux/armv7/libubnt_webrtc_jni.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
OpenJDK Client VM warning: You have loaded library /usr/lib/unifi/lib/native/Linux/armv7/libubnt_webrtc_jni.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
OpenJDK Client VM warning: You have loaded library /usr/lib/unifi/lib/native/Linux/armv7/libubnt_webrtc_jni.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
OpenJDK Client VM warning: You have loaded library /usr/lib/unifi/lib/native/Linux/armv7/libubnt_webrtc_jni.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
OpenJDK Client VM warning: You have loaded library /usr/lib/unifi/lib/native/Linux/armv7/libubnt_webrtc_jni.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
OpenJDK Client VM warning: You have loaded library /usr/lib/unifi/lib/native/Linux/armv7/libubnt_webrtc_jni.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
OpenJDK Client VM warning: You have loaded library /usr/lib/unifi/lib/native/Linux/armv7/libubnt_webrtc_jni.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
OpenJDK Client VM warning: You have loaded library /usr/lib/unifi/lib/native/Linux/armv7/libubnt_webrtc_jni.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
OpenJDK Client VM warning: You have loaded library /usr/lib/unifi/lib/native/Linux/armv7/libubnt_webrtc_jni.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
OpenJDK Client VM warning: You have loaded library /usr/lib/unifi/lib/native/Linux/armv7/libubnt_webrtc_jni.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
OpenJDK Client VM warning: You have loaded library /usr/lib/unifi/lib/native/Linux/armv7/libubnt_webrtc_jni.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
OpenJDK Client VM warning: You have loaded library /usr/lib/unifi/lib/native/Linux/armv7/libubnt_webrtc_jni.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
OpenJDK Client VM warning: You have loaded library /usr/lib/unifi/lib/native/Linux/armv7/libubnt_webrtc_jni.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
OpenJDK Client VM warning: You have loaded library /usr/lib/unifi/lib/native/Linux/armv7/libubnt_webrtc_jni.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
OpenJDK Client VM warning: You have loaded library /usr/lib/unifi/lib/native/Linux/armv7/libubnt_webrtc_jni.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
OpenJDK Client VM warning: You have loaded library /usr/lib/unifi/lib/native/Linux/armv7/libubnt_webrtc_jni.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
OpenJDK Client VM warning: You have loaded library /usr/lib/unifi/lib/native/Linux/armv7/libubnt_webrtc_jni.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
org.tuckey.web.filters.urlrewrite.UrlRewriteFilter INFO: destroy called
OpenJDK Client VM warning: You have loaded library /usr/lib/unifi/lib/native/Linux/armv7/libubnt_webrtc_jni.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
org.tuckey.web.filters.urlrewrite.UrlRewriteFilter INFO: destroy called
OpenJDK Client VM warning: You have loaded library /usr/lib/unifi/lib/native/Linux/armv7/libubnt_webrtc_jni.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
Port 8080 not available
Port 8080 not available
Port 8080 not available
Port 8080 not available
....

Cannot find libjvm.so

I am using this docker image for some while now. However, I have restarted my pi and now the docker file won't run anymore. It crashes with the following error:

unifi    |     invalid section len 4194352, max remaining 48
unifi    |     ignoring unknown attr section agabi
unifi    | Error: dl failure on line 893
unifi    | Error: failed /usr/lib/jvm/java-8-openjdk-armhf/jre/lib/arm/client/libjvm.so, because /usr/lib/jvm/java-8-openjdk-armhf/jre/lib/arm/client/libjvm.so: cannot open shared object file: No such file or directory

I have also tried to follow the installation again (to get a fresh version) but that crashes with the same error. I am running an RPI 3B. Is this a known issue or am I doing something wrong?

5.12.22 now stable

5.12.22 was marked as stable on 2019-10-29: https://community.ui.com/releases/UniFi-Network-Controller-5-12-22/263c8b60-def8-4667-85c3-87a6200a6c9b#comment/57403c30-8bf5-4cb8-8aa4-f3408cb6f4cb

Working with docker on Raspian?

I have a "normal" docker installation on Raspian, can I run your containers with that environment as well?
The last container I tried was that one, but it crashes shortly after starting initialization:
https://hub.docker.com/r/erikdevries/rpi-unifi/
Thanks for all your work on this!

Best, Michael

Raspberry Pi 4 issues

I tried to run the container on a Raspberry Pi 4. First it seemed like it would work, but the application is not coming up. I couldn't see anything helpful in the logs.
Does anyone know why it's not working on the new Raspberry Pi 4 and how this issues can be fixed?

OpenJDK Client Warnings & Java IllegalStateException Errors

Fresh install on RPi 3B+ seeing the below in the log files (as viewed through Portainer)

Is it safe to ignore the warning or do I need to tweak the Java settings etc?

Richy.

Restart policy for docker

Instead of doing separate instructions to run and configure startup initiation for each OS, wouldn't it be better to use docker's restart policy?

Example

docker run -dit --restart unless-stopped redis

Would be the same for all operating systems

Can't get it to work

On a HypriotOS-installed RaspberryPi 3 I followed procedures to bootup unifi with docker-compose, but I can't seem to get it to work.

When I try to access https://IP:8443/ I get the a warning about non trusted certificate, but when I try to continue it just waits indefinitely for response from server. Any help would be appreciated :)

Entrypoint config over-allocates memory

In: https://github.com/ryansch/docker-unifi-rpi/blob/master/5.10/Dockerfile.arm64v8
Line: ENTRYPOINT ["/usr/bin/java", "-Xmx1024M", "-jar", "/usr/lib/unifi/lib/ace.jar"]
Specifies: Max of 1024M for JVM use within the container. However, that is the max available on the Pi. Line should be modified to use a max of say 500M-700M, to allow enough for the base OS to continue to operate while the container is running in Docker.

Environment:
Ubuntu 18.04.2 LTS (GNU/Linux 4.15.0-1032-raspi2 aarch64)
Docker version 18.09.3, build 774a1f4
Container version ryansch/unifi-rpi:5.10.20-arm64v8
Rasberry Pi Model 3B

Pull in OS updates after java layer to shrink upgrade download size

Waiting on https://launchpad.net/~webupd8team/+archive/ubuntu/java to release 8u162. 8u144 is no longer available to download for arm.

Unifi thread: https://community.ubnt.com/t5/UniFi-Wireless-Beta/NOTICE-Oracle-Java-8-update-151-and-the-UniFi-Controller/m-p/2110938#M57216

Oracle Java license change: installer PPA EOLed

We no longer have access to install java into the container image via the oracle-java8-installer. I'll have to invent a new way to get java now.

Is port 8081 actually used by UniFi?

I see you're exposing port 8081/tcp.

However, on this page, port 8081 is not mentioned. In addition, this page has someone asking a similar question, where it is said that 8081 can be closed. On my controller running on a KVM, netstat shows that 8081 is not being listened on either.

Is 8081 actually used by UniFi?

Two different install methods in documentation

There are 2 different methods of installing the controller in the documentation;

https://github.com/ryansch/docker-unifi-rpi#on-rpi

and

https://github.com/ryansch/docker-unifi-rpi/wiki/Getting-Started-on-a-Raspberry-Pi#on-rpi

I used the first (thank you very much 😄) but I have no idea how I might upgrade it. There is an instruction on upgrading under the second method.

Why the repository for ubiquiti is added?

n

Testing/Unstable tag for docker images

Hi Ryan,

thanks so much for your great work. I am using the your docker image since a couple of years and I am also very happy about especially when it comes to updates. I am using the watchtower image to update my controller automatically and it works always like a charme.

For convenience purposes I would like to request a new general tag for testing/unstable versions of the controller versions like you have done for the stable version with "latest" or "5" and so on. Or is that explicitly not wanted from you?

ssl_match_hostname

I'm I missing something ?
I'm on a raspberry pi 4 but can't create the container

pi@raspberrypi:~/unifi $ sudo docker-compose up -d
Traceback (most recent call last):
File "/usr/local/bin/docker-compose", line 6, in
from compose.cli.main import main
File "/usr/local/lib/python2.7/dist-packages/compose/cli/main.py", line 18, in
import docker
File "/usr/local/lib/python2.7/dist-packages/docker/init.py", line 2, in
from .api import APIClient
File "/usr/local/lib/python2.7/dist-packages/docker/api/init.py", line 2, in
from .client import APIClient
File "/usr/local/lib/python2.7/dist-packages/docker/api/client.py", line 10, in
from .build import BuildApiMixin
File "/usr/local/lib/python2.7/dist-packages/docker/api/build.py", line 6, in
from .. import auth
File "/usr/local/lib/python2.7/dist-packages/docker/auth.py", line 9, in
from .utils import config
File "/usr/local/lib/python2.7/dist-packages/docker/utils/init.py", line 3, in
from .decorators import check_resource, minimum_version, update_headers
File "/usr/local/lib/python2.7/dist-packages/docker/utils/decorators.py", line 4, in
from . import utils
File "/usr/local/lib/python2.7/dist-packages/docker/utils/utils.py", line 13, in
from .. import tls
File "/usr/local/lib/python2.7/dist-packages/docker/tls.py", line 5, in
from .transport import SSLHTTPAdapter
File "/usr/local/lib/python2.7/dist-packages/docker/transport/init.py", line 3, in
from .ssladapter import SSLHTTPAdapter
File "/usr/local/lib/python2.7/dist-packages/docker/transport/ssladapter.py", line 23, in
from backports.ssl_match_hostname import match_hostname
ImportError: No module named ssl_match_hostname

Having trouble when upgrading to latest version

I tried upgrading to latest version using:

docker-compose stop
docker-compose rm -f
docker-compose pull   
docker-compose up -d

and this happened:
https://hastebin.com/vonahuxoxa.terminal

Multiarch

Non-root execution

Thanks so much for the work you've done on this, it's saved me a ton of time.

I note that the Java VM runs with root privileges currently. I'd really like to protect my host, is there a simple way to have the container execute as a non-root user? If not, this is a feature request!

Version 5.12.46 Beta

Hi there,

would you mind adding support for the latest 5.12.46 Beta version? I'm usually not into beta versions, but this one contains a very important bugfix for me and I would love to test it.

I guess you are taking some days off over the hoildays anyways, but I will patiently wait.

Best regards

Step by Step To Upgrade To Latest Release

Would you be able to give a step by step on how to update a controller within your docker image? I followed some information you gave on the ubiquiti forums to do a docker-compose down -v and that allowed me to rebuild and pull the latest image but it also required me to upload my config file. Is there anyway to avoid that step and just update the controller without starting fresh?

Thank you.

UniFi Controller is starting up... Never Starts Rock64

So I’m on the Rock64 installed /ryansch/docker-unifi-rpi installs correctly it starts up on the web page but all I get is unifi controller is starting up nothing else. I used these commands to install.

cd /opt 
sudo git clone https://github.com/ryansch/docker-unifi-rpi unifi 
sudo systemctl enable /opt/unifi/contrib/unifi.service 
docker pull ryansch/unifi-rpi:latest (For download and extract progress) 
sudo systemctl start unifi

The Rock64 is arm64/armhf hopefully architecture isn’t why it’s not working correctly. Any help is great!

Don't get any response on url

Hi!

I was trying to use the container you've created. I used the instructions ons the docker hub, but after the container started the url doesn't give any response.
After the docker compose didn't work I tried to use the image directly like this:
docker run -d --name="unifi" -v /home/pi/dockerdata/unifi/config:/var/lib/unifi -v /home/pi/dockerdata/unifi/log:/usr/lib/unifi/logs -v /home/pi/dockerdata/unifi/log2:/var/log/unifi -v /home/pi/dockerdata/unifi/run:/usr/lib/unifi/run -v /home/pi/dockerdata/unifi/run2:/run/unifi -v /home/pi/dockerdata/unifi/work:/usr/lib/unifi/work --restart unless-stopped --net=host ryansch/unifi-rpi:v5

But that is working neither.

Can you help me to get this running? I'm using a Raspian Pi 3b and i'm running more containers that are working.

Thanks in advance!

Swarm support ?

hi guys,
would you be able to migrate from docker-compose to docker swarm ? it will allow us to layer on more tools like Portainer for management (fantastic UI, just 4mb of memory) - https://portainer.io/install.html

Cannot start after update

It gives me this error after update with docker-compose pull

https://hastebin.com/ukumifehut.rb