UniFi Adoption Failed: How to Fix Stuck Devices

For a UniFi adoption failure, first check stable power, an assigned IP address and the path to the intended UniFi Network host. Then check whether the device belongs to an older installation. Resetting first can erase useful configuration without fixing a blocked port or incorrect management VLAN.

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.

Status	What to check next
Pending Adoption or Adopting	Whether the intended host can complete device communication
Provisioning repeatedly	Power, link stability and changes to the device’s management network
Disconnected	Reachability to the existing host, including its local firewall
Managed by Other	Previous application ownership, a suitable backup or reassignment
Adoption Failed	The accompanying message; the label alone does not identify a cause

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.

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.

For application compatibility, check the model’s published minimum UniFi Network version. The U7 Pro specifies 8.0.28 or later. Resolve an unsupported host version before repeating adoption.

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.

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. Consult the DHCP server’s documentation for its required encoding instead of copying an address 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.

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.