[Support] Linuxserver.io - Unifi-Controller


927 posts in this topic Last Reply

Recommended Posts

On 3/7/2019 at 10:51 AM, sreknob said:

Big thanks as usual to the team!

For those having adoption issues, I vaguely remember having issues before about that.

In case you don't already have custom IP in controller settings, you might want to make sure that you have set the IP under settings.

I had a issue where the controller was trying to set-inform with my private docker IP (172.17..1.X) instead.

See screenshot below, checking "Override inform host with controller hostname/IP" and entering the IP of your server above that.

 

image.thumb.png.00cd202d1cfe106ab60271aa68e4bdd3.png

 

This worked perfectly for me.  I tried to do the initial installs of the AP and got the adoption loop when I had the docker to set to bridge.  One I changed the above settings in the controller everything connected properly.  No need to change the docker to host with this change.

Link to post
  • 2 weeks later...
  • Replies 926
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Success, so far, I'm running 5.14.23-ls76 now.   So, to summarize, to those who wish to move from LTS (5.6.42) to 5.14.23-ls76, you must first use 5.10.24-ls21 to upgrade the database.

Sorry, I may have missed something completely earlier in discussions but mine also had this issue as it looks like dockerhub linuxserver.io shows version 6.1.71 attached to the tag 'latest' which it i

I was having adoption issues when i changed to this docker and then i remembered i had the same problem before after an upgrade and i had to change the docker to "host" from "bridge".   Rest

Posted Images

On 3/28/2019 at 8:29 AM, block134 said:

This worked perfectly for me.  I tried to do the initial installs of the AP and got the adoption loop when I had the docker to set to bridge.  One I changed the above settings in the controller everything connected properly.  No need to change the docker to host with this change.

 

Glad it worked for you @block134

 

@linuxserver.io - looking through this thread, I see lots of adoption issues. I wonder if adding the set-inform address in the controller should be part of the instructions to save frustration. I think that many may be running into this problem depending on their docker network setup.

 

For those having adoption problems, if you want to check your devices to see where they're getting stuck with adoption loops, you can SSH into the device and run "info" which will show the current set-inform IP address. This can be done though a usual SSH session or opening a debug terminal from your controller (click on the device, then the tools button, then debug terminal) depending on the state of your device.

Link to post

Hello all,

 

For those having issues with UAP devices showing disconnected and set-inform not working I found the problem. The problem is with auto optimize. What ever you do, for now do not turn on auto-optimize, if you do you'll lose your UAP connection as soon as you power cycle. The solution fortunately is not a big deal, but dang did it take some time to figure out!

 

First of all make sure you do a new backup file. Settings ---> Maintenance --_> Download Backup. After you do this you will have to uninstall and blow away the docker in its entirety. Then reinstall the docker. The important part is this. DO NOT use the backup file from the wizard when you first launch into your docker. Go through the wizard like it is a fresh install AND TURN OFF auto optimize when you get to the admin/authenticate screen, then finish the wizard normally.

 

Finally you can then go back to settings and maintenance and do the backup file. All your settings will go back to normal, and then all your devices will connect. For those devices that do not connect, do set-inform http://[IP]:[Port]/inform after sshing in. And remember, DO NOT TURN ON AUTO OPTIMIZE. It is a beta feature that doesn't want to work well with dockers at the moment, and Ubiquiti doesn't support dockers.

 

Edit: atag_5.10.20_11657

Edited by Snoobish
Link to post

I've been having an update issue with this Docker from both the old Unifi Docker and this new Unifi-Controller Docker.

Docker reports there is an update and when I update it is successful but when I go to the Web UI it is still the same version as before.

For this Docker I am currently on 5.10.20 (using the latest branch) - first question I guess... is 5.10.20 the latest version and Docker is incorrectly reporting an update or is there a later version and it's just not installing correctly?

Edited by egtrev
Link to post
21 minutes ago, egtrev said:

I've been having an update issue with this Docker from both the old Unifi Docker and this new Unifi-Controller Docker.

Docker reports there is an update and when I update it is successful but when I go to the Web UI it is still the same version as before.

