Why won't my UniFi Protect camera adopt, when my access points adopted fine?

Because Protect adoption follows different rules from UniFi Network adoption. Wired Protect adoption uses TCP ports 7444, 7550 and 7442 plus UDP 10001 for discovery — not the Network inform port 8080 — and cameras must receive an IP address via DHCP and sit on the same VLAN as the console or NVR. For a camera on another network, Ubiquiti's documented rescue is the camera's own web interface (default credentials ui/ui), where you enter the Protect host's IP address manually; there is no official SSH set-inform procedure for Protect cameras. A camera still managed by a previous console must be Unmanaged there first — the reset button alone does not release it.

My Protect camera is adopted and connected but records nothing. Why?

Work the configuration layer in order: the recording mode may be set to Never (or a schedule is pausing it); the storage drive may be in a health state such as 'Drive at Risk of Failure', which Protect says cannot be added to the storage pool — a console with no usable pool records nothing; or the mode is Detection Only on a camera whose generation cannot generate the trigger — for example G3 cameras have no person detection without an AI Port, so a detections-only camera correctly records nothing. Each cause is a setting or a status screen, not a defective camera.

Why does my Protect footage have gaps?

Ubiquiti's own connectivity guidance attributes gaps in footage to weak Wi-Fi on wireless cameras. Other documented causes: running beyond the console's recommended camera capacity, which Ubiquiti warns risks missing recordings; drive-health events and RAID rebuilds; and retention behaviour that can masquerade as gaps — Enhanced Retention progressively downgrades older high-quality footage to low quality rather than deleting it, which looks like loss when you scrub old dates. Check signal, capacity, and drive status before suspecting the camera.

UniFi Protect · Cameras · Fix

Protect camera won't adopt — or adopts and records nothing

First published 20 October 2026 · Mechanics below are from Ubiquiti's Protect adoption, getting-started, recording and storage documentation, read for this guide. Everything you learned adopting access points transfers only halfway — the differences are flagged where they bite.

Do not fix the wrong thing first. Protect adoption is not Network adoption. The ports differ (TCP 7444, 7550, 7442 + UDP 10001, not 8080), the cross-network rescue is the camera's own web UI, not SSH set-inform — Ubiquiti documents no SSH procedure for Protect cameras, whatever a forum pasted into a “guide” — and the release verb is Unmanage, not Forget.

FOUR DISEASES Never appears · Appears, won't adopt · Adopted, records nothing · Records, then gaps

Same camera, same blinking light, four different layers at fault — power/network, handshake, configuration/storage, continuity. Pick your symptom; stay in its section.

Each disease has its own ladderOne ladder for all four = a wasted weekend

Disease A — the camera never appears

Is there a Protect host at all? Protect runs on consoles/NVRs (UDM-class, Cloud Key+, UNVR family, Dream Router/Wall) — a Network-only gateway (Ultra, UX7 gateway mode) will never list a camera. If your host is one of those, that's the article: you need a Protect-capable host.
Power per the camera's own datasheet (each model states its PoE class; under-powered cameras light up and misbehave rather than dying cleanly) and a switch port with budget left.
Same VLAN as the console/NVR, and DHCP working — Ubiquiti's getting-started requires both; a camera on a camera-VLAN the console can't reach, or with no DHCP answer, is invisible by design.
Cable sanity: link light, a different port, a short known-good cable at the bench before blaming the run in the ceiling (100 m is the Ethernet standard limit — long marginal runs fail exactly like this).

Disease B — it appears, but adoption won't complete

