jacobalberty / unifi-docker

Unifi Docker files

Unifi-in-Docker (unifi-docker)

This repo contains a Dockerized version of Ubiqiti Network's Unifi Controller.

Why bother? Using Docker, you can stop worrying about version hassles and update notices for Unifi Controller, Java, or your OS. A Docker container wraps everything into one well-tested bundle.

To install, a couple lines on the command-line starts the container. To upgrade, just stop the old container, and start up the new. It's really that simple.

This container has been tested on Ubuntu, Debian, macOS, Windows, and even Raspberry Pi hardware.

See the Current Information section for the latest versions.

Setting up, Running, Stopping, Upgrading

First, install Docker on the "Docker host" - the machine that will run the Docker and Unifi Controller software. Use any of the guides on the internet to install on your Docker host. For Windows, see the Microsoft guide for installing Docker.

Then use the following steps to set up the directories and start the Docker container running.

Setting up directories

One-time setup: create the unifi directory on the Docker host. Within that directory, create two sub-directories: data and log.

cd # by default, use the home directory
mkdir -p unifi/data
mkdir -p unifi/log

Note: By default, this README assumes you will use the home directory on Linux, Unix, macOS. If you create the directory elsewhere, read the Options section below to adjust.)

Running Unifi-in-Docker

Each time you want to start Unifi, use this command. Each of the options is described below.

docker run -d --init \
   --restart=unless-stopped \
   -p 8080:8080 -p 8443:8443 -p 3478:3478/udp \
   -e TZ='Africa/Johannesburg' \
   -v ~/unifi:/unifi \
   --user unifi \
   --name unifi \
   jacobalberty/unifi

In a minute or two, (after Unifi Controller starts up) you can go to https://docker-host-address:8443 to complete configuration from the web (initial install) or resume using Unifi Controller.

Important: Two points to be aware of when you're setting up your Unifi Controller:

• When your browser initially connects to the link above, you will see a warning about an untrusted certificate. If you are certain that you have typed the address of the Docker host correctly, agree to the connection.
• See the note below about Override "Inform Host" IP so your Unifi devices can "find" the Unifi Controller.

Stopping Unifi-in-Docker

To change options, stop the Docker container then re-run the docker run... command above with the new options. Note: The docker rm unifi command simply removes the "name" from the previous Docker image. No time-consuming rebuild is required.

docker stop unifi
docker rm unifi

Upgrading Unifi Controller

All the configuration and other files created by Unifi Controller are stored on the Docker host's local disk (~/unifi by default.) No information is retained within the container. An upgrade to a new version of Unifi Controller simply retrieves a new Docker container, which then re-uses the configuration from the local disk. The upgrade process is:

1. MAKE A BACKUP on another computer, not the Docker host (Always, every time...)
2. Stop the current container (see above)
3. Enter docker run... with the newer container tag (see Current Information section below.)

Options on the Command Line

The options for the docker run... command are:

• -d - Detached mode: Unifi-in-Docker runs in the background
• --init - Recommended to ensure processes get reaped when they die
• --restart=unless-stopped - If the container should stop for some reason, restart it unless you issue a docker stop ...
• -p ... - Set the ports to pass through to the container. -p 8080:8080 -p 8443:8443 -p 3478:3478/udp is the minimal set for a working Unifi Controller.
• -e TZ=... Set an environment variable named TZ with the desired time zone. Find your time zone in this list of timezones.
• -e ... See the Environment Variables section for more environment variables.
• -v ... - Bind the volume ~/unifi on the Docker host to the directory /unifiinside the container. These instructions assume you placed the "unifi" directory in your home directory. If you created the directory elsewhere, modify the ~/unifi part of this option to match. See the Volumes discussion for other volumes used by Unifi Controller.
• --user unifi - Run as a non-root user. See the Run as non-root User discussion below
• jacobalberty/unifi - the name of the container to use. The jacobalberty... image is retrieved from Dockerhub. The Current Information section below discusses the versions/tags that are available.

Current Information

The current "latest" version is Unifi Controller 7.5.176. There are currently no hot-fix or CVE warnings affecting Unifi Controller.

You can choose the version of Unifi Controller in the docker run ... command. In Docker terminology, these versions are specified by "tags".

For example, in this project the container named jacobalberty/unifi (with no "tag") provides the most recent stable release. The table below lists recent versions.

The rc tag (for example, jacobalberty/unifi:rc) uses the most recent Release Candidate from the UniFi APT repository.

You may also specify a version number (e.g., jacobalberty/unifi:stable6) to get a specific version number, as shown in the table below.

Note: In Docker, specifying an image with no tag (e.g., jacobalberty/unifi) gets the "latest" tag. For Unifi-in-Docker, this uses the most recent stable version.

Tag	Description	Changelog
latest v8.1.113	Current Stable: Version 8.1.113 as of 2024-03-18	Change Log 8.1.113
rc	Release Candidate: 7.2.92-rc as of 2022-07-29	Change Log 7.2.91-rc
stable-6	Final stable version 6 (6.5.55)	Change Log 6.5.55
stable-5	Final stable version 5 (5.4.23)	Change Log 5.14.23

multiarch

All available containers now support multiarch with amd64, armhf, and arm64 builds included. armhf for now uses mongodb 3.4, I do not see much of a path forward for armhf due to the lack of mongodb support for 32 bit arm, but I will support it as long as feasibly possible, for now that date seems to be expiration of support for ubuntu 18.04.

Adopting Access Points and Unifi Devices

Override "Inform Host" IP

For your Unifi devices to "find" the Unifi Controller running in Docker, you MUST override the Inform Host IP with the address of the Docker host computer. (By default, the Docker container usually gets the internal address 172.17.x.x while Unifi devices connect to the (external) address of the Docker host.) To do this:

