[Support] Linuxserver.io - Unifi


Recommended Posts

On 17/11/2015 at 7:07 AM, dirtysanchez said:

 

It's not related to bridge mode. The AP doesn't know where the controller is unless you have your DHCP server specifically set up to issue the controller address as an option in the lease. Normally you would use the UniFi discovery tool to find the AP and tell it the IP of the controller, but the UniFi dockers don't have the discovery tool as it is a separate app.

 

To get the AP to show up in the controller so it can be adopted and provisioned, do the following:

 

Determine the IP the AP was leased

SSH to that IP

Login as ubnt / ubnt

mca-cli

set-inform http://address:port/inform (where address is IP of controller and port is the port you are using for inform, default is 8080)

 

Once you run the set inform command it should show in the controller. As soon as you click adopt you need to run the set inform command a second time on the AP.

 

  • Like 1
Link to comment

Hello all.

 

If I wanted to move from the other UniFi controller docker to this one, is there a "simple" migration path?

 

Can I simply backup my old config from within the UniFi controller app, install this docker, disable the old docker, run up this one and import my config? I'm trying to avoid having to set everything up from scratch again as it was a right pain last time!

 

Many thanks :)

Link to comment
2 minutes ago, page3 said:

Hello all.

 

If I wanted to move from the other UniFi controller docker to this one, is there a "simple" migration path?

 

Can I simply backup my old config from within the UniFi controller app, install this docker, disable the old docker, run up this one and import my config? I'm trying to avoid having to set everything up from scratch again as it was a right pain last time!

 

Many thanks :)

 

We don't have any migration guide as this is nothing we test. 

I guess it's only the config that needs to be in the correct place. I haven't tried the other docker, so don't know where that one saves the config. 

Make a backup of the appdata folder and then point our container to the same folder and see if it works. 

Link to comment
42 minutes ago, saarg said:

 

We don't have any migration guide as this is nothing we test. 

I guess it's only the config that needs to be in the correct place. I haven't tried the other docker, so don't know where that one saves the config. 

Make a backup of the appdata folder and then point our container to the same folder and see if it works. 

 

Wow, quick response!

 

Unfortunately, the other docker only keeps logs within the appdata folder, everything else must be within the docker image which seems a bit unusual. This is why I'm keen to move to the Linuxserver.io one.

 

I'm hoping I can do a config back from within the UniFi controller app (.unf file). I can then hopefully import that once I get to the Set-up screen on the UniFi controller on this docker. 

 

*** UPDATE ***

Just for information. I installed the Linuxserver.io docker. Restored the .unf file from my previous docker and all is up and running in under 5 minutes.

 

I now have my config on my cache in an accessible place, rather than from within the docker image.

Edited by page3
Link to comment
3 hours ago, page3 said:

 

Wow, quick response!

 

Unfortunately, the other docker only keeps logs within the appdata folder, everything else must be within the docker image which seems a bit unusual. This is why I'm keen to move to the Linuxserver.io one.

 

I'm hoping I can do a config back from within the UniFi controller app (.unf file). I can then hopefully import that once I get to the Set-up screen on the UniFi controller on this docker. 

 

*** UPDATE ***

Just for information. I installed the Linuxserver.io docker. Restored the .unf file from my previous docker and all is up and running in under 5 minutes.

 

I now have my config on my cache in an accessible place, rather than from within the docker image.

 

Good you got it sorted :)

Link to comment

Help,

 

Fresh install of the docker.  Made sure the /config mapping is correct, made sure the UID and GID map to correct ID numbers from unraid.  On startup the MongoDB server won't run, it crashes with a fatal assertion:

 

LogFile::synchronousAppend failed with 8192 bytes unwritten out of 8192 bytes;  b=0x3786000 errno:22 Invalid argument