Ports, not vibes: between the camera's network and the console, TCP 7444/7550/7442 and UDP 10001 must pass. Firewall rules written for Network adoption (8080) do nothing here.
Still owned elsewhere? A camera managed by another console must be Unmanaged there first — the reset button alone does not release it from its old application (Ubiquiti's FAQ, same rule as our Network adoption guide).
Cross-subnet rescue, the Protect way: browse to the camera's own web UI (default credentials ui/ui on an unmanaged camera) and enter the Protect host's IP manually. Change that default password the moment adoption succeeds — you've just read it on the public internet.
Firmware meets console: the console updates camera firmware as part of adoption; a console far behind on UniFi OS/Protect versions can stall the handshake. Update the host first, then retry — and expect Protect upgrades to arrive paired with UniFi OS releases.

Disease C — adopted, connected, records nothing

Recording mode: Protect's modes are Always / Detection Only / Never — check for Never, and for a schedule quietly pausing recording during your business hours.
Storage pool health: open the console's storage screen. A drive flagged “Drive at Risk of Failure” cannot be added to your storage pool (Ubiquiti's words) — a console with no usable pool shows cameras happily connected and records nothing at all. Storage hardware floor from Ubiquiti: HDDs of at least 1 TB, CMR, 7200 RPM; SSDs need a DRAM cache and ≥0.3 DWPD endurance.
Detection Only on a camera that can't: smart-detection capability is generational — G6/AI cameras detect people natively; G5/G4 less; G3 cameras have no person detection without an AI Port (Ubiquiti's capability table). A G3 set to Detection Only records nothing correctly. Set it to Always, or add the detection hardware.
Pre/post buffers are not the disease: they trim around events; they never zero a recording.

Disease D — it records, then there are gaps

Wireless camera? Signal first. Ubiquiti's own connectivity guide: weak Wi-Fi causes “gaps in footage.” The camera's uplink quality in Protect outranks every other suspect.
Capacity: Ubiquiti publishes recommended camera limits per console (from 5 HD cameras on a Dream Router up to 500 on the enterprise NVR) and warns that exceeding them risks “missing out on any recordings.” Those are guidelines, not hard limits — treat approaching them as a planning alarm.
Drive events: health degradation and RAID rebuilds steal exactly the throughput recording needs; the storage screen's health list (seven documented statuses) tells you which one you're in.
The impostor: Enhanced Retention progressively downgrades older footage from high to low quality. Scrubbing a month-old date and finding soft video is retention working — not a gap and not a failure.
Retention honesty: Ubiquiti publishes no “days per terabyte” constant — anyone quoting one is inventing it. The official route is Ubiquiti's Resource Calculator with your camera mix and the post-RAID usable capacity (RAID 5 ≈ 67–75%, RAID 10 ≈ 50%).

Traps this guide refuses to teach

You'll find it online	The documented truth
SSH into the camera and set-inform	No such Protect procedure exists in Ubiquiti's help documentation. The documented rescue is the camera web UI.
Menu paths like “Device Health → Diagnostic Logs”	Fabricated — an SEO content cluster publishes Protect “guides” with menu paths that don't exist. If a step's menu isn't on your screen, the guide is fiction; Ubiquiti's help centre is the arbiter.
Port-forward the internet to your NVR to fix adoption	Contradicts Ubiquiti's model and endangers the console. Adoption is a local-network (or VPN) affair; never an inbound-forward one.
“The SD card backs everything up automatically”	Documented only for the specific Teleport edge-recording case. General SD-as-backup for locally adopted cameras is not something Ubiquiti's docs promise — don't design around it.
Recordings will follow you to a new console	They don't migrate. Moving hosts means the old footage stays with the old console's drives.

FAQ

The camera adopted — but to the wrong console.

Unmanage it there, then adopt on the right host. (This is why the reset button disappointed you: it resets the camera, not its ownership.)

Do I need to update the cameras before adopting?

No — the console brings camera firmware up as part of adoption; it's the host's UniFi OS/Protect currency that matters beforehand.

ONVIF/third-party camera support — same rules?

Partially: third-party cameras ride Protect with reduced capability (per the same capability table — no smart detections), and their adoption path has its own documented steps. Treat a third-party camera's silence as its own diagnosis, not this guide's four diseases.

Sources

Ubiquiti Help Center — UniFi Protect: Getting Started, Device Adoption (Protect port set, camera web-UI host entry), recording modes & schedules, smart-detection capability table, storage & drive-health statuses, recommended capacity limits, connectivity guidance · Ubiquiti — camera datasheets (per-model power) · Ubiquiti — Resource Calculator (retention method).

Verification note: adoption ports, the web-UI rescue, recording modes, drive states, capability generations and capacity framing were confirmed from Ubiquiti's documentation on 20 October 2026. Ubiquiti publishes no glossary of camera status strings and no days-per-TB constant; this guide describes states instead of quoting strings, and teaches the calculator instead of a constant.

Did this fix work for you?

Your reaction tells us whether this guide solved the problem it promised to solve.