Migrating existing Ubiquiti UniFi Controller to Docker in Synology NAS

Ubiquiti Migrating existing Ubiquiti UniFi Controller to Docker in Synology NAS

Currently reading
Ubiquiti Migrating existing Ubiquiti UniFi Controller to Docker in Synology NAS

@jeyare is there any major difference with this guide: Installing Unifi on Synology

Take note at step 9, where the mount path is /unifi (instead of /var/lib/unifi). And take note of step 11 (BIND_PRIV and RUNAS_UID0) set to false.

My main question is step 11, by setting these two options to false, does that not make the container (or controller) run as root? Is this better in terms of security? Also, regarding step 9 the mount path, is Unifi eventually changing something on their end. I thought I read somewhere that their stuff will be looking for a /unifi directory??

Obviously this stuff is like a second language to me and I still dont yet full understand everything. However, I was able to get Docker and the controller running, and I just did my first test with updating the controller version (docker image?) to the latest with ease.
 
@jeyare is there any major difference with this guide: Installing Unifi on Synology
mentioned guide is from: June 15th 2020
when you check /Builds at Docker source page for this period, there was valid 5.13 and new description also
my tutorial was written in 2019 for 5.10 (still valid)

mount path is /unifi (instead of /var/lib/unifi)
there was a main change in Volume mounting, described by the container author also:
This is a single monolithic volume that contains several subdirectories, you can do a single volume for everything or break up your old volumes into the subdirectories
Conclusions:
no changes there, just more options

And take note of step 11 (BIND_PRIV and RUNAS_UID0) set to false.

Run as non-root User