2017-12-25T20:30:41.286-0600 [initandlisten] Fatal Assertion 13515
2017-12-25T20:30:41.291-0600 [initandlisten] 0xedb3e9 0xe6fb3f 0xe4a1c1 0xe7039b 0x8869fa 0x886f3a 0x88ea86 0x87d184 0x61f92f 0x620903 0x5e943c 0x2b47beb77830 0x61a2d9 
 bin/mongod(_ZN5mongo15printStackTraceERSo+0x39) [0xedb3e9]
 bin/mongod(_ZN5mongo10logContextEPKc+0x21f) [0xe6fb3f]
 bin/mongod(_ZN5mongo13fassertFailedEi+0x71) [0xe4a1c1]
 bin/mongod(_ZN5mongo7LogFile17synchronousAppendEPKvm+0x29b) [0xe7039b]
 bin/mongod(_ZN5mongo3dur20_preallocateIsFasterEv+0x22a) [0x8869fa]
 bin/mongod(_ZN5mongo3dur19preallocateIsFasterEv+0x2a) [0x886f3a]
 bin/mongod(_ZN5mongo3dur16preallocateFilesEv+0x966) [0x88ea86]
 bin/mongod(_ZN5mongo3dur7startupEv+0x74) [0x87d184]
 bin/mongod(_ZN5mongo14_initAndListenEi+0x76f) [0x61f92f]
 bin/mongod(_ZN5mongo13initAndListenEi+0x23) [0x620903]
 bin/mongod(main+0x23c) [0x5e943c]
 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x2b47beb77830]
 bin/mongod(_start+0x29) [0x61a2d9]
2017-12-25T20:30:41.291-0600 [initandlisten] 

***aborting after fassert() failure

 

 

---- Edit ----

 

More info, to help tshoot.

I have verified file permissions match up, plus it's obviously writing out the files to the /appdata/unifi folder as I'm able to get the logs.

It's not a port issue as I have mapped it to it's own IP address on a seperate NIC and I'm able to ping the unique IP for the container.

I have tried to wipe the /appdata/unifi folder and restart and just repeats with the same errors over and over.  

I cannot let it run for long as  the log files get gigantic.

I have tried wiping the image and redownloading with no luck.

I saw before someone else had the same error and had to switch to another docker image, that docker image is what I'm trying to move away from as it has several bugs of it's own.

 

 

--- Edit 2 ----

From what I can tell this is an error that the MongoDB can't write out correctly. Which is strange as it's creating all the files and the log files.  Is there a specific filesystem format that has to exist for this to run?  My cache drive (where appdata is) is formatted as XFS.

 

 

---Edit 3---

 

It just started working after stopping and starting enough times.  Truly odd.

Edited by kingfetty
More info
Link to comment
On 22/11/2016 at 9:36 PM, CHBMB said:

 

OK, should have been fixed in V6.2.4 of unraid.  As an aside, you'll get much better performance from your docker containers if you can put the appdata on a cache disk. 

 

I had similar problems with this.

 

but instead of "/mnt/disk1/appdata/unifi/" i had to change it to "/mnt/cache/appdata/unifi/"

 

The previous setting "/mnt/user/appdata/unifi/" generated lots of these error messages:

 

Dec 27 13:12:34 FoxServer shfs/user: err: shfs_write: write: (22) Invalid argument

Link to comment
  • 2 weeks later...

There's a lot of info here so forgive me if I've overlooked a reply that addresses it already, but how come you have to run set-inform on new devices? On my old UniFi setup (running on a Windows machine on my local network) I never had DHCP options set to tell it what IP to look at, and the APs were always able to find the controller and be adopted without issue, but with this container I have to run set-inform on everything to get it to find the controller now? Why is that?

Link to comment
3 hours ago, CorneliousJD said:

There's a lot of info here so forgive me if I've overlooked a reply that addresses it already, but how come you have to run set-inform on new devices? On my old UniFi setup (running on a Windows machine on my local network) I never had DHCP options set to tell it what IP to look at, and the APs were always able to find the controller and be adopted without issue, but with this container I have to run set-inform on everything to get it to find the controller now? Why is that?

Because the docker internal  IP is NATTED  from the general network, so the IP that is broadcast from the  controller isn't directly reachable by the devices. You have  to tell the devices which IP address will allow them to access the docker.

  • Like 2
Link to comment
19 hours ago, jonathanm said:

Because the docker internal  IP is NATTED  from the general network, so the IP that is broadcast from the  controller isn't directly reachable by the devices. You have  to tell the devices which IP address will allow them to access the docker.

 

Thanks for the explanation! Much appreciated.

Link to comment
22 hours ago, CorneliousJD said:

I've noticed I end up in an adoption loop now after rebooting my server... 

 

DHCP option is even set to the unRAID server IP too.

 

Any advice on this?

 

So I had an old UAP-AC-v2 (Square one) and I ended up just buying a UAP-AC-Pro yesterday and at the same time I just removed the docker and all appdata and recreated it with a fresh set of settings as my old one was using imported settings.

 

Using DHCP options also I do not have to set the inform URL and it works across reboots now. Not sure if it was the AP itself or the reload of the container from scratch, but it's working now!

Link to comment
55 minutes ago, CorneliousJD said:

 

So I had an old UAP-AC-v2 (Square one) and I ended up just buying a UAP-AC-Pro yesterday and at the same time I just removed the docker and all appdata and recreated it with a fresh set of settings as my old one was using imported settings.

 

Using DHCP options also I do not have to set the inform URL and it works across reboots now. Not sure if it was the AP itself or the reload of the container from scratch, but it's working now!

 

Okay I lied... it's back to doing an adopting/disconnected loop every single time I reboot the unRAID server - not sure why it worked for a few times there - Nothing has changed?!

Link to comment

Okay I'm really not sure what was the cause, but setting this to wait 30 seconds to startup with the CA docker autostart manager let things work correctly after each reboot now. Still working fine after 6.4 update.

 

Very strange but it's running normally for now it seems. Sorry for all the posts, wanted to come back and give my resolution incase someone searches later.

Link to comment
On 12/2/2017 at 8:11 AM, orlando500 said:

I didnt read the posts above. But doing so helped me to... 

Setting the config to host mode fixed my problems. Thanks

 

When I update the UniFi docker in Bridge mode, my adopted devices do not reconnect. If I power cycle them, they all connect in UniFi (still in Bridge mode). Next time the docker is updated, I have to again power cycle all of my UniFi devices to get them to reconnect in the UniFi Controller. This is annoying and a fairly new issue as of late 2017.

 

Now that I set the UniFi docker in Host mode, I can update UniFi or restart the docker and all of my UniFi devices connect immediately as you would expect. Setting the docker back to Bridge mode brings back my issues.

 

So leaving the docker in Host mode makes everything work as I'd expect and want. Is the solution to leave it in Host mode, or should I be coming up with a better solution that puts the docker back in Bridge mode and resolves these device connecting issues? Thanks!

Link to comment

I fixed all my adoption/connection issues by just giving the container a static IP with the new feature in 6.4

 

Zero issues since then.

 

Host most also works but it sounds like there's a port that's not being mapped from the template that's causing everyone issues.

Host mode works, but for me it's easier since UniFi uses so many dang ports to just give it a static IP under br0.

  • Like 1
Link to comment
On 1/14/2018 at 4:19 PM, unTER said:

So leaving the docker in Host mode makes everything work as I'd expect and want. Is the solution to leave it in Host mode, or should I be coming up with a better solution that puts the docker back in Bridge mode and resolves these device connecting issues?

 

Bridge mode is the least desired mode to work with.

  1. It has network performance degradation due to the NAT function

  2. All ports need to be explicitedly configured/mapped otherwise connectivity breaks

 

I recommend for docker containers which require many ports to function (like unifi) to configure them on their own IP address. This is possible in unRAID 6.4.

  • Like 1
Link to comment
14 minutes ago, bonienl said:

Bridge mode is the least desired mode to work with.

  1. It has network performance degradation due to the NAT function

  2. All ports need to be explicitedly configured/mapped otherwise connectivity breaks

Severe container isolation isn't always a bad thing. I'd rather open holes in the NAT to keep track of things. Sometimes it's nice to keep a nice tidy list of what apps need what ports, and only allow what is absolutely necessary.

 

I wouldn't call best security least desired.

Link to comment
19 minutes ago, bonienl said:

 

Bridge mode is the least desired mode to work with.

  1. It has network performance degradation due to the NAT function

  2. All ports need to be explicitedly configured/mapped otherwise connectivity breaks

 

I recommend for docker containers which require many ports to function (like unifi) to configure them on their own IP address. This is possible in unRAID 6.4.

 

Isn't that still technically using a bridge if you have 1 ethernet port?  Br0.11/Br0.10/etc...

