Installing UnifiOS in a container (incus) on Goldeye

Having seen that the docker container option for Unifi Network is now coming to an end, I decided to see if I could make the new replacement option (UnifiOS) work in a container on Goldeye, since that seems to be the least wasteful way (IMHO) to run it.

I was successful.

Here’s what I did:

After setting up Containers in the UI (selecting a pool and a bridge), I created a new container (which I later had to delete, but maybe this was important in some way to initialize the system properly, so I won’t leave it out). Since the install failed in that container, I did some research about incus (the container manager used in Goldeye) and I found this:

https://discussion.scottibyte.com/t/self-hosted-unifi-os-in-an-incus-container/673

It was really helpful, but not complete for Goldeye.

So I worked at it for a bit and came up with these steps:

You must first create a network profile:

Since I’m using the macvlan type, I called it macvlan:

incus profile create macvlan

Then I assigned it to the bridge I use for my main network (br01) and gave the interface a name for inside the container (eth0):

incus profile device add macvlan eth0 nic nictype=macvlan parent=br01

Since I was creating the container from the CLI (GUI doesn’t allow all the options I needed), I had to also figure out the storage, which turned out to be the name of the pool I gave when setting up containers, but I used this command to check first:

incus storage list
+------+--------+-------------+---------+---------+
| NAME | DRIVER | DESCRIPTION | USED BY |  STATE  |
+------+--------+-------------+---------+---------+
| nvme | zfs    |             | 2       | CREATED |
+------+--------+-------------+---------+---------+

So I could see the “NAME” I needed to use… (although I could have easily guessed that as it’s the name of the pool).

Then I was ready to create the container:

incus launch images:debian/13 UnifiOS \
  -p default \
  -p macvlan \
  -s nvme \
  -c boot.autostart=true \
  -c security.nesting=true \
  -c security.privileged=true \
  -c security.syscalls.intercept.sysinfo=true \
  -c raw.lxc="lxc.apparmor.profile=unconfined
lxc.cgroup.devices.allow = a * rwm
lxc.mount.auto = proc:rw sys:rw"

Which went OK (note “-p macvlan” specifies the network profile and “-s nvme” specifies the name of the pool/storage to be used for the container… change those if you followed your own naming)

Then I had a running container with all the nice incus stuff done to make UnifiOS work inside it.

So next task was to install it, but first we need to get root access inside the container (which has fortunately appeared in the GUI). I prefer to run in my own terminal, so I needed to set a root password in order to use the incus console command (which demands login), so from the shell (all the way at the bottom of the GUI on the right with that container selected), I typed:

passwd

Followed the prompts to set and retype the password I wanted.

Then back in my shell to the TrueNAS host:

incus console UnifiOS

Then login with root and the password I set above and we’re off to the races.

apt update && apt upgrade -y

Then:

apt install curl wget podman kmod nano net-tools openssh-server -y

openssh-server is optional (I will use it later myself to avoid the need to go via the TrueNAS host and incus to get a console in future).

Finally, installing the UnifiOS package:

wget https://fw-download.ubnt.com/data/unifi-os-server/1856-linux-x64-5.0.6-33f4990f-6c68-4e72-9d9c-477496c22450.6-x6

You may want to go and check if there’s a later release on:

https://www.ui.com/download

and replace the url if so… also replacing the name of the file in the next 2 commands:

chmod +x 1856-linux-x64-5.0.6-33f4990f-6c68-4e72-9d9c-477496c22450.6-x64

./1856-linux-x64-5.0.6-33f4990f-6c68-4e72-9d9c-477496c22450.6-x64

With that, you should be asked if you want to install UnifiOS… press Y and wait a bit.

You will be presented the URL to visit to get to your UnifiOS console at the end of the process if it all went well.

Browse there and you’re good to go.

I was able to take a backup from my old docker Unifi Network application (produces a .unf file) from the Settings | System | Backups tab, electing to download with all data included.

I then shut down the old container and on the start page of UnifiOS, elected to restore, providing the .unf file via upload.

Minutes later, my whole network had swapped over and everything was as before, but a little better (since I now had the option to run innerspace too and application updates will be managed by Unifi in the future rather than docker).

Hope this helps someone.

3 Likes

Missed that memo; mind providing a link so I can read into this?

I still see updates upcoming here → Update UniFi Network Application to v10.1.85 by github-actions[bot] · Pull Request #866 · jacobalberty/unifi-docker · GitHub so I dunno if it’s something else he’s referring too

The last 2 times I updated the container, I had a pop-up (which I didn’t screenshot).

I googled it (unifi network docker popup unifi os) and the AI response said this…

Users running the UniFi Network Application in Docker are increasingly encountering pop-ups prompting them to switch to the official

“UniFi OS Server”. This shift is part of Ubiquiti’s move toward a more integrated, self-hosted platform (comparable to their official hardware) rather than just the standalone application.

Just update your container (maybe something at or over 10.1.85) and you’ll see it on first login.

Also I saw this, so I’m not completely imagining it…

https://community.ui.com/questions/Local-backup-not-available-anymore-Upgrade-to-self-hosted-Unifi-OS-Server-5-0-6/c0bbfb54-e8bf-4519-a67d-02c9d4a5514e

Weird - haven’t gotten any pop-ups yet on my end. Well if it does happen then I appreciate the guide.

Still hoping I don’t have to deal with it :stuck_out_tongue:

Naw you’re not crazy, also the maintainer is getting busy so dunno when the Docker container gets updated

I’m also going to test the Unifi-OS-Server container that this individual created

I installed the lemker in a dockge stack over the weekend. It works fine (my main issue was my own fault for setting the inform address to a FQDN, which didn’t work - should have used the IP!).

I thought it was running a bit laggy - it’s quite slow to start up, and a bit of a resource hog, so I’ve just installed the official app, in podman, in a Ubuntu Server VM instead (local on my TrueNAS instance, not a hosted droplet), as per:

Works fine - but still a bit laggy when loading the webUI - although that may be an issue with my reverse proxy, since loading via IP is fine.

1 Like

I’m curious to know how the dockerized version of that will work when it comes to needing an update. Will it be the backup of settings, refresh with the new container version, then restore?

Also, not sure how much it will matter or if it’s less of an issue now, but having a dedicated Macvlan tap with a linux container (incus for now) seems cleaner to me than using docker networking.

The MACVLAN will help you for discovery and all, but my transition to the Container on Docker of the lemker/unifi-os-server was butter smooth, restored config, and no issues. Even updated inside the Unifi OS Server the version of the “Network” app to 10.1.85 and it was perfect.

I was asking more about the item at the top of that screen (UniFi OS Server), not the Network application.

As it is likely to be updating the OS of the container somehow, not just the podman application container, I guess there may be some more fundamental issues with it being a container which could later go through a recreate event, meaning something could be lost there.

Anyway, whatever works for you, not wanting to criticize.

1 Like

Yeah no worries, I really cared about the Network application, but as long as I can move in and out, the Unifi Control Plane’s Backup section actually allows you to backup/save all or individual parts (the Unifi AP icon is Network, and the Gear is Unifi OS Server)