Fixing UniFi Device Adoption Failures

September 4, 2026 · 5 min read · Josh Dargie · Markdown

Adoption is the step where a new UniFi access point, switch or camera shows up in your Network application and agrees to be managed by it. When it works, it takes thirty seconds. When it doesn't, you get a device stuck at "Adopting", or "Adoption Failed", or worse, a device that never appears at all. By the end of this post you'll have a checklist that finds the cause in the order the causes actually occur, instead of the usual routine of unplugging things at random. This is written for someone comfortable in the UniFi interface who has one stubborn device, not a fleet.

One caveat before we start: Ubiquiti moves menus between releases, so treat the paths I give as landmarks rather than gospel. The concepts don't change even when the buttons do.

Understand what adoption actually is

A UniFi device announces itself on the local network, and once adopted it phones home to your controller's "inform" address over TCP port 8080. Discovery uses UDP port 10001. That's the whole mechanism. Nearly every adoption failure is one of four things: the device can't get an IP, it's on the wrong network or VLAN, something is blocking those ports, or the device still belongs to a previous controller. Work through them in that order.

Step 1: Confirm the device has a sane IP

Check the LED first. A solid or steady white light on most devices means it booted and is waiting for adoption; anything unusual is worth looking up for your specific model. Then find the device in your client list, or use Ubiquiti's WiFiman app to scan for it.

Two IPs tell you a lot. If the device sits at 192.168.1.20, that's the fallback address a UniFi device assigns itself when DHCP fails, which points you at switch port settings or a network loop rather than the device. If it has an address from a subnet you don't recognize, something else on your network is handing out DHCP. A forgotten ISP router still plugged in somewhere is the usual suspect.

Step 2: Check the VLAN, because it's the VLAN

The failure I see most often on networks that have had any VLAN work done: the device is plugged into a switch port whose native network is not the management network. UniFi devices expect to reach the controller untagged on whatever network the port hands them. If that port's native network is your camera VLAN or IoT VLAN, the device boots happily into a network that has no route to the controller, or one where you've blocked exactly the traffic it needs.

Fix it at the switch port. In the Network application, open the port the device is on and confirm the native VLAN is your management network. If you've been overriding port profiles, this is the moment to check what that port actually inherited, not what you think you set six months ago.

Step 3: Make sure nothing is blocking ports 8080 and 10001

If controller and device are on the same flat network, this is rarely the issue. If your controller runs as software on a PC or server, though, the machine's own firewall can block the inform port. Antivirus suites with "network protection" features do this quietly. Confirm TCP 8080 and UDP 10001 are allowed on the machine hosting the application. On a cloud gateway this is handled for you.

Step 4: Factory reset a device that belonged to someone else

A used device, or one adopted to an old controller you've since retired, will refuse a new adoption because it's still holding its previous configuration. It may show as "Managed by Other". The fix is a factory reset: hold the reset button with the device powered until the LED changes behaviour, then release and let it boot clean. Give it a full minute or two. People release the button early, see nothing change, and conclude the device is dead. It usually isn't.

Step 5: SSH and set-inform, the manual override

When the device is healthy but simply can't find the controller, tell it where to go directly. SSH into the device's IP. On a factory-fresh device the username and password are both ui (older units use ubnt for both). Then run:

set-inform http://YOUR-CONTROLLER-IP:8080/inform

Go back to the Network application, and the device should appear as ready to adopt. Click adopt. If it flips back to a disconnected state after adopting, run the same command once more; the first inform sometimes doesn't survive the credential change that adoption performs. This is also the method behind "Layer 3 adoption", where the controller lives on a different subnet or offsite. Ubiquiti supports DHCP option 43 and DNS-based methods for that too, but set-inform is the one you'll actually remember.

Test it

Adopted is not the same as working. Confirm the device shows Online, finishes provisioning (the status will cycle through it), and holds its config. Then power cycle it once and make sure it comes back online on its own, with an address on the management network. A device that only stays adopted until the next reboot has an IP or VLAN problem you've papered over, and it will pick the worst possible week to remind you.

Where this gets harder than a blog post

One device on one site is a checklist. The same problem across multiple sites, adoption over a VPN, a controller migration where fifty devices need to move without downtime, or devices that keep dropping because of a deeper DHCP or spanning tree issue: that's a different job, and it's the kind of thing worth having watched on an ongoing basis rather than fixed on Saturdays. If you've been through this list and the behaviour still doesn't make sense, I'm happy to take a look. Book a second opinion and bring your topology; adoption failures almost always confess under questioning.

Sources

← All posts