It is suggested you start running this as a non root user. The default right now is to run as root but if you set the docker run flag --user to unifi then the image will run as a special unfi user with the uid/gid 999/999. You should ideally set your data and logs to owned by the proper gid. You will not be able to bind to lower ports by default. If you also pass the docker run flag --sysctl with net.ipv4.ip_unprivileged_port_start=0 then you will be able to freely bind to whatever port you wish. This should not be needed if you are using the default ports.
Conclusions:
no changes there, just more options
------------------
Conclusion:
when you will read carefully, you will see, that both described guides are still valid (my) and also your link (what is just a Copy/Paste from Jacob's guide).
 
@jeyare Thank you for your response.

Based on the below author note, that its is urged to move to the new volumes ASAP, is this something where we should change the mount path from /var/lib/unifi to just /unifi ? Again, I do not understand what the difference or significance between one or the other, just looking for your professional recommendation on proper set up and best practice. Unfortunately I grew up on only the Windows OS, so I'm aces in that field; this other stuff I only have my toes in so far.



there was a main change in Volume mounting, described by the container author also:
This is a single monolithic volume that contains several subdirectories, you can do a single volume for everything or break up your old volumes into the subdirectories
Conclusions:
no changes there, just more options

Author also notes this: "

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
 
Last edited:
it's just a cosmetic tune:
till 5.13 was valid old mount structure
from 5.13 is valid new mount structure defined by author of the container

You can use the new one
-- post merged: --

A simplification:
from the WinOS point of view it's same when you change targets (and move the data) from:
C:\Windows\SystemApps\Unifi
to
C:\Program Files\Unifi\data
 
out of curiousity, is there any reason I should not be accessing the dockerized controller via a unifi.myname.synology.me reverse proxy? I've managed to get it set up, and it allows me to access the controller remotely via the phone app, but I didn't know if there is a security concern with doing so.

I have noticed 2 "web socket" errors when I first open the controller this way, but those errors immediately go away and are not present in the "Alerts" list. I have not seen the web socket error when connecting directly via IP address.
 
out of curiousity, is there any reason I should not be accessing the dockerized controller via a unifi.myname.synology.me reverse proxy? I've managed to get it set up, and it allows me to access the controller remotely via the phone app, but I didn't know if there is a security concern with doing so.

I have noticed 2 "web socket" errors when I first open the controller this way, but those errors immediately go away and are not present in the "Alerts" list. I have not seen the web socket error when connecting directly via IP address.
I’ve read to go into the rp rule then custom headers and create websocket. Not sure if this is the 100% fix but I stopped receiving the websocket error
 

Attachments

  • 4EEADD6D-D244-4D6B-97ED-EBC5E54CE8E3.png
    4EEADD6D-D244-4D6B-97ED-EBC5E54CE8E3.png
    348 KB · Views: 28
WAN access to the controller is OK, when you have:
- VPN enabled at controller side and remote device side (phone, computer)
- strong user/psw ..... >40 characters mixed (lowercase, uppercase, numbers, special characters)

My personal advice- never use enabled unifi.cloud access.
And finally you need tune your extremely customizable firewall rules:

more details explained here
one interesting picture from the link

1606460546826.png
 
Thanks. I did it more out of curiosity if I could than any actual need for it.

Just to be clear, a RP for something like bitwarden is ok while a RP for the unifi controller needs much more security is because you are bypassing all of the unifi firewall and giving direct access to unifi settings with the unif RP?
 
Last edited:
Regarding the RP:
RP isn’t in itself safe area. You need use all possible security levels to stay safe.

One of the powerful firewall rule is:
WAN local ... definition what kind of connection is possible to router from WAN
usage:
- e.g. for a remote site with static public IP

More you can find in official Unifi KB:
there is also WAN IN rules group - traffic from WAN through the router to chosen LAN. There is a place to drop almost 95% of unwanted traffic as port scanners, pings, ...

there is also LAN Local, what LAN IP or subnet is able to connect to the controller.
and x-next setup options
-- post merged: --

from Unifi era in all my network sites I have empty IP block list in my NASes = every single attempt is blocked at Unifi level.
 
Does anyone use a memory limit for this Unifi image in a docker container? Can someone suggest what a reasonable memory limit would be for one site (home network), 4 devices (2 aps and 2 switches). Currently the container is using up around 6-900mb of ram, wondering if this needs to be that large.
 
Personally no, but imho, 200-300MB should be ok for any scale.
I once had a limit on it and saw no issues. Few months ago I removed it and today I noticed dsm log in was slow, received an err email stating memory was low. I’m going to put the memory limit back on since I didn’t see any negative affect.

I also had a vm of dsm 7.2 running and I only turn that on once in a while so that is what ultimately led to the memory error. Other than that I’m usually good.
 
If you are using the jacobalberty image i found that below 500Mb the image becomes unstable during unifi devices firmware updates. At 256Mb mine immediately crash after trying to delete a log entry from gui. 500Mb looks good and prevent the image to eat 900Mb-1Gb of memory
 
It appears that the Jacobalberty image may have been abandoned, It hasn't been updated in over 2 months. Some comments on the Github has others coming to the same conclusion as there has been no response from Jacobalberty. I have also seen that someone forked the project to bring the project up to date.

If this is truly the case, can someone provide some sort of resource on how to either change the image or configure a new setup?
 
I hope it hasn’t been abandoned as it’s such a simple process to keep this running.

it still has one of the latest v7.5 updates available from memory, just hadn’t updated to the new v8 stream as yet. I’d read in the forums of numerous issues so wasn’t in a hurry to update just yet (I only run UniFi at home), however would have at some point. Hopefully just waiting for a more stable release, although the lack of communication sounds ominous.
 
Hopefully is the case where they’re waiting for v8 to mature. But in the event this is truly abandoned, I hope there’s some other project just as easy.

We shall see
 
Unifi Network controller has been in a rapid-fire release schedule for all the new features and hardware they are bringing out. With all the updates I would agree with @Gerard that the dust of v8 needs to settle before being worked on in the docker image. Because I am early release for some hardware, I had to move my controller to a VM in Proxmox from my Synology earlier this year.
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Back
Top