UniFi Adoption Failed: How to Fix Stuck Devices

UniFi “Adoption Failed” means the device and the UniFi Network application could not finish their handshake over TCP 8080. Work through five causes in this order: unstable PoE power, no valid IP on the management VLAN, a host on another subnet, ownership by an old controller, and firmware the application will not accept. Factory reset last, not first.

Fast answers by symptom

Read the status before choosing a fix

Adoption connects a device to its managing application; provisioning applies its configuration. Preserve the exact status and the time it changed before trying another recovery step.

This distinction also prevents confusing an unavailable dashboard with failed Wi-Fi. Ubiquiti’s self-hosting documentation says adopted APs and switches keep functioning when UniFi Network stops, while statistics and configuration management need the application running.

What adoption actually is

Adoption is the process of connecting a UniFi device to the UniFi application that will manage it. Under the surface it is a conversation: the device has to discover a controller, then reach that controller’s inform endpoint over TCP port 8080, then be claimed there.

Ubiquiti’s ports reference lists the two that matter for the discovery phase: UDP 10001 for device discovery during adoption, and TCP 8080 for device and application communication. UDP 3478 supports STUN during adoption and communication. These are UniFi Network checks for APs and switches; Protect has its own adoption requirements.

There is one more property of the process that explains a surprising number of failures. The Layer 3 adoption documentation notes that a device cycles through all of its inform options, including a zero-touch provisioning code, and whichever responds first adopts it. A stale DHCP option 43 entry or an old DNS record pointing at a decommissioned controller can therefore win the race against the controller you actually want.

The diagnostic order

Work top to bottom and stop when the symptom changes.

1. Does the device remain powered with a stable Ethernet link?
2. Does it have a valid IP address on the intended management network?
3. Is the intended UniFi Network host running and reachable from that network?
4. Do routing and firewall rules allow the documented communication ports?
5. Does it still belong to an older application, or discover an unintended host?

Check power and cabling before controller recovery

Ubiquiti requires the switch’s total PoE availability to exceed the connected devices’ power requirements. Check both the shared budget and the individual port’s supported PoE mode. A spare port does not prove there are spare watts.

If the device repeatedly restarts, try a known-good cable and compatible power source before changing controller settings. Record whether its uptime resets and whether the switch reports a link change. These observations help separate a physical interruption from a device that stays powered but cannot reach its host; they do not establish a failed AP by themselves.

Use the PoE budget and switch planning guide for the power worksheet. Wait for boot or an update to finish before judging another attempt.

1. No IP address: check the management VLAN

A missing or invalid address can follow a port-profile change or an incorrect Network Override. Ubiquiti recommends tracing the switch-port path back to the gateway with VLAN Viewer. Check that the device management VLAN is carried along that entire path and that DHCP is available on it.

Ubiquiti’s connectivity troubleshooting guide reads no address, or the fallback 192.168.1.20, as a tagging, Network Override or loop problem, and an unexpected address as a sign of a rogue DHCP server.

Check, in this order: the port profile assigned to that switch port, whether the management network is actually the untagged network on it, and whether a DHCP scope exists on that network at all. The UniFi home network setup guide explains the controller, gateway and tagging roles.

If the device works on the host’s VLAN but fails after moving to its final port, compare the two network paths. Do not assume the successful temporary adoption also validates the destination VLAN.

2. Not in factory-default state, or “Managed by Other”

Ubiquiti documents Managed by Other when the device still belongs to a different application instance, including the instance that existed before a console reset. If available, restore a backup that already managed the device. The account owner’s mobile app can also reassign eligible devices under the conditions in the reset documentation.

A new installation of UniFi Network on another computer is another host, not a viewer for the existing installation. Open the existing host’s interface when you only want to manage it from a second computer.

Reset-button prompt: hold until the LED state changes

Use a factory reset when reclaiming a device for a fresh adoption after checking the network path. It clears the device configuration and interrupts its service. Ubiquiti specifies roughly 5-10 seconds, depending on the device, or until the reset indication begins; keep power connected and follow the model’s instructions.

A physical reset does not remove the old application record. Holding the button too briefly can reboot the device, while holding it too long can enter recovery mode. An unexpected LED sequence therefore does not by itself prove a power or hardware fault.

3. Different VLAN or subnet: this is Layer 3 adoption

Discovery on UDP 10001 is a broadcast. Broadcasts do not cross a router. As soon as the device and the controller are on different VLANs or subnets, automatic discovery stops working even though routing between them is perfectly fine.