Link to comment
3 hours ago, smdion said:

 

Isn't that still technically using a bridge if you have 1 ethernet port?  Br0.11/Br0.10/etc...

 

Yes that's a bridge too, same in name but different in operation. The bridge function of Docker uses address translation and consequently needs to process every packet coming in and going out.

 

The bridge function of linux is a passthrough mechanism without much overhead. It is mandatory for VMs to give outside connectivity. For docker this bridge function is optional, i.e. a  custom (macvlan) network may be attached directly to the interface (e.g. eth0) or the associated bridge (br0).

 

Edited by bonienl
Link to comment
21 hours ago, bonienl said:

 

Bridge mode is the least desired mode to work with.

  1. It has network performance degradation due to the NAT function

  2. All ports need to be explicitedly configured/mapped otherwise connectivity breaks

 

I recommend for docker containers which require many ports to function (like unifi) to configure them on their own IP address. This is possible in unRAID 6.4.

I hope to do this when I upgrade to 6.4 - any idea if there is any additional config work required on the Unifi side?  I am still on 6.3.5 and if I can remember properly off the top of my head I let the Unifi docker have the default ports like 8080 and 8443 - but they are currently on the same IP as my docker, which is 192.168.1.99.  So when I go to 6.4 and move the Unifi docker container to a new IP, say 192.168.1.201, will I have to do anything to tell my devices like my WAPs and USG that the Controller is now on a different IP?

Link to comment
5 hours ago, wayner said:

I hope to do this when I upgrade to 6.4 - any idea if there is any additional config work required on the Unifi side?  I am still on 6.3.5 and if I can remember properly off the top of my head I let the Unifi docker have the default ports like 8080 and 8443 - but they are currently on the same IP as my docker, which is 192.168.1.99.  So when I go to 6.4 and move the Unifi docker container to a new IP, say 192.168.1.201, will I have to do anything to tell my devices like my WAPs and USG that the Controller is now on a different IP?

 

I assigned a separate IP address to my Unifi docker yesterday by editing the docker, setting network type to br0, and specifying the desired IP address.  This caused the docker to reload.  All ports were left at the defaults. When I accessed the WebUI, for about a minute the dashboard page showed pending on all my devices, but, it sorted itself out quickly and reactivated all devices.  All I did was change the IP address in the docker and the UniFi controller took care of the rest when restarted.

 

The docker shows up as a wired client in UniFi (on the same switch port as the unRAID server, of course) and I gave it an alias to identify it as the docker in the client list.  It's all a very simple process.

Edited by Hoopster
Link to comment
On 12/24/2017 at 3:55 AM, page3 said:

Wow, quick response!

 

Unfortunately, the other docker only keeps logs within the appdata folder, everything else must be within the docker image which seems a bit unusual. This is why I'm keen to move to the Linuxserver.io one.

 

I'm hoping I can do a config back from within the UniFi controller app (.unf file). I can then hopefully import that once I get to the Set-up screen on the UniFi controller on this docker. 

 

*** UPDATE ***

Just for information. I installed the Linuxserver.io docker. Restored the .unf file from my previous docker and all is up and running in under 5 minutes.

 

I now have my config on my cache in an accessible place, rather than from within the docker image.

 

I am currently using pducharme's UniFi Controller docker and is considering of switching to Linuxserver.io docker.

 

Did you have to uninstall your previous UniFi docker before installing Linuxserver.io?

Edited by mifronte
Link to comment
On 1/19/2018 at 1:25 PM, Hoopster said:

 

I assigned a separate IP address to my Unifi docker yesterday by editing the docker, setting network type to br0, and specifying the desired IP address.  This caused the docker to reload.  All ports were left at the defaults. When I accessed the WebUI, for about a minute the dashboard page showed pending on all my devices, but, it sorted itself out quickly and reactivated all devices.  All I did was change the IP address in the docker and the UniFi controller took care of the rest when restarted.

 

The docker shows up as a wired client in UniFi (on the same switch port as the unRAID server, of course) and I gave it an alias to identify it as the docker in the client list.  It's all a very simple process.

 

Now that you have the UniFi Controller docker running on its own IP, can you ssh into the controller app?

Link to comment
  • trurl locked this topic
Guest
This topic is now closed to further replies.