• Find Settings -> System -> Other Configuration -> Override Inform Host: in the Unifi Controller web GUI. (It's near the bottom of that page.)
• Check the "Enable" box, and enter the IP address of the Docker host machine.
• Save settings in Unifi Controller
• Restart UniFi-in-Docker container with docker stop ... and docker run ... commands.

See Side Projects for other techniques to get Unifi devices to adopt your new Unifi Controller.

Volumes

Unifi looks for the /unifi directory (within the container) for its special purpose subdirectories:

• /unifi/data This contains your UniFi configuration data. (formerly: /var/lib/unifi)

• /unifi/log This contains UniFi log files (formerly: /var/log/unifi)

• /unifi/cert Place custom SSL certs in this directory. For more information regarding the naming of the certificates, see Certificate Support. (formerly: /var/cert/unifi)

• /unifi/init.d You can place scripts you want to launch every time the container starts in here

• /var/run/unifi Run information, in general you will not need to touch this volume. It is there to ensure UniFi has a place to write its PID files

Legacy Volumes

These are no longer actually volumes, rather they exist for legacy compatibility. You are urged to move to the new volumes ASAP.

• /var/lib/unifi New name: /unifi/data
• /var/log/unifi New name: /unifi/log

Environment Variables:

You can pass in environment variables using the -e option when you invoke docker run... See the TZ in the example above. Other environment variables:

• UNIFI_HTTP_PORT This is the HTTP port used by the Web interface. Browsers will be redirected to the UNIFI_HTTPS_PORT. Default: 8080

• UNIFI_HTTPS_PORT This is the HTTPS port used by the Web interface. Default: 8443

• PORTAL_HTTP_PORT Port used for HTTP portal redirection. Default: 80

• PORTAL_HTTPS_PORT Port used for HTTPS portal redirection. Default: 8843

• UNIFI_STDOUT Controller outputs logs to stdout in addition to server.log Default: unset

• TZ TimeZone. (i.e America/Chicago)

• JVM_MAX_THREAD_STACK_SIZE Used to set max thread stack size for the JVM Example:

  --env JVM_MAX_THREAD_STACK_SIZE=1280k
  

  as a fix for https://community.ubnt.com/t5/UniFi-Routing-Switching/IMPORTANT-Debian-Ubuntu-users-MUST-READ-Updated-06-21/m-p/1968251#M48264

• LOTSOFDEVICES Enable this with true if you run a system with a lot of devices and/or with a low powered system (like a Raspberry Pi). This makes a few adjustments to try and improve performance:

  • enable unifi.G1GC.enabled
  • set unifi.xms to JVM_INIT_HEAP_SIZE
  • set unifi.xmx to JVM_MAX_HEAP_SIZE
  • enable unifi.db.nojournal
  • set unifi.dg.extraargs to --quiet

  See the Unifi support site for an explanation of some of those options. Default: unset

• JVM_EXTRA_OPTS Used to start the JVM with additional arguments. Default: unset

• JVM_INIT_HEAP_SIZE Set the starting size of the javascript engine for example: 1024M Default: unset

• JVM_MAX_HEAP_SIZE Java Virtual Machine (JVM) allocates available memory. For larger installations a larger value is recommended. For memory constrained system this value can be lowered. Default: 1024M

Exposed Ports

The Unifi-in-Docker container exposes the following ports. A minimal Unifi Controller installation requires you expose the first three with the -p ... option.

• 8080/tcp - Device command/control
• 8443/tcp - Web interface + API
• 3478/udp - STUN service
• 8843/tcp - HTTPS portal (optional)
• 8880/tcp - HTTP portal (optional)
• 6789/tcp - Speed Test (unifi5 only) (optional)

See UniFi - Ports Used for more information.

Run as non-root User

The default container runs Unifi Controller as root. The recommended docker run... command above starts Unifi Controller so the image runs as unifi (non-root) user with the uid/gid 999/999. You can also set your data and logs directories to be owned by the proper gid.

Note: When you run as a non-root user, you will not be able to bind to lower ports by default. (This would not necessary if you are using the default ports.) If you must do this, also pass the --sysctl net.ipv4.ip_unprivileged_port_start=0 option on the docker run... to bind to whatever port you wish.

Certificate Support

To use custom SSL certs, you must map a volume with the certs to /unifi/cert

They should be named:

cert.pem  # The Certificate
privkey.pem # Private key for the cert
chain.pem # full cert chain

If your certificate or private key have different names, you can set the environment variables CERTNAME and CERT_PRIVATE_NAME to the name of your certificate/private key, e.g. CERTNAME=my-cert.pem and CERT_PRIVATE_NAME=my-privkey.pem.

For letsencrypt certs, we'll autodetect that and add the needed Identrust X3 CA Cert automatically. In case your letsencrypt cert is already the chained certificate, you can set the CERT_IS_CHAIN environment variable to true, e.g. CERT_IS_CHAIN=true. This option also works together with a custom CERTNAME.

Certificates Using Elliptic Curve Algorithms

If your certs use elliptic curve algorithms, which currently seems to be the default with letsencrypt certs, you might additionally have to set the UNIFI_ECC_CERT environment variable to true, otherwise clients will fail to establish a secure connection. For example an attempt with curl will show:

% curl -vvv https://my.server.com:8443
curl: (35) error:1404B410:SSL routines:ST_CONNECT:sslv3 alert handshake failure

You can check your certificate for this with the following command:

% openssl x509 -text < cert.pem | grep 'Public Key Algorithm'
         Public Key Algorithm: id-ecPublicKey

If the output contains id-ec as shown in the example, then your certificate might be affected.

Additional Information

This document describes everything you need to get Unifi-in-Docker running. The Side Projects and Background Info page provides more about what we've learned while developing Unifi-in-Docker.

TODO

This list is empty for now, please add your suggestions.

unifi-docker's Issues

[Feature Proposal] Handle existing chain.pem during import

What tag are you using

none (yet)

What do you expect to happen?

By specifying my CERTDIR I expect that import_cert imports my certificate into the container.

What actually happens?

import_cert won't find my certificate, because it is already chained and named fullchain.pem instead of cert.pem.

Proposal

I'd like to propose to add an option to specify if there are two files chain.pem and cert.pem, or if they are already chained. I'm happy to implement it and create a PR, but I created this issue to discuss the format of how we want to handle it.

I would say we could add an ENV variable CERTNAME that defaults to cert.pem and additionally add an ENV variable CHAINPROVIDED that defaults to false. If CHAINPROVIDED is set to true, we consider the file at "$CERTDIR/$CERTNAME" to be the chain and directly use it instead of concatenating a chain and a cert.

What do you think?

Cant add Site

I cant add site. Only default site is available.

Build fails due to openjdk-8-jre-headless breaks ca-certificates-java

Looks like this is a recent problem on Jessie with openjdk-8-jre-headless: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851667

system.properties changes do not stick

Host operating system

Debian GNU/Linux 8

What tag are you using

Example: latest

What complete docker command or docker-compose.yml do you use to launch the container (omitting sensitive values)?

unifi:
    container_name: unifi
    # https://github.com/jacobalberty/unifi-docker
    image: jacobalberty/unifi:latest
    network_mode: host
    restart: always
    volumes:
      - ./data/unifi:/unifi
      - ./data/letsencrypt/certs/gateway.feliciterra.com:/unifi/cert

Note: A screenshot of your configuration page if using a gui is acceptable

What do you expect to happen?

system.properties to keep the settings that I change.

What actually happens?

system.properties is set back to default (everything commented) and my changes are removed.

Volumes are not correct

I'm commenting specifically on the unifi5 docker file.

I docker exec'd into the running container and reviewed the declared volume folders and found the following:

/var/lib/unifi - This volume seems ok, contains MogoDB Data AND Unifi Server Logs + Settings
/var/log/unifi - This folder is empty.. Logs are contained in the previous mount.
/var/run/unifi - This folder is empty. Not sure what should/would have been here?
/usr/lib/unifi/work - This folder contains an empty folder called ROOT.. nothing else.

What's missing are the MongoDB logs... They can be found here: /usr/lib/unifi/logs/mongod.log

So I purpose we REMOVE /var/log/unifi /var/run/unifi /usr/lib/unifi/work and ADD /usr/lib/unifi/logs

So end result would be:
VOLUME ["/var/lib/unifi", "/usr/lib/unifi/logs"]

Thoughts? I'd be more than happy to submit a PR too...

ERR_SSL_VERSION_OR_CIPHER_MISMATCH with letsencrypt certificates

Host operating system

Debian GNU/Linux 8

What tag are you using

latest

What complete docker command or docker-compose.yml do you use to launch the container (omitting sensitive values)?

version: '3'
services:
  letsencrypt:
    container_name: letsencrypt
    image: csmith/letsencrypt-lexicon:latest
    restart: always
    environment:
      PROVIDER: 'dnsimple'
      ACCEPT_CA_TERMS: 'true'
    env_file:
      - .env
    volumes:
      - ./data/letsencrypt:/letsencrypt
  unifi:
    container_name: unifi
    # https://github.com/jacobalberty/unifi-docker
    image: jacobalberty/unifi:latest
    network_mode: host
    restart: always
    volumes:
      - ./data/unifi:/unifi
      - ./data/letsencrypt/certs/gateway.feliciterra.com:/unifi/cert

What do you expect to happen?

For the TLS certs to work when visiting with a browser.

What actually happens?

I've tried a variety of things here but can't seem to get anything to work. The error displayed in chrome is ERR_SSL_VERSION_OR_CIPHER_MISMATCH and in Firefox it's SSL_ERROR_NO_CYPHER_OVERLAP. If I remove my letsencrypt certificates everything works fine with the self-signed cert. It seems that the letsencrypt certs are broken when imported into unifi. These exact same certs I have mounted in other services and running just fine. I have rebuilt the container numerous times all with the same results.

Update Package to 5.4.14

Hello Jacob
First of all thanks for your great work. Can you please create the new package for version 5.4.14. Another question is there a way to upgrade to the latest version without redoing the container?

Error starting

I just ran

~$ docker run --net=host -d jacobalberty/unifi:latest

Got this error:

4acb32b0ea26446bc809008a5b54dd402c5f0296edd2fd616733dd98a6800212
docker: Error response from daemon: oci runtime error: container_linux.go:247: starting container process caused "process_linux.go:359: container init caused "apparmor failed to apply profile: no such file or directory"".

Any ideas what would cause this?

Thanks!

STUN Not Responding

My APs are reporting that the STUN server on the controller is unavailable. I'm running this container with "-p 3478:3478", but when I attempt to connect using stun-client on the docker host I'm seeing an error.

bfdonny@muon:~$ docker ps --filter "name=unifi"

CONTAINER ID        IMAGE                       COMMAND                  CREATED             STATUS                  PORTS                                                                                                                                                NAMES
d1b3cf7819e6        jacobalberty/unifi:stable   "/usr/local/bin/docke"   15 hours ago        Up 15 hours (healthy)   6789/tcp, 0.0.0.0:3478->3478/tcp, 0.0.0.0:8081->8081/tcp, 8080/tcp, 8843/tcp, 0.0.0.0:8443->8443/tcp, 3478/udp, 0.0.0.0:10001->10001/tcp, 8880/tcp   unifi

bfdonny@muon:~$ stun 192.168.0.172

STUN client version 0.97
Primary: Blocked or could not reach STUN server
Return value is 0x00001c

I'm not sure if I'm just doing something wrong, or if there's some other issue.

How do I an upgrade to latest docker container?

Host operating system

same

What tag are you using

latest for now

What complete docker command or docker-compose.yml do you use to launch the container (omitting sensitive values)?

docker on synology nas.

What do you expect to happen?

a documentation section about upgrade to new container version.

What actually happens?

I don't know.

QNAP TS-451 locks up when trying to install

My problem is installing this causes my QNAP to lock up. I have a TS-451 QNAP.

I installed the Container Station so that was fine (took a bit but it worked) Then first I simply searched for the unifi and installed it that way based on another video and it locked up at 83% complete and my system was inaccessible. I needed to force a reboot, uninstall container station and do a media check of the drives.

I saw a video from the docker comments and decided to try installing it via SSH. The command I ran was:

docker run --name unifi-uap-controller --net=host -d jacobalberty/unifi:latest

It downloaded everything but it locked up while extracting the 200MB file and so I thought perhaps it was simply "stuck" so I went to bed and looked at it this morning. In the morning it was still inaccessible so I had to force a reboot again. This time I had to check the volume but at least Container station sort of loaded. I say sort of because it sat for 40 minutes on "loading" whereas before it gave a big red "can't load" error.

I ended up uninstalling it again and just putting my port back to 8080 and I'm deciding that my QNAP cannot handle this unless someone reading this knows what else I can do to get it installed.

Incidentally I have over 2TB of space available on the volume so it's not full.

Upgrade question Syno Docker controller

Host operating system

Synology DiskStation / Docker controller

I still have 5.5.24 version running and want to upgrade to the 5.6 version. Normally i would use the following command:

docker run -d -p 3478:3478/udp -p 8080:8080 -p 8443:8443 -v /volume1/docker/unifi/:/var/lib/unifi --restart=always --name unifi jacobalberty/unifi:latest

Now with the new folder structure, can i still use it in this way ? Or do i have to do preparations before i can upgrade ? It it said that one should switch to new folder layout asap, but i do not know how. Simply replace folder names in above command would not be right i guess, because the folders (unifi/data - unifi/log) do not exist at the moment.

So basically, how to upgrade from 5.5.24 to 5.6.xx ? Many thanx,

Problem with updated kernel

This seems to be brokenn right now and as far as i can see also affects this repo:

https://community.ubnt.com/t5/UniFi-Routing-Switching/IMPORTANT-Debian-Ubuntu-users-MUST-READ-Updated-06-21/m-p/1968251#M48264

Controller does not come up when port 8080 is not bound

Is it possible to startup the container without all ports bound on the host?

It seems to me that if i do only bind port 8443 (for testing only) the container does not come up. Is there any reason for this?

I know i need more or all of the ports in production, but i do have other containers running on the same host using these ports already (8080)

Possibility to choose Unifi verision to install by ENV variable?

Hi, could you change the dockerfile in a way so its possible to choose the installation verison of Unifi by ENV variable? For example just check if there is the ENV "PKGURL" configured, if not, then fallback to latest stable. Or is this already possible?

Docker image sits at Starting unifi controller service.

Starting unifi controller service.

Just pulled the latest image and am running it in docker on OMV 3. Log sits at
Starting unifi controller service.

Here is the full log with 1 reboot. Trying the stable tag now.
[2017-10-12 21:12:20,643] <docker-entrypoint> Starting unifi controller service.
[2017-10-12 21:19:51,358] <docker-entrypoint> Exit signal received, shutting down
/usr/local/bin/docker-entrypoint.sh: line 1: kill: (15) - No such process
[2017-10-12 21:19:58,589] <docker-entrypoint> Exit signal received, shutting down
[2017-10-12 21:20:02,184] <docker-entrypoint> Starting unifi controller service.

Add HEALTHCHECK

Was just reading over this:

https://blog.newrelic.com/2016/08/24/docker-health-check-instruction/

Seems like something like this would suffice:

curl -k -L --fail https://localhost:8443 || exit 1

Map/Open UDP ports

Your docs want to be changed to open/map the UDP ports, e.g.,

-p 8080:8080 -p 8443:8443 -p 3478:3478/udp -p 10001:10001/udp

Use tags in builds

This is just to give a warning of the future, the current build system uses directories, docker hub supports using {sourceref} to create tags based on releases. I'd like to clean up the builds to use sourceref instead.

Switch to Alpine Linux

It might be a good idea to switch to Alpine Linux to decrease the image size. There might

There's an official image openjdk:8-jdk-alpine available now, and mongodb package on testing branch of Alpine.

Although it would be better if Ubiquiti offered an official package for Alpine.

Trigger build for newest controller stable release

Can you trigger a new build so that the latest tag is updated? Thanks!

Running an external MongoDB

According to @UBNT-JoeHughes;

In 5.3.X this is now possible and you can set the following in your system.properties file.

db.mongo.local=false
db.mongo.uri=mongodb://ubnt:password@IP_ADDRESS:PORT/unifi-test
statdb.mongo.uri=mongodb://ubnt:password@IP_ADDRESS:PORT/unifi-test_stat
unifi.db.name=unifi-test

db.mongo.local Set to false to use an external mongodb server and not star the local mongo db service.
db.mongo.uri The Mongo URI that should be used to connect to the remote mongo database.
statdb.mongo.uri The mongo uri for the external mongo stats database.
unifi.db.name This will default to ace so must be set to the name that can be connected and managed on the external mongo db server.

Make sure you notice in the URI that unifi.db.name is used for both stat and the main database.

So the mongo URI will work with any ip address… even if mongo is local… but the URI needs to be in the correct format to connect.

REF: https://community.ubnt.com/t5/UniFi-Wireless/External-MongoDB-Server/td-p/1305297

/unifi/cert/chain.pem does not work for me with Let's Encrypt

with the chain in chain.pem it does not work but if I put the cert and the chain together in cert.pem it's ok. Maybe you should change the doc?

Host operating system

CentOS Linux release 7.3.1611 (Core)

What tag are you using

latest

What complete docker command or docker-compose.yml do you use to launch the container (omitting sensitive values)?

docker run --net=host -d
-e TZ='Europe/Berlin'
-v /opt/unifi:/unifi
--name unifi
jacobalberty/unifi:latest

Note: A screenshot of your configuration page if using a gui is acceptable

What do you expect to happen? chain and cert in cert.pem (real domain masked)

openssl s_client -servername unifi.xxx.net -connect unifi.xxx.net:8443
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = unifi.xxx.net
verify return:1

Certificate chain
0 s:/CN=unifi.xxx.net
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3

What actually happens? (chain in chain.pem)

openssl s_client -servername unifi.xxx.net -connect unifi.xxx.net:8443
CONNECTED(00000003)
depth=0 CN = unifi.xxx.net
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = unifi.xxx.net
verify error:num=27:certificate not trusted
verify return:1
depth=0 CN = unifi.xxx.net
verify error:num=21:unable to verify the first certificate
verify return:1

Certificate chain
0 s:/CN=unifi.xxx.net
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3

Setting UNIFI_GID yields an error

Host operating system

Synology NAS

What tag are you using

Example: 5.6.19-sc

What complete docker command or docker-compose.yml do you use to launch the container (omitting sensitive values)?

Example: sudo docker run -p 8080:8080 -p 8880:8880 -p 8843:8843 -p 6789:6789 -p 8443:8443 -p 3478:3478/udp -p 10001:10001/udp -e TZ='Europe/Berlin' -e RUNAS_UID0='false' -e UNIFI_UID=1036 -e UNIFI_GID=100 -v /volume1/docker/unifi/2017-10-18:/unifi --name 2017-10-18-unifi-5.6.19-sc -d jacobalberty/unifi:5.6.19-sc

What do you expect to happen?

Container runs without error.

What actually happens?

I get an "groupmod: GID '100' already exists" error and the container does not run.
UID and GID are set in correspondece to the user I created for this container which owns the directory.

Possibly adding option -o (-o, --non-unique) to groupmod would help?!

Best regards

USG Json file

I can't seem to find where to upload the JSON files. I am using docker with synology.

Cannot connect to the Cloud when RUNAS_UID0 is set to false

Host operating system

QNAP TS-453A

What tag are you using

5.6.19

What complete docker command or docker-compose.yml do you use to launch the container (omitting sensitive values)?

Example: docker run --rm --init -p 8080:8080 -p 8443:8443 -p 3478:3478/udp -p 10001:10001/udp -e TZ='Africa/Johannesburg' -v ~/unifi/data:/var/lib/unifi -v ~/unifi/logs:/var/log/unifi --name unifi jacobalberty/unifi:unifi5

Note: A screenshot of your configuration page if using a gui is acceptable

What do you expect to happen?

after setting the owner of the folder to the right user group i proceeded to create the container. i should be able to connect to the cloud service.

What actually happens?

there is no possibility to connect to the cloud service unless the RUNAS_UID0 is set to true

5.5.6 unstable container

Jacob,

can you please provide a docker container for the current "unstable" version 5.5.6?
https://www.ubnt.com/downloads/unifi/5.5.6-b559495f0c/unifi_sysvinit_all.deb

According to ubnt support it should fix some issues which are not going to be fixed for the 5.4. branch.

AP being constantly readopted

Host operating system

Example: Fedora 26 with Docker version 17.09.0-ce, build afdb6d4

What tag are you using

latest

What complete docker command or docker-compose.yml do you use to launch the container (omitting sensitive values)?

docker run -d --rm --init -p 8081:8080 -p 8443:8443 -p 3478:3478/udp -p 10001:10001/udp -p 6789:6789 -e TZ='Europe/London' --mount source=unifi,target=/unifi --name unifi jacobalberty/unifi:latest

Note: A screenshot of your configuration page if using a gui is acceptable

What do you expect to happen?

Access point adopted and remains that way

What actually happens?

I see this in the server logs for a given day:

[root@tazmadlx log]# grep 2017-12-04 server.log | grep adopted | head
[2017-12-04 04:11:30,263] <ssh> INFO  event  - [event] AP[80:2a:a8:16:cb:af] was automatically readopted
[2017-12-04 04:12:39,574] <ssh> INFO  event  - [event] AP[80:2a:a8:16:cb:af] was automatically readopted
[2017-12-04 04:13:39,627] <ssh> INFO  event  - [event] AP[80:2a:a8:16:cb:af] was automatically readopted
[2017-12-04 04:14:39,676] <ssh> INFO  event  - [event] AP[80:2a:a8:16:cb:af] was automatically readopted
[2017-12-04 04:15:39,693] <ssh> INFO  event  - [event] AP[80:2a:a8:16:cb:af] was automatically readopted
[2017-12-04 04:16:39,731] <ssh> INFO  event  - [event] AP[80:2a:a8:16:cb:af] was automatically readopted
[2017-12-04 04:17:39,774] <ssh> INFO  event  - [event] AP[80:2a:a8:16:cb:af] was automatically readopted
[2017-12-04 04:18:39,830] <ssh> INFO  event  - [event] AP[80:2a:a8:16:cb:af] was automatically readopted
[2017-12-04 04:19:39,870] <ssh> INFO  event  - [event] AP[80:2a:a8:16:cb:af] was automatically readopted
[2017-12-04 04:20:39,914] <ssh> INFO  event  - [event] AP[80:2a:a8:16:cb:af] was automatically readopted
[root@tazmadlx log]# grep 2017-12-04 server.log | grep adopted | wc -l
1091
[root@tazmadlx log]# 

There also seems to be some sort of memory leak caused by I suspect the java process, but then I am new to all the docker stuff so not 100% sure. I had seen a post about this issue somewhere but I can't seem to find it now so apologies if this was already resolved and I am doing something dumb.

In case it helps, am running:

openjdk version "1.8.0_151"
OpenJDK Runtime Environment (build 1.8.0_151-b12)
OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)

