UXG-Max adoption: correct Inform Host Override displayed, but device uses a stale hostname

[Epervios]

I am sharing a resolved UXG-Max adoption case and would appreciate clarification on a configuration inconsistency between the Inform Host Override shown in UniFi Network and the hostname stored in the controller database.

I understand that LSIO maintains the container rather than the UniFi application. I am posting this as a configuration case study for other users of the LSIO image, not as a confirmed container bug. If this belongs upstream, guidance on the supported way to reconcile the settings would still be helpful.

This is an observation from one existing installation. I have not reproduced it on a clean installation or established whether the cause is in UniFi Network, configuration carried over from an earlier installation, or the container environment.

Environment

• UniFi Network Application: 10.5.67.
• Container image: lscr.io/linuxserver/unifi-network-application:10.5.67-ls142.
• MongoDB: separate mongo:4.4 container.
• Host: Synology NAS, Docker Engine 20.10.3.
• Device: UXG-Max, firmware 5.1.26.33914.
• Existing controller configuration, with a previous migration from Network 9.x to 10.5.67 in its history. A causal link to that migration has not been established.
• The UXG WAN and controller host were on the same upstream subnet. The UXG LAN used a separate, non-overlapping subnet.

CONTROLLER_IP below replaces the actual controller address. It is a placeholder, not a literal hostname used by the installation.

Observed behavior

The UXG remained unreachable/offline in the controller after an incomplete adoption attempt.

In the controller UI, Inform Host Override was enabled and displayed the correct controller IP, without a port or path.

However, running info directly over SSH on the UXG returned:

Status: Unreachable (http://example-domain.ui.com:8080/inform)

example-domain.ui.com was the actual hostname reported by the device, not an anonymized replacement.

Checks that narrowed it down

1. A request made directly from the UXG to http://CONTROLLER_IP:8080/inform returned HTTP 400. This established reachability of the Inform endpoint; a browser-style GET does not establish a successful Inform exchange or completed adoption.

2. The UXG had a valid DHCP WAN address, a default route in its WAN policy-routing table, and synchronized NTP.

3. The controller database contained these conflicting settings:

   super_mgmt.override_inform_host          = true
   super_mgmt.override_inform_host_location = CONTROLLER_IP
   super_identity.hostname                 = example-domain.ui.com
   

4. The controller's device record already contained the correct Inform URL, while the device's own info output showed the stale hostname.

Earlier adoption logs also included inform decryption failed with defaultAuthKey=false and an adoption timeout. Those messages alone did not establish an authentication-key mismatch as the root cause.

Recovery performed in this installation

After creating and verifying a native Network 10.5.67 backup and preparing a rollback:

1. We changed only super_identity.hostname to match the correct controller IP, leaving the existing Override settings unchanged.

2. We restarted only the UniFi Network application container and verified that 10.5.67 was responding again.

3. On the UXG, we ran once, with the actual controller IP substituted:

   /usr/bin/mca-cli-op set-inform http://CONTROLLER_IP:8080/inform

4. We checked the device's info output and the controller's status and subsequent contacts.

The targeted database edit describes what we did in this installation; it is not presented as an official or generally recommended repair procedure. We would prefer a supported UI/API method if one exists.

Result and limits

The UXG reported:

Status: Connected (http://CONTROLLER_IP:8080/inform)

The controller showed the gateway online and up to date, with a connected client and traffic. The initial-adoption waiting flags disappeared, and contact timestamps continued advancing over approximately five minutes. No new Inform-decryption errors were found in the reviewed post-restart log interval.

No factory reset, device-record deletion, management-key replacement, further Adopt action, firmware update, or routing change was needed during this recovery. Other NAS services remained available.

This was a short observation window. Persistence across a gateway reboot, a WAN lease renewal, or long-term operation has not been tested. Since the hostname alignment, application restart, and set-inform were performed in sequence, this case does not isolate the effect of each individual step.

Questions for maintainers / others who have seen this

• Is it expected that the UI's Inform Host Override can be correct while super_identity.hostname still contains a different hostname?
• Under what circumstances can the device receive or retain that stale hostname despite the configured Override?
• Is there a supported UI/API operation to reconcile these settings without editing the database?
• Has anyone reproduced this with existing or migrated controller configurations?

Related upstream context: an older Ubiquiti Community answer says that changing the Inform Host Override updates the hostname. That does not establish the cause of the discrepancy observed here or a new regression.

I can provide additional sanitized observations if useful. This report intentionally excludes credentials, management keys, database URIs containing credentials, device identifiers, and raw support archives.

[aappuupatell]

Short version: this isn't the container, and the database edit almost certainly did nothing — the set-inform is what fixed it. Your four questions in order:

1. Override shows the right value while super_identity.hostname holds something else — expected? Yes, they're two different settings. super_identity.hostname is the old "Controller / Network Application Hostname/IP" identity field; in older releases that's what "Override inform host with controller hostname/IP" used, and it rides along untouched through migrations. In 9.x/10.x the override is its own pair, super_mgmt.override_inform_host + override_inform_host_location, which is what the UI shows and what devices get provisioned with. A migrated DB with a stale hostname in super_identity next to a correct override is normal, not corruption.

2. How did the UXG keep the stale hostname despite the override? Because the override is pushed, and only to devices the controller is actually managing. Every UniFi device stores its own inform URL and auth key and keeps using them until a controller completes a provision or you run set-inform. The example-domain.ui.com:8080/inform came from the UXG's previous adoption, not from this controller. It couldn't receive the new URL because adoption never completed: "Inform decryption failure … defaultAuthKey=false" means the device was encrypting informs with a non-default key — it still considered itself adopted. A clean controller can never decrypt that; a migrated one that still holds the device's record and key can, which is why one set-inform to the controller IP was enough to flip it to Connected. Of your three steps, only that one touches the device.

3. Supported way to reconcile without touching Mongo? For devices that are already talking to the controller: Devices → gear (Device Updates and Settings) → Device Settings → Inform Host Override → Apply pushes the URL to everything managed. For a device that isn't talking to it (your case) the supported tools are device-side: set-inform http://CONTROLLER_IP:8080/inform over SSH (run it twice if it sits at Pending), or the L3 methods — a DNS record unifi → controller IP, or DHCP option 43. If the controller doesn't hold the device's key, factory reset + re-adopt is the only route Ubiquiti supports. I'd leave super_identity.hostname alone unless something that uses it (notifications, legacy redirects) misbehaves.

4. Reproduced? It's the standard "device adopted elsewhere / controller migrated" behaviour rather than anything 10.5.67- or LSIO-specific; the lscr.io image runs the stock Network application, so there's nothing for LSIO to change. The Ubiquiti community is the right place if you want them to clear super_identity.hostname on migration.