January 4, 20251 yr 21 hours ago, bmartino1 said: you will either need to re make and start new by setting up locally or regain/reset the unifi ubiquity account. Once inside the network controller, you can add a local admin for access and configuration changes. Unfii info on MFA: https://help.ui.com/hc/en-us/articles/115012986607-Multi-Factor-Authentication-MFA See also: https://community.ui.com/questions/Create-second-local-administrator-on-Unifi-controller/8023249b-0d5c-4496-b298-6696efc7c2ab https://community.ui.com/questions/SOLVED-UniFi-Network-Application-new-local-user/114ac4c5-e3d2-4a4d-965c-89d94c16ccc8 On setting up a local admin user... Normally the self-hosted container doesn't need mfa unless you enable and set up the cloud side stuff to access the controller from unifi.ui.com MFA was forced a few year back when UNifi had a cybersecurity breach... old notice: https://community.ui.com/questions/Update-to-January-2021-Account-Notification/3813e6f4-b023-4d62-9e10-1035dc51ad2e with ui in the devices them selves via the unif OS... Its Settings > admins & users as seen here... the admin user is a local role of super admin and was made at controller first launch and how the controller was originally setup. You may need to enable legacy mode to get to a similar screen to add a local admin user not assigned or associated with the unifi account. Thank you guys. I think i may have to restart from scratch. I do have a case opened with unifi support but i doubt they will disable the MFA requirement temp so i can log in.
January 5, 20251 yr I'm trying to get this up and running again. It died at some point and I just gave up on it. The issue I was receiving was I would get a Error 404 page from the container, and it was marked as unhealthy. I don't know anything about what makes the container as healthy or unhealthy. In my experience, I always ran a healthcheck in the extra parameters. Nothing in the container logs. I removed the container, and the image and attempted to reinstall. Now I get a full Site can't be reached, however it is now marked as healthy. My log only shows: {"time":"2025-01-05T22:13:51.000Z","type":"INF","msg":"starting unifi (8.5.6)"} org.tuckey.web.filters.urlrewrite.UrlRewriteFilter INFO: destroy called {"time":"2025-01-05T22:17:29.000Z","type":"INF","msg":"starting unifi (8.5.6)"} I did try the original version 7.XX (something, missed it on the first page but it matches the old old). I then moved the image to the 8.5.6. Still nothing. I then also deleted the image, container, and removed the config folder in the appdata. Still nothing. I have tried the network on bridge, and on custom with a unique address, nothing. Accessing 10.0.0.200 (or .201 on custom):8443 gives me nothing. No errors on the docker logs, no errors on the app build. Any help? Thanks!
January 6, 20251 yr 1 hour ago, firedog said: I'm trying to get this up and running again. It died at some point and I just gave up on it. The issue I was receiving was I would get a Error 404 page from the container, and it was marked as unhealthy. I don't know anything about what makes the container as healthy or unhealthy. In my experience, I always ran a healthcheck in the extra parameters. Nothing in the container logs. I removed the container, and the image and attempted to reinstall. Now I get a full Site can't be reached, however it is now marked as healthy. My log only shows: {"time":"2025-01-05T22:13:51.000Z","type":"INF","msg":"starting unifi (8.5.6)"} org.tuckey.web.filters.urlrewrite.UrlRewriteFilter INFO: destroy called {"time":"2025-01-05T22:17:29.000Z","type":"INF","msg":"starting unifi (8.5.6)"} I did try the original version 7.XX (something, missed it on the first page but it matches the old old). I then moved the image to the 8.5.6. Still nothing. I then also deleted the image, container, and removed the config folder in the appdata. Still nothing. I have tried the network on bridge, and on custom with a unique address, nothing. Accessing 10.0.0.200 (or .201 on custom):8443 gives me nothing. No errors on the docker logs, no errors on the app build. Any help? Thanks! delete the app data and check resource over head. I hvae seen some of that when momory resource where full or trying to allocate to much. if you didn't set a appdata path. delete that folder so the container can recreate new with better permissions... edit and set the extra parameter to 4G use latest at first start template install. as of writing Stable: 11notes/unifi:8.5.6-unraid Regarding the log entry: org.tuckey.web.filters.urlrewrite Log Entry What It Means: This message is related to the UrlRewriteFilter, a Java-based URL rewriting library used by the UniFi Controller to manage incoming requests (e.g., routing REST API calls or serving web pages). INFO: destroy called: This means the UrlRewriteFilter is being stopped or destroyed, often during application shutdown or restart. If this log entry occurs during the controller’s startup sequence, it might indicate an issue where the URL rewrite filter fails to initialize properly. more a api issue that can be casued with memory issues... you can add extra parm for health cehcks: --health-interval=30s --health-timeout=5s --health-retries=3 but I would recomend deleting the appdata folder and rebuildin the container with less ram in the extra parm. this way the api is clear and the docker first run will creat the necessary folders... Otherwise please post a diag file as i'm failry certain this is a java memory realted issue.
January 7, 20251 yr New Year new Network Server update! https://ui.com/download/releases/network-server This patch actually looks sick.
January 8, 20251 yr Is there a way to get this container exposed so that I can access it via https://unifi.ui.com/? It appears there for cloud access, but I can only get into the management portal by referencing the Docker container's IP and port directly.
January 8, 20251 yr 2 hours ago, tehg said: Is there a way to get this container exposed so that I can access it via https://unifi.ui.com/? It appears there for cloud access, but I can only get into the management portal by referencing the Docker container's IP and port directly. Yes, this is possible. it is easeir to setup the controller as fresh new by signing into your unifi account. Then add a local admin user. This is the quickest and easiest way to enable unifi.ui.com api to access the network controller... Otherwise, You have to have a unifi account and enable sso signin. you also need some settigns under Settigns Gear > System > Advanced --Can't find the documentation/video... I have done this in the past... If you set it up as a local admin first, you may also need to add your unifi email account used as a user aswell.
January 9, 20251 yr Author 09 Jan 2025 New tags for all deployments as of today: Choose your own adventure tag: https://hub.docker.com/r/11notes/unifi/tags Current recommended Home User tag: 11notes/unifi:9.0.108-unraid Current Company/Corporate recommended tag: 11notes/unifi:8.6.9-unraid Current Critical Infrastructure (no downtime) tag: 11notes/unifi:8.5.6-unraid All above listed tags have no known CVEs listed against them. Please upgrade ASAP. Kind regards P Side note: This docker is expected to have 8GB RAM allocated to it. While it may typically use less - approximately 1-2GB - it is nonetheless expected to be able to expect and use 8GB if the need arises albeit temporarily. Do not configure the docker to use less than this as is can cause database issues during certain tasks. Ignoring of this warning is a decision made by you, and any consequences to be blamed, on you. It is expected that reasonable CPU and RAM is allocated to this docker for correct functioning of the Unifi and MongoDB software. Weird and extremely constrictive setups in the name of "improving performance" are beyond the scope of support. Edited January 9, 20251 yr by PeteAsking
January 9, 20251 yr I've updated to 9.0.108 but am not seeing the option to move to zone based firewalls. Anyone else who has updated able to see this?
January 9, 20251 yr Author 48 minutes ago, fat said: I've updated to 9.0.108 but am not seeing the option to move to zone based firewalls. Anyone else who has updated able to see this? Do you have the following requirements? Requirements UniFi Cloud Gateway (or independent UniFi Gateway) UniFi Network Application version 9.0 or newer UniFi (Cloud) Gateway version 4.1 or newer
January 9, 20251 yr 31 minutes ago, PeteAsking said: Do you have the following requirements? Requirements UniFi Cloud Gateway (or independent UniFi Gateway) UniFi Network Application version 9.0 or newer UniFi (Cloud) Gateway version 4.1 or newer I cant believe I missed those requirements. UXG Pro official release hasn't hit 4.1 yet. Thanks for clarifying
January 9, 20251 yr Thanks for the updates as always, really appreciate them. Would be great though if "latest" version tags could be added for each stream (home/company/critical for unraid and non-unraid versions). That would allow automatic updates without manual user interactions to change the version and fix CVEs automatically.
January 9, 20251 yr Author 1 minute ago, Taramu said: Thanks for the updates as always, really appreciate them. Would be great though if "latest" version tags could be added for each stream (home/company/critical for unraid and non-unraid versions). That would allow automatic updates without manual user interactions to change the version and fix CVEs automatically. This will never be added. Auto upgrades are unsupported and never will be for this docker. This is 100% intentional. Edited January 9, 20251 yr by PeteAsking
January 10, 20251 yr On 1/8/2025 at 11:22 AM, bmartino1 said: Yes, this is possible. it is easeir to setup the controller as fresh new by signing into your unifi account. Then add a local admin user. This is the quickest and easiest way to enable unifi.ui.com api to access the network controller... Otherwise, You have to have a unifi account and enable sso signin. you also need some settigns under Settigns Gear > System > Advanced --Can't find the documentation/video... I have done this in the past... If you set it up as a local admin first, you may also need to add your unifi email account used as a user aswell. That is what is odd. I did login using SSO and I see it in site manager, but just clicking on it causes it to load indefinitely with the `Connecting to Site is taking longer than expected ...` message. So my theory is something is being blocked that I should allow.
January 10, 20251 yr 3 minutes ago, tehg said: That is what is odd. I did login using SSO and I see it in site manager, but just clicking on it causes it to load indefinitely with the `Connecting to Site is taking longer than expected ...` message. So my theory is something is being blocked that I should allow. that's Ubquity/unifi side server issues. Every once in a while I have unifi api issue where using unifi.ui.com will not let me see my device. that's all on unifi... https://community.ui.com/questions/Connecting-is-taking-longer-than-expected-/6708c63f-969b-4a19-9a4c-8d0dd2e15061 Sometimes a restart of the docker / container will fix this... Sometimes a SSO local login is needed to reconnect... They been having performance and high usage since late December. that's when I noticed issues connecting to things via their api... Edited January 10, 20251 yr by bmartino1 data - typo
January 11, 20251 yr 17 hours ago, bmartino1 said: that's Ubquity/unifi side server issues. Every once in a while I have unifi api issue where using unifi.ui.com will not let me see my device. that's all on unifi... https://community.ui.com/questions/Connecting-is-taking-longer-than-expected-/6708c63f-969b-4a19-9a4c-8d0dd2e15061 Sometimes a restart of the docker / container will fix this... Sometimes a SSO local login is needed to reconnect... They been having performance and high usage since late December. that's when I noticed issues connecting to things via their api... Mine used to always work without issue until I moved to the pre 9.0 update. Now I get the taking longer than expected to connect error.
January 12, 20251 yr Author Please note: Unifi users still using linuxserver.io who have not yet moved to this image. On 1st February 2025 we will no longer support migrations from the old unifi docker maintained by linuxserver.io. If this is a problem please move to this unraidunifireborn (this image) docker before 1st February. on 1 Feb the new installations for this docker will be tagged unifi:8.5.6-unraid. The old tag unifi:7.5.187-unraid will be deprecated and there will be no direct upgrade from linuxserver.io’s image to this image. new installs will all be tagged 8.5.6 after this date and it will be expected you run this image or later. Many thanks, P
January 21, 20251 yr On 1/10/2025 at 6:41 PM, tehg said: That is what is odd. I did login using SSO and I see it in site manager, but just clicking on it causes it to load indefinitely with the `Connecting to Site is taking longer than expected ...` message. So my theory is something is being blocked that I should allow. I recently migrated to the new UniFi Controller container and also faced issues getting cloud access to work after the migration. After numerous attempts, here’s the process that finally worked for me: Set-up fresh controller (don't recover from backup just yet) Sign in with your Unifi account and login Settings -> Backups -> Restore -> Restore from backup Settings -> Advanced -> Disable "Remote Management" -> Remove Re-enable "Remote Management" and sign in with your credentials + MFA 💡 Note: Steps 1 and 2 might be unnecessary if you restore from backup during the initial setup. However, I didn’t want to experiment further after finally resolving the issue. A big shout-out to the team behind the UniFi-Controller-Reborn Docker! The installation process was smooth and hassle-free. I initially tried using the LinuxServer container but had a frustrating experience—performance was painfully slow, and I lost a day troubleshooting. Switching to UniFi-Controller-Reborn was a game-changer. Thank you for making this container available! Edited January 21, 20251 yr by jiggier wording
January 21, 20251 yr 46 minutes ago, jiggier said: I recently migrated to the new UniFi Controller container and also faced issues getting cloud access to work after the migration. After numerous attempts, here’s the process that finally worked for me: Set-up fresh controller (don't recover from backup just yet) Sign in with your Unifi account and login Settings -> Backups -> Restore -> Restore from backup Settings -> Advanced -> Disable "Remote Management" -> Remove Re-enable "Remote Management" and sign in with your credentials + MFA 💡 Note: Steps 1 and 2 might be unnecessary if you restore from backup during the initial setup. However, I didn’t want to experiment further after finally resolving the issue. Tried this, sadly no joy. Here are the logs I am seeing: :0 Permanent error code on allocate request: 420 - . This was after receiving a valid nonce :0 TURN instance failed: TURN id: 3; fd: 256 0.0.0.0:40124 -> 141.101.90.1:3478 (all_interfaces) DTLS id: :0 STUN id: 4; fd: 263 172.17.0.6:60069 -> MY.IP.ADDR:53190 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 5; fd: 263 172.17.0.6:60069 -> MY.IP.ADDR:57366 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 6; fd: 263 172.17.0.6:60069 -> 104.30.144.212:53535 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 7; fd: 263 172.17.0.6:60069 -> 104.30.144.212:22212 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 8; fd: 263 172.17.0.6:60069 -> 104.30.144.212:58178 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 4; fd: 237 172.17.0.6:40744 -> MY.IP.ADDR:19547 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 5; fd: 237 172.17.0.6:40744 -> MY.IP.ADDR:23328 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 6; fd: 237 172.17.0.6:40744 -> 104.30.144.212:32691 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 7; fd: 237 172.17.0.6:40744 -> 104.30.144.212:59751 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 8; fd: 237 172.17.0.6:40744 -> 104.30.144.212:22938 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 4; fd: 223 172.17.0.6:47224 -> MY.IP.ADDR:47032 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 5; fd: 223 172.17.0.6:47224 -> MY.IP.ADDR:21813 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 6; fd: 223 172.17.0.6:47224 -> 104.30.144.213:10607 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 7; fd: 223 172.17.0.6:47224 -> 104.30.144.212:31146 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 8; fd: 223 172.17.0.6:47224 -> 104.30.144.212:19737 (eth0) DTLS id: 0 () (PEER) timed out :0 TCP candidates not supported yet :0 Permanent error code on allocate request: 420 - . This was after receiving a valid nonce :0 TURN instance failed: TURN id: 3; fd: 237 0.0.0.0:37336 -> 141.101.90.1:3478 (all_interfaces) DTLS id: :0 STUN id: 4; fd: 247 172.17.0.6:39115 -> MY.IP.ADDR:17267 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 5; fd: 247 172.17.0.6:39115 -> MY.IP.ADDR:50323 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 6; fd: 247 172.17.0.6:39115 -> 104.30.144.212:47547 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 7; fd: 247 172.17.0.6:39115 -> 104.30.144.212:29280 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 8; fd: 247 172.17.0.6:39115 -> 104.30.144.212:16033 (eth0) DTLS id: 0 () (PEER) timed out That led me down a bit of a rabbit hole. So I have setup the container to be on the bridge network, which would lead it to have 172.17.0.0/16 as the subnet. What is the recommended network to run the container on? I do see that IP being blocked as a destination from my local PC when I try to go to unifi.ui.com and select that network, so it is definitely tied to the Docker container's IP address.
January 22, 20251 yr Author 2 hours ago, tehg said: Tried this, sadly no joy. Here are the logs I am seeing: :0 Permanent error code on allocate request: 420 - . This was after receiving a valid nonce :0 TURN instance failed: TURN id: 3; fd: 256 0.0.0.0:40124 -> 141.101.90.1:3478 (all_interfaces) DTLS id: :0 STUN id: 4; fd: 263 172.17.0.6:60069 -> MY.IP.ADDR:53190 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 5; fd: 263 172.17.0.6:60069 -> MY.IP.ADDR:57366 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 6; fd: 263 172.17.0.6:60069 -> 104.30.144.212:53535 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 7; fd: 263 172.17.0.6:60069 -> 104.30.144.212:22212 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 8; fd: 263 172.17.0.6:60069 -> 104.30.144.212:58178 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 4; fd: 237 172.17.0.6:40744 -> MY.IP.ADDR:19547 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 5; fd: 237 172.17.0.6:40744 -> MY.IP.ADDR:23328 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 6; fd: 237 172.17.0.6:40744 -> 104.30.144.212:32691 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 7; fd: 237 172.17.0.6:40744 -> 104.30.144.212:59751 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 8; fd: 237 172.17.0.6:40744 -> 104.30.144.212:22938 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 4; fd: 223 172.17.0.6:47224 -> MY.IP.ADDR:47032 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 5; fd: 223 172.17.0.6:47224 -> MY.IP.ADDR:21813 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 6; fd: 223 172.17.0.6:47224 -> 104.30.144.213:10607 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 7; fd: 223 172.17.0.6:47224 -> 104.30.144.212:31146 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 8; fd: 223 172.17.0.6:47224 -> 104.30.144.212:19737 (eth0) DTLS id: 0 () (PEER) timed out :0 TCP candidates not supported yet :0 Permanent error code on allocate request: 420 - . This was after receiving a valid nonce :0 TURN instance failed: TURN id: 3; fd: 237 0.0.0.0:37336 -> 141.101.90.1:3478 (all_interfaces) DTLS id: :0 STUN id: 4; fd: 247 172.17.0.6:39115 -> MY.IP.ADDR:17267 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 5; fd: 247 172.17.0.6:39115 -> MY.IP.ADDR:50323 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 6; fd: 247 172.17.0.6:39115 -> 104.30.144.212:47547 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 7; fd: 247 172.17.0.6:39115 -> 104.30.144.212:29280 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 8; fd: 247 172.17.0.6:39115 -> 104.30.144.212:16033 (eth0) DTLS id: 0 () (PEER) timed out That led me down a bit of a rabbit hole. So I have setup the container to be on the bridge network, which would lead it to have 172.17.0.0/16 as the subnet. What is the recommended network to run the container on? I do see that IP being blocked as a destination from my local PC when I try to go to unifi.ui.com and select that network, so it is definitely tied to the Docker container's IP address. I dont actually understand clearly what you have done or what you are trying to do. Did you setup this container from scratch and never get it working or did you try restore a backup or what?
January 22, 20251 yr Author Ate you just trying to use cloud access? Mine seems to work perfectly and dont even remember setting anything up: I am using network type bridge. This works perfectly. If your firewall blocks random things make sure there are relevant exceptions for testing.
January 22, 20251 yr 4 minutes ago, PeteAsking said: I dont actually understand clearly what you have done or what you are trying to do. Did you setup this container from scratch and never get it working or did you try restore a backup or what? I've tried both. It works as a whole, which is great. It was more just a curiosity about how to get remote access working. At the end of the day, I can't imagine I need remote access ever, but I like trying to figure things out.
January 22, 20251 yr Author 2 minutes ago, tehg said: I've tried both. It works as a whole, which is great. It was more just a curiosity about how to get remote access working. At the end of the day, I can't imagine I need remote access ever, but I like trying to figure things out. Its working for me (first time trying it) so must be something your side you have changed or blocked. I guess this is on by default: Edited January 22, 20251 yr by PeteAsking
January 22, 20251 yr 1 minute ago, PeteAsking said: Its working for me (first time trying it) so must be something your side you have changed or blocked. Weird! I will blame OPNSense and mess around with it. Maybe bridge mode is making it sad with how my network is setup or something.
January 22, 20251 yr Author Just now, tehg said: Weird! I will blame OPNSense and mess around with it. Maybe bridge mode is making it sad with how my network is setup or something. Must be. Check if you can add logging on all your block rules and then watch the live log as you try it.
January 23, 20251 yr On 1/22/2025 at 5:02 AM, tehg said: Weird! I will blame OPNSense and mess around with it. Maybe bridge mode is making it sad with how my network is setup or something. In my case, I also did open port 8443 from WAN to my unifi controller. I am running on ETH1 Network type with static IP. I had this port open while testing various approaches. Closed it, once I got unifi.ui.com working. This port should be used for UI access only and don't think unifi servers use it for validation. can you verify your firewall is not blocking outbound traffic for this container?
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.