Thanks

How to run container behind proxy?

I have a server running various things and use nginx to proxy to services based on hostname. When I try to proxy requests to localhost 8443 the page loads, but I get a 403 when trying to login. Is this configuration supported?

Ideally, I could turn off tls and just proxy to 8080, since nginx handles certs, but anyway I can get it to work is fine.

Host operating system

Ubuntu 17.10

What tag are you using

stable

What complete docker command or docker-compose.yml do you use to launch the container (omitting sensitive values)?

docker run --restart=always --init -p 6789:6789 -p 8080:8080 -p 8443:8443 -p 3478:3478/udp -p 10001:10001/udp -e TZ='America/Los_Angeles' -v /path/unifi:/unifi --env RUNAS_UID0=false --name unifi -d jacobalberty/unifi:stable

10001/udp not exposed?

New to docker but when I do an 'inspect' I don't see 10001/udp in there,

        "ExposedPorts": {
            "3478/udp": {},
            "6789/tcp": {},
            "8080/tcp": {},
            "8443/tcp": {},
            "8843/tcp": {},
            "8880/tcp": {}
        },

Is that an oversight?

Document ways of running without `--net=host`

This is in fact unnecessary, though full network access is more convenient, it causes all sorts of issues such as conflicts with other containers and/or services on the host. IMHO, a better option is to just expose ports 8443 and 8080 (EDIT: and 10001/udp) (both of which can be re-mapped), and then SSH:ing into the AP and issuing the following commands:

# mca-cli
# set-inform http://<host_ip>:8080/inform

(where host_ip is the IP of the machine running Docker, and 8080 can be changed as appropriate if the port is remapped).

This makes the container play a lot more nicely in a multi-container system.

(Disclaimer: I got this information from a forum thread, but I verified this working and I am currently running your container this way)

5.4.17

Hello jacob

just to let you now that 5.4.17 is out

5.4.18

Hello Jacob

can you make the container for 5.4.18?

HEALTHCHECK fails if a custom UI/API port is specified

Specifying a non-default UI/API port via "unifi.https.port" in the system properties causes the HEALTHCHECK to fail as it is hard-coded to try to connect to the default port (8443).

For example we are giving the container its own IP and setting the UI/API port to the standard HTTPS port (443) so users can be given a nice simple URL with no port specification.

See pull request: #61

Timezone env var not working and add new env var for country?

First of all thanks for this image! Very nice, saves me having to install all kinds of Java stuff ;)

I just started the container/the controller for the first time and it seems like the timezone env var isn't being picked up. I passed TZ='Europe/Amsterdam' as env var, yet the setup wizard has "Brussels, Copenhagen, Madrid, Paris" selected.
Any idea why this isn't working?

And I was wondering if it would be possible to pass the country as an env var as well, just like the timezone. Hoping to be able to just skip the initial setup screen when starting a clean container :)