Ubiquiti’s answer is Layer 3 adoption, and its requirement is stated as unrestricted connectivity over TCP port 8080 between the device and the UniFi Network application. So:

• Confirm inter-VLAN routing is enabled between the two networks.
• Confirm no firewall rule blocks TCP 8080 in that direction.
• Then use one of the inform methods below to tell the device where the controller lives, since it cannot discover it by broadcast.

SSH and set-inform. Connect to the device over SSH and run:

set-inform http://ip-of-host:8080/inform

The device then appears as ready to adopt. The documentation notes that the command may need repeating after the device shows up in the controller, which catches people out: the first inform gets it listed, and the adoption handshake can require the second.

Factory-default devices accept SSH as ui/ui, or ubnt/ubnt on older units. After adoption the site’s generated credentials are listed under Device Updates and Settings > Device SSH Authentication, per Ubiquiti’s SSH guide.

DHCP option 43 or DNS. Ubiquiti also supports supplying the application host through DHCP option 43 or resolving the hostname unifi to it. Verify the value served on the device’s VLAN. Ubiquiti’s IP form is 0104 followed by the address in hex, so 192.168.1.10 becomes 0104C0A8010A; check how your DHCP server expects that value rather than copying one from another installation.

4. Remote sites: the path, not the device

Adopting across the internet is the same Layer 3 problem with a longer path. Ubiquiti breaks it into three cases: the controller has a public IP and no upstream firewall blocks TCP 8080; the controller sits behind a gateway and TCP 8080 is port-forwarded to it; or a VPN puts the device on the same logical network, in which case only internal firewalling can be in the way.

Exposing TCP 8080 to the internet is worth thinking about before doing it. A routed VPN provides a private path when its firewall permits the required traffic. Adoption is followed by ongoing device communication, so retain a working path after the initial handshake.

5. Something else is answering

If a device adopts itself to the wrong controller, or bounces between pending and adopting without settling, look for a competing inform source. Because a device tries every option it knows and takes the first response, the candidates are: a leftover DHCP option 43 value on that VLAN, a unifi DNS record pointing at an old host, a previous controller still running somewhere on the network, and a zero-touch provisioning claim on the account.

Clearing the stale entry is the fix. Restarting the intended controller is not.

Stuck on Adopting: the adopt-and-drop loop

A device stuck on Adopting reached the application once but cannot finish at the inform address it is handed back. Over SSH, info prints the firmware, IP address and inform status (command reference). If that URL is not your host, check:

1. Inform Host Override. Inside Docker, UniFi uses an address other devices cannot reach, say the LinuxServer.io notes; enable Inform Host Override under UniFi Devices > Device Updates and Settings > Device SSH Settings with a reachable address.
2. A remapped port. The same notes require 8080:8080 on both sides.
3. A single set-inform. Repeat it after the device appears.
4. A competing inform source (section 5).

Update Required, or adoption failed after an update

Update Required points at firmware. Ubiquiti’s advanced updating guide covers a device that “cannot be adopted because it has been preloaded with outdated firmware.” Fix it in this order:

1. Use the Update button in UniFi Network if offered. Quickly flashing white/blue LEDs mean an upgrade is running; do not cut power (LED guide).
2. Paste the model’s firmware link from community.ui.com/releases into the Settings tab of the device’s properties panel.
3. Last resort, which Ubiquiti reserves for UI Support requests: SSH in and run upgrade <firmware-link>.

If downloads fail, the UniFi Updates article suggests DNS such as 1.1.1.1 and unblocked UDP 53 and 123.

Failure after an update starts with versions: compare the model’s minimum UniFi Network version with the host’s. A reinstalled self-hosted server needs TCP 8080, TCP 8843, UDP 10001 and UDP 3478 reopened in its local firewall, per Ubiquiti’s self-hosting steps. A move to a new host needs Override Inform Host set on the old application, per Backups and Migration. Self-hosters face that move next: UniHosted reports Ubiquiti naming 10.6 the final standalone Network release, because 11.0 moves to PostgreSQL.

UniFi AP adoption failed, including the U7 Pro

• Power. The U7 Pro takes PoE+ and draws up to 21 W. Ubiquiti’s PoE table gives 802.3af 12.95 W at the device, so an af-only port or injector falls short. Size the switch with the AP PoE budget guide.
• Version. The U7 Pro needs UniFi Network 8.0.28 or later; other models list their minimum on their spec pages.
• LED. Steady white is ready for adoption; white flashing off every half second is still booting. Steady blue means already configured: if the AP is not in your application, the standalone AP article says to factory reset it first.
• Mesh. A wireless-uplink AP needs Wireless Meshing enabled and Mesh Connect on the uplink AP.

