“Peer is already registered by a different User or a Setup Key” means that the identity stored on the device is already associated with another enrolment identity on the management server.

We identify a peer primarily by its cryptographic public key, not simply by its hostname, username or IP address. When the device attempts to register using a different user or setup key, The NetBird client blocks the request to prevent an existing peer from being reassigned without authorisation.

DO NOT TREAT THIS LIGHTLY - THIS IS A RED FLAG ERROR

Common causes

• The device was originally enrolled with a setup key, but someone is now attempting to sign in interactively with a user account.
• The device was registered by one user and is now being enrolled by another user.
• A setup key belonging to a different account, tenant or deployment is being used.
• A virtual machine or system image was cloned after the client had already generated its peer identity. Multiple machines then present the same cryptographic identity.
• NetBird was reinstalled, but its existing configuration and identity files were retained.
• The peer was removed or recreated incorrectly in the dashboard while the device retained its previous identity.
• The client has been changed to use a different management server while retaining identity data from the previous server.

A revoked or expired setup key normally produces a different error. This message specifically indicates an ownership or enrolment-method conflict.

Using the existing registration

If the peer is already registered correctly, it does not normally need to be enrolled again. Bring the existing peer online with:

netbird up

Its current state can be checked with:

netbird status -d

For a user-owned peer, authentication must use the same account and user identity that originally registered it. For a setup-key peer, avoid switching to interactive user authentication unless the peer is intentionally being reassigned.

Reassigning the device to another user or setup key

Reassignment should be performed as a controlled re-enrolment, and should be avoided where possible. Everything we do is to reduce risk, and a re-enrolment of a peer is a risky process. 

Cloned computers and virtual machines

An enrolled machine must not be cloned with its existing identity intact. Doing so causes every clone to use the same peer key, leading to registration conflicts and unreliable connectivity.

For templates and golden images:

• Stop NetBird before capturing the image.
• Remove the template’s peer identity using the organisation’s approved image-preparation process.
• Do not embed a reusable setup key unless its permissions, expiry and usage limit are appropriately restricted.
• Enrol each deployed machine separately so that it generates a unique peer identity.

Simply changing the clone’s hostname does not resolve the problem because the cryptographic peer identity remains unchanged.

If the message continues after removing the peer

The local device may still contain stale identity data. Reinstalling the application alone may not remove this data, particularly when application data is deliberately preserved.

Before performing a full local reset:

• Confirm that the old peer has been deleted from the correct account.
• Confirm that the client is configured for the correct management server.
• Confirm that the intended user or setup key belongs to that same account.
• Stop the NetBird service before removing or resetting application state.
• Re-enrol the device only once; repeated attempts using different users and setup keys can make diagnosis more difficult.

A full identity reset creates a new peer from NetBird’s perspective. Any previous peer IP address, groups, policies, routes and approvals may therefore need to be reapplied.

This error is a security safeguard rather than a general connectivity fault: it prevents possession of an existing device identity from being used to transfer that peer silently to another user or enrolment key.