For this Docker I am currently on 5.10.20 (using the latest branch) - first question I guess... is 5.10.20 the latest version and Docker is incorrectly reporting an update or is there a later version and it's just not installing correctly?

I think you are confusing container updates with application updates. Many LSIO containers update on a weekly basis (Fridays I think). When the update is installed whatever app version you have tagged will be pulled. If there has been an update to that version of the app then it will also be updated, but many times the container is updated without any change to the app.

Link to post
1 hour ago, wgstarks said:

I think you are confusing container updates with application updates. Many LSIO containers update on a weekly basis (Fridays I think). When the update is installed whatever app version you have tagged will be pulled. If there has been an update to that version of the app then it will also be updated, but many times the container is updated without any change to the app. 

 

That makes sense. Thank you.

Link to post
  • 4 weeks later...

I had to replace my cache drive and recreate my docker.img.  I restored my appdata using CA Appdata Backup / Restore v2 and installed Unifi-Controller LTS.  Everything was working perfect before but the issue now is I can see my devices in the Unifi Controller but I can't see any clients. 

 

The next step I took was to download a backup file from Unifi Controller.  I then remove the existing docker and deleted the appdata/unifi folder and created a new docker and restored from the backup file.  I had the same results of seeing devices but not clients.

 

Only thing I see different is that the current LTS is 5.6.42 and my backups are from 5.6.40.  Not sure if that makes a difference.  Any ideas as why I'm not seeing clients? 

unifi.PNG

Link to post
27 minutes ago, niwmik said:

I had to replace my cache drive and recreate my docker.img.  I restored my appdata using CA Appdata Backup / Restore v2 and installed Unifi-Controller LTS.  Everything was working perfect before but the issue now is I can see my devices in the Unifi Controller but I can't see any clients. 

 

The next step I took was to download a backup file from Unifi Controller.  I then remove the existing docker and deleted the appdata/unifi folder and created a new docker and restored from the backup file.  I had the same results of seeing devices but not clients.

 

Only thing I see different is that the current LTS is 5.6.42 and my backups are from 5.6.40.  Not sure if that makes a difference.  Any ideas as why I'm not seeing clients? 

unifi.PNG

I'm going to hazard a guess that it's because the radios are disabled?

 

2019-05-12_20-33.png.6763af358620c2bfa8f1f0bcc3090079.png

Link to post
Hi, new ubiquiti user here.
 
Switch US-16-150W
AP Nano HD
 
For a totally fresh installation, any tips to follow?
What brach would be better to start with? 5.9?
 
Thankyou
Gus
For stability I'd say go with LTS, you can always upgrade at a later date.

Sent from my Mi A1 using Tapatalk

Link to post
On 5/12/2019 at 2:07 PM, niwmik said:

I had to replace my cache drive and recreate my docker.img.  I restored my appdata using CA Appdata Backup / Restore v2 and installed Unifi-Controller LTS.  Everything was working perfect before but the issue now is I can see my devices in the Unifi Controller but I can't see any clients. 

 

The next step I took was to download a backup file from Unifi Controller.  I then remove the existing docker and deleted the appdata/unifi folder and created a new docker and restored from the backup file.  I had the same results of seeing devices but not clients.

 

Only thing I see different is that the current LTS is 5.6.42 and my backups are from 5.6.40.  Not sure if that makes a difference.  Any ideas as why I'm not seeing clients? 

unifi.PNG

 

The solution for me was to switch from LTS to 5.9 and then restore from my 5.6.40 backup.  I can now see all my clients.

Link to post
On 5/19/2019 at 5:01 PM, truetype said:

Suddenly I cannot login anymore? Says it's the wrong username / password. But I can reach it from the UBNT cloud...

I had the exact same problem recently.  For me, I was using the wrong username with the docker.  The cloud I was able to login with my email so I changed my user name on the cloud to the one I normally use and was able to log in again.  It made me feel stupid because it took me over a week to figure out I was using the wrong user name.

Link to post
On 5/12/2019 at 12:07 PM, niwmik said:

I had to replace my cache drive and recreate my docker.img.  I restored my appdata using CA Appdata Backup / Restore v2 and installed Unifi-Controller LTS.  Everything was working perfect before but the issue now is I can see my devices in the Unifi Controller but I can't see any clients. 

 

The next step I took was to download a backup file from Unifi Controller.  I then remove the existing docker and deleted the appdata/unifi folder and created a new docker and restored from the backup file.  I had the same results of seeing devices but not clients.

 

Only thing I see different is that the current LTS is 5.6.42 and my backups are from 5.6.40.  Not sure if that makes a difference.  Any ideas as why I'm not seeing clients? 

unifi.PNG

Thanks for posting this.  I had the same issue.  In the old docker, I was running Unifi Controller version 5.6.40.  Before upgrading to the new docker, I backed up my appdata and also downloaded a backup of the controller settings from Settings/Maintenance in the Unifi Controller.  

 

When I installed the LTS branch of the new docker, it installed Unifi Controller version 5.6.42.  I followed the directions at the beginning of the thread and used the old appdata folder.  All the APs connected and were working, but nothing was shown in the client list. 

 

I tried restoring the backup of the 5.6.40 settings in the 5.6.42 controller, but that did not fix the missing client list and now the UI incorrectly showed the APs as disabled (even though they were still working). 

 

So, I installed the new docker again, this time choosing the 5.9 branch and created a brand new appdata folder.  Then, I restored the backup of my 5.6.40 controller settings.  The APs and client list are now working and shown correctly in the UI.

Link to post
  • 2 weeks later...

Coming off of the deprecated 5.6.40 controller which had no issues, now I am seeing the same adopting issues as many others have mentioned on 5.6.42, 5.8.30, etc. Unfortunately, I cannot use the "Override inform host with controller hostname/IP" work around as I have USGs in other sites that use a FQDN to inform the controller, which I have found the above workaround does not work with.


 

Things I have tried and noticed.


 

Override inform host with controller hostname/IP – using FQDN

・Offsite no issues connecting, local devices adopt loop

・From ^ SSH into the local devices, set-inform manually to the controller’s local IP, it will connect, then when it re-provisions those local devices to the FQDN forced hostname, it starts looping again


 

Not using override - after restarting unRAID

・Offsite that had been set previously with FQDN inform, connects with no issues

・Local devices adopt loop. Like above, setting the inform manually via ssh to the controller’s local ip works immediately


 

I am using a site-to-site tunnel, and according to unifi, the tunnel should auto update the WAN address, keeping the connection alive. So I’m wondering if forcing the inform to the local ip of the controller will work or not. I don’t know, even if it does, I don’t like that idea of having only a single point of failure, with the probability of loosing access to that offsite site.


 

I’m curious if maybe making a json file, setting the local device’s informs to the controller’s local IP address, if that will be like ssh’n into them manually stopping the loop or not. Just an idea that popped into my head, but I wouldn’t know how to do that, even following the unifi “make a json” instructions.


 

If anyone has any other ideas, I am open to them. Otherwise, I might have to try and get the 5.6.40 controller back up and running again (if that is even possible with it being deprecated).

 

Updated----

 

Tried rolling back to 5.6.40, same issue there now. Not sure whats causing it. I mean, everything still works (aside from the controller) after a reboot, so I suppose it will just be a minor annouyance of manually set-inform'n for awhile until things get sorted out. 

Edited by ryoko227
updated
Link to post
6 hours ago, ryoko227 said:

Override inform host with controller hostname/IP – using FQDN

・Offsite no issues connecting, local devices adopt loop

Using the override with FQDN works fine internally for me. Are you sure your NAT reflection / loopback is working properly in your router? I have 3 external sites and 1 internal site managed with this container, all working fine, with all devices using FQDN.

Link to post
21 hours ago, jonathanm said:

Using the override with FQDN works fine internally for me. Are you sure your NAT reflection / loopback is working properly in your router? I have 3 external sites and 1 internal site managed with this container, all working fine, with all devices using FQDN.

