One of my UniFi Protect cameras, a G3 Pro, dropped off the console and would not come back. The console listed it, the camera was pingable, and every attempt to re-adopt it from the Protect UI failed without a useful message. It took four days and several wrong theories to fix, and the fix is a two-minute job once you know it. This post is the whole journey, wrong turns included, because the wrong turns are the ones people search for.
What the camera was doing
SSH into the camera (enable it in Protect under the device’s settings, or use the recovery password) and look at the adoption client log. Mine showed a reconnect attempt every three seconds, continuously, for four days. CPU was at 93 per cent. The camera was trying to open its WebSocket to the console and the console was refusing it.
The root cause
The camera had got itself into a contradictory state. Its own configuration said it was adopted by my console, but it was advertising itself on the network as adoptable. The console saw a device claiming to be unadopted and refused the WebSocket from it, and the camera saw a console it believed it belonged to and kept trying. Neither side would blink.
Why re-adopting from the console cannot work on this firmware
When you click adopt in Protect, the console pushes a request to the camera’s management endpoint (/api/1.2/manage) and authenticates with the device password. On the 4.75 firmware this camera runs, that request never succeeds. I pulled the camera’s CGI binary apart with strings and the only authentication it accepts on that endpoint is a session cookie from its own web UI. There is no basic authentication path, so the console’s push adopt cannot get in. It is not you; the button just does not work for this combination.
The wrong theories, for the record
- Clock or certificate mismatch. Plausible, because the camera’s time had drifted. Fixing it changed nothing.
- A zero-byte adopted.conf. This looks like corruption. It is normal on an adopted camera.
- Factory reset. I did not want to lose the camera’s settings, and in the end it was not needed.
The fix: adopt from the camera, not the console
- SSH to the camera and reset the adoption client configuration so it stops claiming to belong to anyone:
mv /etc/persistent/ubnt_avclient.conf /etc/persistent/ubnt_avclient.conf.bak cfgmtd -w -p /etc/ reboot - Browse to the camera’s own web UI (https on its IP) and sign in with the device password.
- Under the Protect settings in that UI, enter the IP of your Protect console and save.
That adopts in the other direction. The camera announces itself to the console with consistent state, the console accepts it, and within a minute it was recording with all its old settings intact.
If you have lost the device password
Each camera’s password is set by the console at adoption and shown in the Protect settings. If you cannot find it there, it is also stored in the console’s own Postgres database, which you can query over SSH on the console. Treat that as a last resort and do not change anything in there.
What I would do first next time
Tail the camera’s log before touching the console. Ten minutes of watching the reconnect loop would have told me the console was refusing the connection, and that points at adoption state, not certificates. And when the adopt button does nothing, go round the other way and adopt from the camera.