arm32v7-beta image's architecure is amd64 in image metadata

At least the current unifi:arm32v7-beta image's architecture is amd64 in the image metadata.
It works fine when run on stand-alone container (with docker run or docker-compose up) but noticed that when I tried to setup a swarm and run it as a service it got stuck in pending state as there were no amd64 machines in my swarm.

Support DHCP server too

The Unifi controller software supports being the DHCP server for the network settings of a site but when using the container there is no port exposed so DHCP will not work.

The DHCP employs a connectionless service model, using the User Datagram Protocol (UDP). It is implemented with two UDP port numbers for its operations which are the same as for the BOOTP protocol. UDP port number 67 is the destination port of a server, and UDP port number 68 is used by the client. (Wikipedia: DHCP)

So for supporting DHCP please add an EXPOSE of 67/udp to the image.

Coverage Map uploads not working

When attempting to upload custom image for the coverage maps, it yields an error message and nothing displays. The sample image also disappears after attempting to upload the first custom image.

Running in vSphere Integrated Containers?

I'm having issues running this in vSphere Integrated Containers but it can certainly be user error. This is a lab environment that I built yesterday and yesterday was also the first time I ever typed "docker" into my CLI so noob-level is quite high. Here are the steps I took to create the environment:

Create the VCH
.\vic-machine-windows.exe create --name unifi --target ESX-server-IP --user root --password "ESXrootpassword" --no-tlsverify --force --image-store "ESX-Datastore-name" --volume-store ESX-Datastore-name/docker-volume-folder:default --dns-server 10.0.0.10 --public-network-ip 10.0.0.20/24 --public-network-gateway 10.0.0.1

