Regular (non-admin) users can't view peers they don't own since v0.70 (#6006); no setting restores it through v0.75.0-rc.3

[zerotohero]

Before posting

• I searched existing discussions and issues, including closed ones, and checked the relevant docs.
• I believe this is a product bug rather than a configuration or setup question.
• I can reproduce this issue, or for intermittent issues I've included trigger, frequency, and timing details below.
• I removed or anonymized sensitive data from logs, screenshots, and configuration.

Affected area

Dashboard / Admin UI, Self-hosting / Deployment

Deployment type

Self-hosted - advanced/custom deployment

Operating system or environment

Linux, Docker, Browser

NetBird version and upgrade status

• Client: N/A (server-side visibility behavior; affects all clients' dashboard view)
• Management: 0.73.2
• Signal: 0.73.x
• Relay: 0.73.x
• Dashboard: v2.x (post the "cloud edition" merge)
• Upgrade status: reproduced on the current stable line (Management 0.73.2). The responsible code is also unchanged in the source at v0.74.0-rc.2 and v0.75.0-rc.3, so upgrading does not resolve it.

Did this work before?

Yes, this worked before

Regression details

• Last known working version: 0.69.0 (regular users could view peers reachable via group/policy)
• First known broken version: 0.70.0
• Recent changes: management/dashboard were upgraded across the 0.69 → 0.70+ line. No changes were made to user roles, groups, policies, or the "Restrict dashboard for regular users" setting (it was and remains OFF).

Summary

Since v0.70.0, regular (user-role) accounts can only see peers they personally registered in the dashboard. Peers belonging to other users — previously visible based on group/policy reachability — no longer appear, even though "Restrict dashboard for regular users" is OFF. There is no account setting that restores the previous visibility in open source.

Current behavior

A regular (non-admin) user opens the Peers page and sees only the peer(s) they personally registered. With "Restrict dashboard for regular users" OFF, they previously saw all peers reachable via policy. WireGuard connectivity between peers is unaffected — this is dashboard / management-API visibility only.

Root cause: PR #6006 ("[management] Drop netmap calculation on peer read", merged 2026-04-28) changed GetPeers in management/server/peer.go to return only the requesting user's owned peers when they lack the peers:read permission, removing the prior policy-aware expansion (getUserAccessiblePeers / GetPeerConnectionResources). The logic is identical at v0.73.2, v0.74.0-rc.2, and v0.75.0-rc.3:

allowed = ValidateUserPermissions(Peers, Read)
if allowed:                  return GetAccountPeers(...)   // all peers (admin/owner)
if RegularUsersViewBlocked:  return []                     // none
                             return GetUserPeers(...)       // only the user's OWN peers

As a result, RegularUsersViewBlocked is now effectively binary for non-admins — "own peers" (off) vs "no peers" (on) — and no value gives a regular user visibility of peers they don't own. In open source, no role short of admin carries peers:read, so the only way to give a user the full peer list is to make them an admin (which also grants config write).

Expected behavior

With "Restrict dashboard for regular users" OFF, regular users should be able to view peers (as before v0.70 and as the docs still describe). If the permission-gated model is intentional, there should be an open-source account setting or a non-admin role/capability that allows regular users to view all (or policy-reachable) peers without granting full admin — and the docs should be updated to match the current behavior.

Steps to reproduce

1. Self-host NetBird v0.70.0 or later (reproduced on Management 0.73.2; logic also present in v0.74.0-rc.2 and v0.75.0-rc.3).
2. Create several peers registered by different users, with groups/policies so a regular user's peers can reach other peers. Confirm Settings → "Restrict dashboard for regular users" is OFF.
3. Log in to the dashboard as a regular (non-admin) user.
4. Open the Peers page.
5. Observe: only the peers that user personally registered are listed. On v0.69.x the same user saw all policy-reachable peers.

Environment and topology

• Peer A / Peer B: N/A (visibility issue, not a connectivity issue)
• Same LAN or different networks: N/A
• NAT/CGNAT/corporate firewall/mobile network: N/A
• Other VPN software: None
• Firewall, DNS, or endpoint security software: N/A
• Routes, DNS, policies, posture checks, or SSH rules involved: Groups + access policies are configured; regular users previously saw peers made reachable by those policies.
• IdP, reverse proxy, or browser involved: IdP = Google (OIDC); no external reverse proxy; browser = Chrome.

Self-hosted details, if available

• Deployment method: Docker Compose (standard quickstart artifacts)
• Management/signal/relay/dashboard versions: 0.73.2 / 0.73.x / 0.73.x / dashboard v2.x
• Reverse proxy: none (TLS via certbot in the dashboard container)
• IdP/provider: Google Workspace (OIDC)
• STUN/TURN/coturn/relay details: coturn (host network); NetBird relay
• Relevant component logs: management returns a filtered (owned-only) peer set for non-admin users; see Additional context for the source path and account-setting value.

Logs, status output, or debug evidence

N/A — UI/management-API visibility report. The decisive evidence is source-level (the `GetPeers` logic above) plus the account setting value (see Additional context); `netbird status -d` is not relevant since peer connectivity is unaffected.

Related issues or discussions

• Related discussion (community forum, no maintainer response): https://forum.netbird.io/t/regular-users-lose-peer-list-visibility-after-upgrading-from-0-69-0-to-0-70-x-possible-pr-6006-regression/728
• Likely cause: PR [management] Drop netmap calculation on peer read #6006 — "[management] Drop netmap calculation on peer read"
• Why it may be the same: same symptom (regular users lose peer visibility starting 0.70.x), and the PR's diff matches the observed behavior.

Impact

• Affected users/peers: a self-hosted deployment with 100+ peers; multiple regular users who can no longer see the peers they work with.
• Business/production impact: regular users lose the shared peer overview they previously relied on; the only workaround over-privileges them.
• Workaround available: grant the affected users the admin role (carries peers:read), but this also grants config write — not acceptable as a general solution. No non-admin workaround exists in open source.

Additional context

• The account setting was verified directly in the management store: regular_users_view_blocked = false (i.e. "Restrict dashboard for regular users" is genuinely OFF), yet regular users still see only their own peers — confirming this is a server-side authorization change, not a configuration issue.
• The policy-aware helpers getUserAccessiblePeers and GetPeerConnectionResources were removed from the peer-read path in [management] Drop netmap calculation on peer read #6006 and have not been reinstated through v0.75.0-rc.3.
• Documentation still describes the older behavior (regular users can view peers, governed by the restricted-dashboard setting), so at minimum the docs are out of date.
• Request: restore an open-source way for regular users to view all (or policy-reachable) peers without full admin — e.g., honor RegularUsersViewBlocked = false as "view all" again, or add a non-admin peers:read capability — and update the docs accordingly.

[a-elkaim]

I opened another discussion on the subject with a technical proposal to fix the issue: #6680

[zerotohero]

Draft PR for this regression is up: #6771

It adds an opt-in, default-off account setting RegularUsersGroupPeersViewEnabled that lets regular users see peers of the groups they belong to (own peers ∪ group peers), while RegularUsersViewBlocked keeps precedence. Approach and discussion are in #6680.