It's great, as far as I'm concerned.

It seems stable (although I've only been running it for a week), and the new UI finally works as it should. Best version yet, dare I say.

That is great, I would also agree with 7.0.23 being excellent and zero problems my side and nobody here moaning and reddit is quiet also on this version so probably everyone should try it and check they are happy. If nobody is complaining in a month or so about 7.0.23 we should just recommend that to anyone who asks. Its kind of easy when everyone has a stable version to then recommend how to upgrade from it to a later version (ie the exact steps) and also then everyone kind of knows how it works and what to expect etc. Plus this supports all their hardware currently so seems like a good place to me anyway.

Edited March 20, 20224 yr by PeteAsking

7.0.25 has few changes and just a few bugfixes. Updating to it from 7.0.23 is very seamless.

Why won't the controller listen for 161 (SNMP). I have SNMP enabled on the controller and I even added the port forwards but it just refuses it. Can anyone help me with what I am missing?

Hi,

 

I'm getting a MongoDB exception after running the Unifi Controller for like a day or two,

It keeps happening all the time. Only a restart to the container solves it temporarily till it happens again.

I'm using the latest version.

 

Did it happen to anyone?

Anyone have any idea what to do?

 

Exception in thread "RefreshSsoTokens" com.mongodb.MongoTimeoutException: Timed out after 30000 ms while waiting for a server that matches ReadPreferenceServerSelector{readPreference=primary}. Client view of cluster state is {type=UNKNOWN, servers=[{address=localhost:27117, type=UNKNOWN, state=CONNECTING, exception={com.mongodb.MongoSocketOpenException: Exception opening socket}, caused by {java.net.ConnectException: Connection refused (Connection refused)}}]
at com.mongodb.connection.BaseCluster.createTimeoutException(BaseCluster.java:377)
at com.mongodb.connection.BaseCluster.selectServer(BaseCluster.java:104)
at com.mongodb.binding.ClusterBinding$ClusterBindingConnectionSource.<init>(ClusterBinding.java:75)
at com.mongodb.binding.ClusterBinding$ClusterBindingConnectionSource.<init>(ClusterBinding.java:71)
at com.mongodb.binding.ClusterBinding.getReadConnectionSource(ClusterBinding.java:63)
at com.mongodb.operation.OperationHelper.withConnection(OperationHelper.java:406)
at com.mongodb.operation.FindOperation.execute(FindOperation.java:510)
at com.mongodb.operation.FindOperation.execute(FindOperation.java:81)
at com.mongodb.Mongo.execute(Mongo.java:836)
at com.mongodb.Mongo$2.execute(Mongo.java:823)
at com.mongodb.DBCursor.initializeCursor(DBCursor.java:870)
at com.mongodb.DBCursor.hasNext(DBCursor.java:142)
at com.ubnt.service.system.n.Ò00000(Unknown Source)
at com.ubnt.service.sso.ooOO.new(Unknown Source)
at com.ubnt.service.sso.ooOO.o00000(Unknown Source)
at com.ubnt.service.sso.ooOO$_o.run(Unknown Source)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)    

 

 

 

2 hours ago, idans said:

Hi,

 

I'm getting a MongoDB exception after running the Unifi Controller for like a day or two,

It keeps happening all the time. Only a restart to the container solves it temporarily till it happens again.

I'm using the latest version.

 

Did it happen to anyone?

Anyone have any idea what to do?

 

Exception in thread "RefreshSsoTokens" com.mongodb.MongoTimeoutException: Timed out after 30000 ms while waiting for a server that matches ReadPreferenceServerSelector{readPreference=primary}. Client view of cluster state is {type=UNKNOWN, servers=[{address=localhost:27117, type=UNKNOWN, state=CONNECTING, exception={com.mongodb.MongoSocketOpenException: Exception opening socket}, caused by {java.net.ConnectException: Connection refused (Connection refused)}}]
at com.mongodb.connection.BaseCluster.createTimeoutException(BaseCluster.java:377)
at com.mongodb.connection.BaseCluster.selectServer(BaseCluster.java:104)
at com.mongodb.binding.ClusterBinding$ClusterBindingConnectionSource.<init>(ClusterBinding.java:75)
at com.mongodb.binding.ClusterBinding$ClusterBindingConnectionSource.<init>(ClusterBinding.java:71)
at com.mongodb.binding.ClusterBinding.getReadConnectionSource(ClusterBinding.java:63)
at com.mongodb.operation.OperationHelper.withConnection(OperationHelper.java:406)
at com.mongodb.operation.FindOperation.execute(FindOperation.java:510)
at com.mongodb.operation.FindOperation.execute(FindOperation.java:81)
at com.mongodb.Mongo.execute(Mongo.java:836)
at com.mongodb.Mongo$2.execute(Mongo.java:823)
at com.mongodb.DBCursor.initializeCursor(DBCursor.java:870)
at com.mongodb.DBCursor.hasNext(DBCursor.java:142)
at com.ubnt.service.system.n.Ò00000(Unknown Source)
at com.ubnt.service.sso.ooOO.new(Unknown Source)
at com.ubnt.service.sso.ooOO.o00000(Unknown Source)
at com.ubnt.service.sso.ooOO$_o.run(Unknown Source)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)    

 

 

 

Did you set a memory limit as has been suggested many times in this thread? Also while on reading the thread did you set a version tag (eg: /unifi-controller:version-7.0.25) so your docker does not auto update past a revision without your knowledge, as has been suggested many times in this thread? Both these things are very important when using the unifi docker. Reason being the tag means you could have taken a manual backup before updating so you can always roll back to a prior version if you have a problem later on with anything, such as DB issue or any other issue.

Edited April 4, 20224 yr by PeteAsking

Noob question. How do you specify the tag? I'm searching on google but no luck. 

 

Thanks!

21 minutes ago, SP67 said:

Noob question. How do you specify the tag? I'm searching on google but no luck. 

 

Thanks!

lscr.io/linuxserver/unifi-controller:7.0.23

Hi guys , why if i install unifi controller on a custom network for swag after few second stop to work all .

Is like Unifi controller is going to corrupt my swag docker container, as soon i stop unifi and i restart swag all is back in service

3 hours ago, simo241 said:

Hi guys , why if i install unifi controller on a custom network for swag after few second stop to work all .

Is like Unifi controller is going to corrupt my swag docker container, as soon i stop unifi and i restart swag all is back in service

I mean, you are going to have to provide a lot more information about your particular setup before anyone can help. Collectively the community might know more than any individual about how things should work, but you alone are in possession on how your particular setup is configured so unless you tell us we will have no idea what to suggest.

Another question. I'd like to add a controller that is not on my network. I've seen this official manual (link) but I was wondering, when it says: "Take a laptop to the device's site to perform adoption via Chrome browser (easiest method)", how would I do that using this docker? Would I need to make the controller available via a reverse proxy, can I use a VPN, or is there any other recommended alternative?

 

Thanks in advance

On 4/4/2022 at 8:30 PM, PeteAsking said:

Did you set a memory limit as has been suggested many times in this thread? Also while on reading the thread did you set a version tag (eg: /unifi-controller:version-7.0.25) so your docker does not auto update past a revision without your knowledge, as has been suggested many times in this thread? Both these things are very important when using the unifi docker. Reason being the tag means you could have taken a manual backup before updating so you can always roll back to a prior version if you have a problem later on with anything, such as DB issue or any other issue.

I tried, I set a memory limit of 2Gb (--memory="2g") but the issue still happens.
Any other suggestions?

 

P.S: my unifi controller version is 7.0.25

8 hours ago, idans said:

I tried, I set a memory limit of 2Gb (--memory="2g") but the issue still happens.
Any other suggestions?

 

P.S: my unifi controller version is 7.0.25

The correct syntax is:

--memory=2G

not

--memory="2g" which is a syntax you have made up and not appropriate.

On 4/19/2022 at 6:32 AM, PeteAsking said:

The correct syntax is:

--memory=2G

not

--memory="2g" which is a syntax you have made up and not appropriate.

Thanks, but the previous syntax was working as well, the limit was indeed 2G and I took it from the docker documentation.
Anyway, I changed it to your syntax but the exception still occurs.

I'm lost and don't know how to continue, anyone has an idea?

The error indicates mongodb is not running so must be some issue with your setup. Either wrong port or something blocking it etc. You would need to look into that.

Changed my tag to lscr.io/linuxserver/unifi-controller:version-7.1.61 and verified everything is working perfectly.

53 minutes ago, PeteAsking said:

Changed my tag to lscr.io/linuxserver/unifi-controller:version-7.1.61 and verified everything is working perfectly.

Would you say this is a good place to park for a few months? I'm currently still parked at linuxserver/unifi-controller:6.5.55.

 

If you feel this is a good spot, I'll unpin the 6.2.26 post and pin this one.

49 minutes ago, JonathanM said:

I'm currently still parked at linuxserver/unifi-controller:6.5.55.

And I am still running 5.14.23.  The horrible experience most had with the early 6.x.x versions put me off upgrading since none of my current equipment requires a version beyond 5.14.23.

 

I may finally take the plunge soon since I don't want to get left too far behind.

1 hour ago, JonathanM said:

Would you say this is a good place to park for a few months? I'm currently still parked at linuxserver/unifi-controller:6.5.55.

 

If you feel this is a good spot, I'll unpin the 6.2.26 post and pin this one.

I just upgraded to v7.1.61 from v7.0.25 without issue.

v7.0.25 has been solid, and the new interface is pretty much complete. I run 2x wired AC LR and a USG, so it's not a complicated setup, but I wouldn't hesitate to recommend moving to the v7 series.

Edited April 27, 20224 yr by jademonkee

What are the advantages to the newer versions? I'm still on 5.14.23-ls76.

 

I know the Log4j bug was fixed, and it supports newer hardware (I only run AC Lite APs), but are there other new features that are worthwhile looking at?

 

Thanks.

2 hours ago, johnieutah said:

What are the advantages to the newer versions? I'm still on 5.14.23-ls76.

 

I know the Log4j bug was fixed, and it supports newer hardware (I only run AC Lite APs), but are there other new features that are worthwhile looking at?

 

Thanks.

I mostly prefer the new interface.

There's heaps of other changes since v5. You can see the changelogs from v6 > v7 here: https://community.ui.com/releases/UniFi-Network-Application-7-0-25/3344c362-7da5-4ecd-a403-3b47520e3c01

And of course there's even more from v5 > v6

On 4/27/2022 at 3:52 PM, JonathanM said:

Would you say this is a good place to park for a few months? I'm currently still parked at linuxserver/unifi-controller:6.5.55.

 

If you feel this is a good spot, I'll unpin the 6.2.26 post and pin this one.

All of the 7 series have had no issues whatsoever for me so any of the version 7 versions are totally fine. Only thing I am unsure of is upgrading from an old version if you need to go via certain revisions or if you can just go from say 6.2.26 straight to the latest one.

I have always had Max Memory defined as an Extra Parameter. On Github change long for 7.0.25 mentions: Move min/max memory config from run to system.properties.. Does that mean I need to move my memory out of Extra Parameters now?

 

 

7.1.65 has just minor bug changes so anyone on 7.1.61 should immediately just upgrade (take a copy of your docker obviously first)as there is an almost zero chance of anything going wrong.

I'm hoping someone could advise me on this issue. 

 

So I have just started using the latest version of the Unifi controller around 2 weeks ago. I got all my devices into the controller and everything was working fine. Then I logged in the next day and all my devices were saying "waiting adoption". So i SSH into each device and run the following command.

 

set-inform http://UNRAIDIP:8080/inform

 

that fixed the issue. Next day comes along and I logged in to the Unifi controller and the same thing happened again. "Waiting Adoption". 

 

Basically every single day i have to run that command to get my device to adopted into the controller. I have all my auto update plugins to miss this container. I also have my Appdata backup to not include the Unifi-controller folder. 

 

Anything else i can try to fix this issue?