This appears to correctly build the virtual container host. I can query it using the docker client in a shell:

$ docker -H 10.0.0.20:2376 --tls info
Containers: 1
Running: 1
Paused: 0
Stopped: 0
Images: 1
Server Version: v1.1.1-10711-56a309f
Storage Driver: vSphere Integrated Containers v1.1.1-10711-56a309f Backend Engine
VolumeStores: default
vSphere Integrated Containers v1.1.1-10711-56a309f Backend Engine: RUNNING
VCH CPU limit: 3679 MHz
VCH memory limit: 27.93 GiB
VCH CPU usage: 58 MHz
VCH memory usage: 4.898 GiB
VMware Product: VMware ESXi
VMware OS: vmnix-x86
VMware OS version: 6.5.0
Plugins:
Volume: vsphere
Network: bridge
Swarm: inactive
Operating System: vmnix-x86
OSType: vmnix-x86
Architecture: x86_64
CPUs: 3679
Total Memory: 27.93GiB
ID: vSphere Integrated Containers
Docker Root Dir:
Debug Mode (client): false
Debug Mode (server): false
Registry: registry-1.docker.io
Experimental: false
Live Restore Enabled: false

When I attempt to run unifi-docker, though it appears to hang after "Starting unifi controller service" as seen here:
$ docker -H 10.0.0.20:2376 --tls run --rm -p 8080:8080 -p 8443:8443 -p 3478:3478 -p 10001:10001 -e TZ='America/Denver' -v /var/lib/unifi -v /var/log/unifi --name unifi jacobalberty/unifi:stable
Unable to find image 'jacobalberty/unifi:stable' locally
Pulling from jacobalberty/unifi
5233d9aed181: Pull complete
a3ed95caeb02: Pull complete
2e02715fac5e: Pull complete
78a9ca0f090f: Pull complete
3142747da002: Pull complete
8f15781934fa: Pull complete
b9ffd3cc8d63: Pull complete
4fcde711a5af: Pull complete
b13b02c3b14b: Pull complete
0720fe1df3cd: Pull complete
de35a6c93f7b: Pull complete
Digest: sha256:d7bcce256790e59d140105cee309667dfe961ed5e1e98d4272a2eb6ee03d5a99
Status: Downloaded newer image for jacobalberty/unifi:stable
Starting unifi controller service.

A docker ps shows this:
$ docker -H 10.0.0.20:2376 --tls ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
27cd00abfcd9 jacobalberty/unifi:stable "/usr/bin/dumb-ini..." Less than a second ago Up 2 hours 10.0.0.20:3478->3478/tcp, 10.0.0.20:8080->8080/tcp, 10.0.0.20:8443->8443/tcp, 10.0.0.20:10001->10001/tcp unifi

Hitting http://10.0.0.20:8080 in a browser appears to connect, but then I'm stuck at "Waiting for 10.0.0.20..."

Using this same basic method for VCH creation and docker deployment for a simple "hello world" webserver works fine, so I think the basic method I'm using is sound but I'm probably just missing a detail somewhere? Any pointers on where to look or any information I can provide to better illuminate this?

Unifi Not Starting and is Providing Minimal Reasons to why that is...

First let me lay out what I had, I had the Unifi:5.4.11 container, setup on a Marathon/Mesos. Now, it should not matter that it was here, I volume mounted data, run, and lib directories as instructed to persistent storage, so that's great, I am also running it in HOST network mode.