Sounds like something specific on my side then. So I checked the USG's config.boot and its showing "hairpin-nat enable" in the port forwarding section. I then verified that the FQDN resolves internally, pointing to my WAN IP, which it does. So I checked my firewall and porting forwarding to try and make sure I don’t have anything silly in there. Everything is default, aside from my port forwarding stuff for the inform, stun, and an old OpenVPN docker I had setup. From there I started searching and found something about forwarding ports 443 and 10443, but that also didn’t work. I even forced a DNS entry for that FQDN => local unRAID IP, which worked for all devices except the USG, which would still come back with the WAN IP, and then adopt loop.

 

Thinking something was off, I created another docker container completely from scratch, no backup restore, set-default all devices, this time using 5.8.30 on the controller. Same issue, if I don’t “Override inform host with controller hostname/IP” when the docker/unRAID server restarts, the devices go into an adoption loop. One thing I did notice that I thought was odd is if you SSH into the devices and use “info” while its looping, it’s showing an inform set to the docker container IP, not the previously set/working inform information.

 

I really don’t have any idea why the USG isn’t liking the FQDN as its inform. I have pulled power, set-default, used the reset button, everything back to factory, and it still hates it. If I set-inform to the local unRAID server address, it immediately connects.

 

Did you have to do anything special to get your's working with an overiden FQDN?

 

Outside of that, I am extremely curious if there is a .json way to hard-lock the inform information on a per-device basis. That's kind of the last ditch effort , as this is looking like my only/easiest option.

Link to post
1 hour ago, ryoko227 said:

I really don’t have any idea why the USG isn’t liking the FQDN as its inform. I have pulled power, set-default, used the reset button, everything back to factory, and it still hates it. If I set-inform to the local unRAID server address, it immediately connects.

 

Did you have to do anything special to get your's working with an overiden FQDN?

I don't use any USG's, I only have wifi radios in my sites. Sorry to mislead you, I didn't see any mention of a USG in your post, and didn't think to go back in your post history to see which devices you had.

Link to post
On 6/4/2019 at 7:36 PM, jonathanm said:

I don't use any USG's, I only have wifi radios in my sites. Sorry to mislead you, I didn't see any mention of a USG in your post, and didn't think to go back in your post history to see which devices you had.

Oh, dang, I was hoping for some juicy tidbits, sorry for the confusion. Thank you though, I can also confirm that the APs don't seem to have any issue when “Override inform host with controller hostname/IP” are with the FQDN, just the USG that's WAN IP is where the FQDN resolves to.

 

I'm gonna see if I can find a way to json the inform information and hard lock them to something that works.

 

 

---------SOLVED----------

https://www.reddit.com/r/Ubiquiti/comments/bxrzoh/usg_setinform_fqdn_gives_local_usg_adopt_loop/

This is how I made the config.gateway.json...


{
    "system": {
        "static-host-mapping": {
            "host-name": {
                "FQDN": {
                    "inet": "My_unRAID_Local_IP"
                }
            }
        }
    }
}



Since it's running in unRAID, I could simply place this into...

/mnt/cache/appdata/Unifi_Container_Name/data/sites/Site_Name_Being_Used

 

Edited by ryoko227
Added Solution
Link to post
  • 2 weeks later...

Im new to Unifi and this is a brand new installation  USG with 16-port 150W Switch and one UAP Pro for a small Business. All three devices are stuck in the adopting stage, then they show disconnected for couple of second and again back t adopting in a never ending loop. any ideas?

Link to post
14 minutes ago, NGMK said:

Im new to Unifi and this is a brand new installation  USG with 16-port 150W Switch and one UAP Pro for a small Business. All three devices are stuck in the adopting stage, then they show disconnected for couple of second and again back t adopting in a never ending loop. any ideas?

You need to do what's being done in this picture or read the post right above your one.image.png.8bc217f65ae5771dc220e9639f82e74d.png

(Stolen from post further up)

Edited by j0nnymoe
Link to post
On 6/13/2019 at 11:03 AM, j0nnymoe said:

You need to do what's being done in this picture or read the post right above your one.

(Stolen from post further up)

Yes this worked for me thank you very much.  This should be part of the initial instructions 

 

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.