jcberthon / unifi-docker Goto Github PK

Similar to issue #2 there is an issue when creating Kubernetes containers that volumes are created with root ownership kubernetes/kubernetes#2630 . While the runtime does appear to be able to write into the volume without issue, the unifi.init script detects that the folder has UID/GID ownership of 0 . Commenting out that check to bypass creates a stateful container that persists through deletions.

I created everything you did here after finding this fork off of a write up on Reddit I found. I replicated the entire site - actually several times and have attempted to import my old site running on Windows to this server / docker. At the beginning, with the data folders mapped to my home directory as in your README, I select to restore from a backup and upload my file. As soon as that happens the site goes to "reboot" but just shuts down. With Portainer I see it's stopped and I then restart it, which looks like it collected the data but I can never log in. The password is blown up and even docker exec bashing in and playing with Mongo I can find no data. It actually looks like it's looking in an empty database, one that isn't in the data folder at all. At that point I'm unable to continue and have tried multiple things to get this working.

Any ideas on what else I can try? I did try to start the container, go through the wizard, then import my site with the same results. Import, does stuff, reboots, and back to the same instance but no data import. Imported back to my old controller to troubleshoot and it works there. Thanks in advance. Let me know what data I can put together if needed.

Since Unifi Controller 5.7 and for the LTS branch for 5.6.36 and newer (the 5.6.31 was still working), the controller fails to start with the following error:

unifi cannot start. Please create unifi user, and chown -R unifi /var/lib/unifi /var/log/unifi /var/run/unifi

The problem is due to capabilities. I will have to remove a security feature I had implemented and which worked since last summer because Unifi messed-up the feature.

Actually, back in summer 2017, I implemented several security feature in my Unifi Controller container. First I dropped all capabilities (Linux privilege access feature) and then I created a Unifi user which run the controller instead of root. Unifi has since been implementing these features which broke several times my container. And lastly I'm very annoyed because they do try to dropped a lot of capabilities, but before doing that they increase their capability set. Therefore forcing me to increase mine at the container level. But at the container level I control the set for both their Java application (for which they drop some) but also for the MongoDB database (for which they do not drop any). Therefore I'm not happy that the obvious solution to fix the issue (increasing the capability set) will reduce the overall security of my container. Not cool Unifi!

Ubiquiti has now 5.7 has the stable branch and 5.6 as the old stable or LTS.

Automated build needs to be updated to reflect the new versioning.