This was working for me, I would run it, do things I need to do , and then I would shut it down as to not waste resources. When I needed to upgrade/config I'd just start the service and go from there. Today, when I went to start the service, it starts and stays up, however, the actual service isn't running.

My outputs are this...

From a Mesos perspective, there is nothing in Standard Error, and in Standard Log there only "Starting unifi controller service."

In the log directly, there are only two files unifi.err.log and unifi.out.log. unifi.out.log is empty (but is created when I start the container). unifi.err.log has only the string "Service killed by signal 11" it it repeats and grows if I leave things running.

If I go into the container, these are the only processes running:

1 ?        Ss     0:00 /usr/bin/dumb-init -- /usr/local/bin/unifi.sh
7 ?        Ss     0:00 sh /usr/local/bin/unifi.sh

10 ? S 0:00 unifi -nodetach -home /usr/lib/jvm/java-8-openjdk-amd64 -classpath /usr/share/java/commons-daemon.jar:/usr/lib/unifi/lib/ace.jar -pidfile /var/run/unifi/unifi.pid -procname unifi -outfile /var/log/unifi/unifi.out.log -errfile /var/log/unifi/unifi.err.lo
g -Dunifi.datadir=/var/lib/unifi -Dunifi.rundir=/var/run/unifi -Dunifi.logdir=/var/log/unifi -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Xmx1024M com.ubnt.ace.Launcher start

If I kill -9 pid 10 the container stops (probably expected)

Some other things:

• /var/lib/mongodb is empty... is that intended?
• In /var/log no other log files seem to have any info on what is happening (Any other place to look)
• I tried upgrading to a 5.4.16 image, and then a 5.5.11 image and am getting the same result.

I typically am competent at troubleshooting, but I am at a loss on how to approach this. Ideally I'd like this to work without having to start from scratch and readopt and setup my network... Anything would be appreciated.

John

SSL_ERROR_NO_CYPHER_OVERLAP from browser when attempt to access Unifi web portal

Host operating system

Open Media Vault 3.0.80 (Erasmus)

What tag are you using

Stable

What complete docker command or docker-compose.yml do you use to launch the container (omitting sensitive values)?

IMAGE OF CONFIG FOR DOCKER CONTAINER

What do you expect to happen?

What actually happens?

After a recent docker container upgrade I have stopped being able to access the web portal (port: 8443) and get the following browser error:
Cannot communicate securely with peer: no common encryption algorithm(s). Error code: SSL_ERROR_NO_CYPHER_OVERLAP

I have checked the directory layouts as per the new changes (eg. changed /unifi/lib to /unifi/data) and set the relevant privileges.
I also tried the solution given here and restarted but have not had any luck.

The output from docker-healthcheck.sh gives this error:

curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

I am not sure what else to try here, I have not done anything unusual to this container. Has anybody else experienced this?

can't connect to controller since 5.5.24

Host operating system

Synology DSM

What tag are you using

Example: 5.5.24

What actually happens?

I was using your 5.5.20 image without issues. I now upgraded to your 5.5.24 image and now Chrome tells me:

This site can’t provide a secure connection

controller.internal.headincloud.be uses an unsupported protocol.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
HIDE DETAILS
Unsupported protocol
The client and server don't support a common SSL protocol version or cipher suite.

I tried mapping my data logdir to the new paths (/unifi/data and /unifi/log instead of /var/lib/unifi and /var/log/unifi), but this makes no difference.

This is the log from the container:

2017-10-16 20:16:01 | stdout | [2017-10-16 22:16:01,242] <docker-entrypoint> WARNING: Running UniFi in insecure (root) mode
2017-10-16 20:16:01 | stdout | [2017-10-16 22:16:01,240] <docker-entrypoint> Starting unifi controller service.
2017-10-16 20:16:01 | stdout | [2017-10-16 22:16:01,228] <docker-entrypoint> Done!
2017-10-16 20:16:01 | stdout | Unable to import the certificate into keystore
  |   |  
2017-10-16 20:16:00 | stdout | [2017-10-16 22:16:00,054] <docker-entrypoint> Importing cert into Unifi database...
2017-10-16 20:15:59 | stdout | keytool error: java.lang.Exception: Source keystore file exists, but is empty: /tmp/tmp.rwH5Asisiy
2017-10-16 20:15:59 | stdout | [2017-10-16 22:15:59,365] <docker-entrypoint> Inserting certificate into Unifi keystore...
2017-10-16 20:15:59 | stdout | keytool error: java.lang.Exception: Alias <unifi> does not exist
  |   |  
2017-10-16 20:15:58 | stdout | [2017-10-16 22:15:58,761] <docker-entrypoint> Removing existing certificate from Unifi protected keystore...
2017-10-16 20:15:58 | stdout | pkcs12: Use -help for summary.
  |   |  
2017-10-16 20:15:58 | stdout | pkcs12: Cannot open input file /unifi/cert/cert.pem, No such file or directory
2017-10-16 20:15:58 | stdout | [2017-10-16 22:15:58,753] <docker-entrypoint> Using openssl to prepare certificate...
2017-10-16 20:15:58 | stdout | md5sum: /unifi/cert/cert.pem: No such file or directory
  |   |  
2017-10-16 20:15:58 | stdout | [2017-10-16 22:15:58,749] <docker-entrypoint> Cert has changed, updating controller...
2017-10-16 20:15:58 | stdout | x509: Use -help for summary.
  |   |  
2017-10-16 20:15:58 | stdout | x509: Cannot open input file /unifi/cert/cert.pem, No such fil
e or directory
2017-10-16 20:15:58 | stdout | [2017-10-16 22:15:58,461] <docker-entrypoint> Cert directory found. Checking Certs

Issue when starting the docker

After shutting down and restarting the docker this is what i get

Starting unifi controller service.
WARN: unifi service process ended without being singaled? Check for errors in /var/log/unifi.

Custom SSL Certificate quick config

I'm working on building in custom ssl certificates. My thinking is add a new volume say /config/ for image specific configuration (to allow expansion of more quick configuration options)
then put your entire keychain in say /config/ssl.pfx. Then to trigger a new certificate you would delete /usr/lib/unifi/data/keystore and restart your container.