UniFi switch adoption failed

A switch that forwards traffic but will not adopt usually lacks a working management address. Ubiquiti’s VLAN guide lists three mistakes that also block wired adoption: Network Override onto a VLAN that is already the port’s Primary (Native) Network, Network Override onto a VLAN not tagged upstream, or a native network not allowed upstream. Check its lease against section 1; old firmware takes the same upgrade command as an AP.

USG adoption failed

Check the version first. HostiFi reports the USG end of life since November 2024, and UniHosted reports Ubiquiti naming Network 10.6 the last release to support the USG, USG-Pro and USG XG 8. The USG quick start guide sets 5.4 as the minimum. Then work from its defaults: LAN 1 serves DHCP at 192.168.1.1/24 and WAN 1 is a DHCP client.

1. Connect the modem to WAN 1 and the UniFi Network host’s switch to LAN 1.
2. Confirm the host took a 192.168.1.x lease from the USG, then adopt.
3. If it was managed before, hold Reset about 10 seconds, until the right LED on WAN 2/LAN 2 flashes and then stays lit.
4. For old firmware, run upgrade <firmware-link> over SSH.

Adoption failed after a power outage

If Wi-Fi still works, start with the host, not the APs. Once the gateway and host have booted, check failed devices for the 192.168.1.20 fallback and bounce their ports. On a self-hosted server, confirm the application restarted and kept its IP; if not, reserve that address or point Override Inform Host at the new one.

Adopted but stuck provisioning

If adoption completes and the device then drops during provisioning, review the last configuration change. Ubiquiti’s VLAN troubleshooting guide identifies Network Override and missing upstream VLAN tags as causes of devices going offline. Confirm that the newly assigned management network can still reach DHCP and the host.

Compare device uptime with link and configuration events. If uptime resets, return to power checks. If it stays up but becomes unreachable after a VLAN change, restore the documented management path before attempting another reset.

Review installed firmware and the application’s supported versions. Use the official update workflow and relevant release notes; avoid changing firmware, VLAN assignments and the host address in the same troubleshooting attempt. Keep a configuration backup before updates.

Device does not respond to adopt commands

Treat this wording as a reason to check communication, not as proof the AP is defective. Verify its current address, confirm which host it is contacting, and review the host firewall as well as inter-VLAN rules. For a self-hosted application, opening the dashboard locally does not demonstrate that devices can reach it.

Record whether the failure happens before adoption or after configuration starts. That narrows the next check to initial reachability or the provisioning path above.

Server reject during adoption

Record the exact message and the intended application instance. Review old ownership and competing inform sources before changing anything: rejection text alone does not prove stale credentials. If the device is marked Managed by Other, use the documented restoration, reassignment or reset path above.

Sanity checks that save time

• Check the ports on the controller side too. The application GUI and API run on TCP 8443 on a UniFi console, with TCP 443 for browser access; STUN on UDP 3478 is required for device adoption and communication. A firewall policy written only for 8080 can still break the session.
• Keep the physical and application observations together. Note the LED sequence, uptime, assigned address and status text. Use the UniFi sizing planner for an initial estimate, then verify the actual device power specifications.
• Do not plan a management-VLAN change on a live network without a path back. Moving adopted devices to a different management network is one of the reliable ways to strand a fleet. Decide the management VLAN when you are still planning the build, as set out in what to buy first.

If the checks do not resolve the problem, collect the device model, application and firmware versions, status timeline and management topology for support. Keep credentials and configuration backups private. A documented sequence is more useful than another unrecorded factory reset.

FAQ

how do i fix a unifi device stuck on adopting

SSH to the device, run info, and read the inform URL it reports. If it is not your host, correct Inform Host Override or the DHCP option 43 and DNS entries that supplied it, then run set-inform http://host-ip:8080/inform again after the device appears. Confirm TCP 8080 is open end to end.

what does update required mean when adopting unifi

The device’s firmware is too old for the UniFi Network application to adopt it. Use the Update button if offered, or paste the model’s firmware link from community.ui.com/releases into the device’s Settings tab. Ubiquiti’s last resort is SSH and the upgrade command with that link, then adopt again.

why won’t my u7 pro adopt

Check power and version first. The U7 Pro needs PoE+ and draws up to 21 W, more than an 802.3af port delivers, and it requires UniFi Network 8.0.28 or later. If both check out, treat it like any other AP: IP address, TCP 8080 path, then previous ownership.