UniFi · Adoption · Fix ladder
UniFi device stuck on “Adopting,” or branded “Managed by Other”? Work the ladder, in order
Steady white means the device is ready to be adopted — powered, reset, and waiting. If yours shows this and the controller still will not take it, the block is on the path between them, not in the device. This page finds it.
The fast answer
Adoption is a conversation: the device must find the controller and the controller must be allowed to claim it. Nearly every stuck adoption is one of five things, and the ladder below works them in the order that wastes the least of your evening:
- The device is bonded to another controller — “Managed by Other.” It must be released there first; the reset button alone does not release it.
- The path is blocked: adoption talks on TCP 8080 (inform) and discovers on UDP 10001. The often-blogged port 8443 is only the web interface.
- The device sits on an unexpected address — after reset it can fall back to 192.168.1.20, invisible on a differently-numbered network.
- It is on a different network than the controller with no directions — remote (layer-3) adoption needs
set-inform, DHCP option 43, or DNS to point it home. - Its firmware predates the controller by too much — update path matters.
Do not start with a factory reset. It is rung 6 here, deliberately — and done wrong (or too long) it creates two new problems.
Read the device first: the LED is the first witness
| What you see | What it means (Ubiquiti) | Start at |
|---|---|---|
| Steady white | Factory state — ready for adoption. | Rung 2 (address) if the controller cannot see it at all. |
| Steady blue | Adopted and working normally. | Your problem is elsewhere — check which controller it belongs to. |
| Blue flashing off every ~5 seconds | Adopted, but the uplink is lost. | Cabling/switch port — this is not an adoption problem. |
| Flashing white/blue/off cycle | Firmware or TFTP recovery activity. | Do not power-cycle mid-write. See the traps. |
| “Managed by Other” in the controller | Bonded to a different UniFi application. | Rung 4 — the bond must be broken there. |
| “Isolated” | An adopted device that has lost its wireless uplink. | Uplink path, not adoption. |
LED meanings and status names: Ubiquiti help centre (help.ui.com). One honesty note: the phrase “Adoption Failed” is community language, not a string in Ubiquiti's current documentation — this page describes states by the names UniFi itself shows you.
The ladder
Rung 1 — Confirm the address the device actually has
- In the controller, open the DHCP/IP leases view (or Ubiquiti's WiFiman) and find the device by its MAC address — printed on the device label.
- Verify: you can see a lease on your network. No lease on your subnet, and the device may be sitting on the fallback
192.168.1.20after reset, or stranded behind a VLAN tag it cannot cross. Give it a reachable address (or temporarily meet it on its subnet) before touching anything else.
Rung 2 — Open the real path: 8080 and 10001
- Between device and controller, nothing may block TCP 8080 (inform) or UDP 10001 (discovery). Firewalls, “guest” VLANs and isolation features are the usual suspects.
- Ignore any guide that tells you to open 8443 for adoption — Ubiquiti's port reference assigns 8443 to the web GUI/API only.
- Verify: from the device's network, the controller answers on 8080. If the controller is a self-hosted install, also confirm the service itself is running — a stopped application discovers nothing.
Rung 3 — If it says “Managed by Other,” break the old bond properly
- Ubiquiti's own order: first try the old application — restore from its backup, or reassign via the UniFi mobile app where offered.
- Otherwise, in the old application, use Forget on the device. Understand what the buttons do: the physical reset button resets the device — Ubiquiti states plainly that it does not remove the device from the old application. Reset without Forget is why devices return from the dead still bonded.
- Verify: the device shows steady white and appears as Pending Adoption — not Managed by Other — in the new controller.
Rung 4 — Firmware: controller first, then device
- A device whose preloaded firmware is far older than the controller can fail or loop. Bring the controller current first, then let it upgrade the device as part of adoption.
- Hands off during the write. The flashing cycle in the LED table is a device mid-surgery; power-cycling it is how adoption problems become recovery problems.
- Verify: after adoption the device reports the controller-offered firmware and state Connected.
Rung 5 — Different network? Give it directions (layer-3 adoption)
- SSH to the device (after a factory reset, Ubiquiti's documented defaults apply; after adoption, the controller's device credentials do — another reason rung order matters) and run:
set-inform http://<controller-address>:8080/inform - Click Adopt in the controller when the device appears — then run set-inform a second time. This is not a folk hack: Ubiquiti's adoption documentation says you may need to repeat the command after the device appears in UniFi.
- Alternatives that scale: DHCP option 43 or a DNS name for the controller, so future devices find home on their own.
- Verify: the device checks in from its remote network and stays Connected through a reboot.
Rung 6 — Factory reset, last and correctly
- Press and hold reset for 5–10 seconds depending on the device — Ubiquiti's range, not the internet's flat “10 seconds.” Holding far longer can push the device into TFTP recovery mode, a different procedure entirely.
- Before resetting a bonded device, reread Rung 3: reset + no Forget = the same bond waiting for you afterwards.
- Verify: steady white LED, default credentials accepted, device appears as Pending Adoption.
The traps that manufacture repeat failures
- Adopting into the wrong instance. A second controller on the network (an old laptop install, a test VM) will happily claim devices. One site, one live controller.
- “But it pings.” Ping proves an address answers. Adoption needs the 8080/10001 conversation — a pinging device can still be unreachable for adoption.
- Inform-URL typos. In set-inform, the address, the :8080 port and the /inform path all matter; the classic failure is a correct-looking URL missing one of them.
- SSH firmware surgery as routine advice. Ubiquiti labels manual SSH firmware updating “not an officially supported process,” to be used at UI Support's request. Blogs present it as step one. It is not step one.
- The deprecated Chrome discovery tool still recommended by older articles. Ubiquiti's current path is WiFiman plus the controller's lease view.
FAQ — the issues behind this problem, answered
The device pings and shows in discovery, but adoption loops forever. Why?
Discovery (UDP 10001) and inform (TCP 8080) are separate legs. Being found is leg one; the loop lives in leg two — a blocked 8080, a wrong inform target, or an existing bond rejecting the claim. Walk the ladder: address, path, bond, in that order.
I reset the device and it STILL says Managed by Other.
Expected behaviour, per Ubiquiti: the reset button does not remove the device from its old application. Forget it there (or restore/reassign from the old application first), then reset if still needed.
Do I need to run set-inform twice, really?
Yes — Ubiquiti's own adoption article says the command may need repeating after the device appears in UniFi. The first run introduces the device; the second confirms the inform address now that the controller knows it.
Sources
Ubiquiti Help Center (help.ui.com) — UniFi device adoption, “Managed by Other” FAQ and console migration guidance, LED status reference, UniFi ports reference, layer-3 adoption (set-inform, DHCP option 43, DNS), factory restore guidance. Community patterns (deprecated discovery tool, SSH-update folklore, reset-timing myths) were cross-checked against those official pages and are labelled as community claims wherever used.
Did this fix work for you?
Your reaction tells us whether this guide solved the problem it promised to solve.