Posting this so if anyone wants to give any input on the feature design ahead of time they can.

ARM Support

I do not presently have any working ARM systems but I am trying cross building this image to run on ARM systems through qemu.

Change standard ports to any other

Standard ports used by Unifi controller are very well-known and I had quite huge numbers of attempts to break in.
Now I am using non-standard ports and there are no connections from unknown locations.

Unifi Controller has a simple way to change it in the system.properties file

## device inform
# unifi.http.port=8080
## controller UI / API
# unifi.https.port=8443

Would you be able to add Environment Variables to manage it as you already have support to change settings for MongoDB?

It could be some code before confSet

if [ -z "$UNIFI_HTTP_PORT" ]; then
  settings["unifi.http.port"]="8080"
elif
  settings["unifi.http.port"]="UNIFI_HTTP_PORT"
fi

if [ -z "$UNIFI_HTTPS_PORT" ]; then
  settings["unifi.https.port"]="8443"
elif
  settings["unifi.https.port"]="UNIFI_HTTPS_PORT"
fi

OpenJDK 64-bit Server Warning

When I install the docker I get the following in the console log
OpenJDK 64-bit Server Warning : You have loaded library /usr/lib/unifi/native/Linux/amd64/libubnt_webrtc_jni.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It is highly recommended that you fix the library with 'execstack -c , or link it with 'noexecstack'

I do get a URL that shows:
HTTP status 400
description: The request sent by the client was syntactically incorrect.

I'm trying to load this in container station for QNAP.

GPG Keyserver for gosu key intermittently fails

Host operating system

macOS High Sierra 10.13

Docker Version

Client:
 Version:      17.09.0-ce
 API version:  1.32
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:40:09 2017
 OS/Arch:      darwin/amd64

Server:
 Version:      17.09.0-ce
 API version:  1.32 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:45:38 2017
 OS/Arch:      linux/amd64
 Experimental: false

What tag are you using

Example: beta

What complete docker command or docker-compose.yml do you use to launch the container (omitting sensitive values)?

docker build -t unifi-beta --build-arg PKGURL=<unifi-beta-controller-url>/unifi_sysvinit_all.deb .

What do you expect to happen?

Command within Dockerfile to retrieve the PGP key should succeed, and then proceed to import it/continue as normal.

What actually happens?

[...]


2017-10-16 06:31:30 (33.1 MB/s) - '/usr/local/bin/gosu.asc' saved [543/543]

+ mktemp -d
+ export GNUPGHOME=/tmp/tmp.8DN8Bjgz7Y
+ gpg --keyserver ha.pool.sks-keyservers.net --recv-keys B42F6819007F00F88E364FD4036A9C25BF357DD4
gpg: keybox '/tmp/tmp.8DN8Bjgz7Y/pubring.kbx' created
gpg: keyserver receive failed: Cannot assign requested address

If I run the same gpg --keyserver ha.pool.sks-keyservers.net --recv-keys B42F6819007F00F88E364FD4036A9C25BF357DD4 command on my host system (same network path to the keyserver), I also observe an error. The GPG version is different, so the output differs a little:

gpg: keyserver receive failed: No data

Similar issue reported elsewhere

This is the same issue as reported in this other project's issue, and it is not specific to that project nor this one, but just an issue with the particular GPG keyserver that is being used: tianon/gosu#35

There is a workaround suggested in that issue thread for trying several explicit keyservers until the command succeeds, since it appears that if a single server within a pool fails, the client just aborts entirely. Would you be open to having something like that implemented to handle this situation?

Error starting up on Raspberry Pi 3

I'm trying to run the docker image on a Raspberry Pi 3 but docker run and docker build both fail with:

standard_init_linux.go:178: exec user process caused "exec format error"

System details

$ lsb_release -a
Distributor ID:	Raspbian
Description:	Raspbian GNU/Linux 8.0 (jessie)
Release:	8.0
Codename:	jessie

$ uname -a
Linux aloy 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 armv7l GNU/Linux

Errors during docker build

On running docker build -t unifi-controller-arm:0.0.1 ./Dockerfile I get the following error:

standard_init_linux.go:178: exec user process caused "exec format error"

Removing intermediate container ee2097b6333a
Step 5/19 : RUN echo "deb http://deb.debian.org/debian/ jessie-backports main" > /etc/apt/sources.list.d/10backports.list &&   echo "deb http://www.ubnt.com/downloads/unifi/debian unifi5 ubiquiti" > /etc/apt/sources.list.d/20ubiquiti.list &&   apt-key adv --keyserver keyserver.ubuntu.com --recv C0A52C50
 ---> Running in 92d58b1e9a16
standard_init_linux.go:178: exec user process caused "exec format error"
The command '/bin/sh -c echo "deb http://deb.debian.org/debian/ jessie-backports main" > /etc/apt/sources.list.d/10backports.list &&   echo "deb http://www.ubnt.com/downloads/unifi/debian unifi5 ubiquiti" > /etc/apt/sources.list.d/20ubiquiti.list &&   apt-key adv --keyserver keyserver.ubuntu.com --recv C0A52C50' returned a non-zero code: 1

Any ideas?

Timezone not setting correctly

Host operating system

Ubuntu 16.04 4.4.0-97-generic

What tag are you using

latest; 5.6.19 stable, but was happening on all 5.6.xx-sc

What complete docker command or docker-compose.yml do you use to launch the container (omitting sensitive values)?

version: '2.2'
services:
unifi:
image: jacobalberty/unifi
init: true
ports:
- 8080:8080
- 8443:8443
- 8843:8843
- 8880:8880
- 3478:3478/udp
environment:
PUID: 1000
PGID: 1000
TZ: America/Denver
volumes:
- /apps/unifi/config:/var/lib/unifi
- /apps/unifi/logs:/var/log/unifi
- /apps/unifi/run:/var/run/unifi

Note: A screenshot of your configuration page if using a gui is acceptable

What do you expect to happen?

Graph times set to America/Denver timezone

What actually happens?

The time in all graphs in the controller are off by +6 hours, not sure if it is my config or a bug in unifi