[Bug] If an unknown user is added to a group, the entire group do not work

[brandonfl]

Is this a support request?

• This is not a support request

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

The issue #2863 seems to be present on version v0.27.1 with groups

We currently have a OIDC and we try to pre-assign group to users that are not already existing.
This make the group not work at all.

On this exemple, the users of the group:developer can not access to exit nodes because one of the user of the group is not already existing :

{
  "acls": [
    (...)
    {
      "action": "accept",
      "src": [
        "group:developer"
      ],
      "dst": [
        "autogroup:internet:*"
      ]
    },
   (...)
  ],
  (...)
  "groups": {
    "group:developer": [
      "xxx@xxx.com",
      "xxx@xxx.com",
      "xxx@xxx.com",
      "xxx@xxx.com",
      "xxx@xxx.com"
    ]
  }
}

Expected Behavior

The group should work even if some users are not existing

Steps To Reproduce

Create group with users that are not already existing to the headscale and to a ACL rule with that group

Environment

docker image headscale/headscale:stable

headscale version v0.27.1+dirty
commit: f658a8eacd4d86edc65424b50635afed46ca4b2a
build time: 2025-11-11T19:17:02Z
built with: go1.25.1 linux/amd64

Tailscale version: 1.92.5

Runtime environment

• Headscale is behind a (reverse) proxy
• Headscale runs in a container

Debug information

None

[nblock]

This should be fixed in the upcoming 0.28 release. Are you able to test 0.28.0-beta.2 to see if it works?

[brandonfl]

@nblock there are others issues on the beta version that block me to update like the #2990 for example

[kradalby]

#2990 is closed, and the changes to solve that closely resemble the issue you describe, can you please test main?

[github-actions]

Thank you for taking the time to report this issue.

To help us investigate and resolve this, we need more information. Please provide the following:

Tip

Most issues turn out to be configuration errors rather than bugs. We encourage you to discuss your problem in our Discord community before opening an issue. The community can often help identify misconfigurations quickly, saving everyone time.

Required Information

Environment Details

• Headscale version: (run headscale version)
• Tailscale client version: (run tailscale version)
• Operating System: (e.g., Ubuntu 24.04, macOS 14, Windows 11)
• Deployment method: (binary, Docker, Kubernetes, etc.)
• Reverse proxy: (if applicable: nginx, Traefik, Caddy, etc. - include configuration)

Debug Information

Please follow our Debugging and Troubleshooting Guide and provide:

1. Client netmap dump (from affected Tailscale client):

   tailscale debug netmap > netmap.json

2. Client status dump (from affected Tailscale client):

   tailscale status --json > status.json

3. Tailscale client logs (if experiencing client issues):

   tailscale debug daemon-logs

   [!IMPORTANT]
   We need logs from multiple nodes to understand the full picture:

   • The node(s) initiating connections
   • The node(s) being connected to

   Without logs from both sides, we cannot diagnose connectivity issues.

4. Headscale server logs with log.level: trace enabled

5. Headscale configuration (with sensitive values redacted - see rules below)

6. ACL/Policy configuration (if using ACLs)

7. Proxy/Docker configuration (if applicable - nginx.conf, docker-compose.yml, Traefik config, etc.)

Formatting Requirements

• Attach long files - Do not paste large logs or configurations inline. Use GitHub file attachments or GitHub Gists.
• Use proper Markdown - Format code blocks, logs, and configurations with appropriate syntax highlighting.
• Structure your response - Use the headings above to organize your information clearly.

Redaction Rules

Caution

Replace, do not remove. Removing information makes debugging impossible.

When redacting sensitive information:

• ✅ Replace consistently - If you change alice@company.com to user1@example.com, use user1@example.com everywhere (logs, config, policy, etc.)
• ✅ Use meaningful placeholders - user1@example.com, bob@example.com, my-secret-key are acceptable
• ❌ Never remove information - Gaps in data prevent us from correlating events across logs
• ❌ Never redact IP addresses - We need the actual IPs to trace network paths and identify issues

If redaction rules are not followed, we will be unable to debug the issue and will have to close it.

---

Note: This issue will be automatically closed in 3 days if no additional information is provided. Once you reply with the requested information, the needs-more-info label will be removed automatically.

If you need help gathering this information, please visit our Discord community.

[kradalby]

Closing due to lack of response, if the issue persist, please open a new issue with the appropriate debug information.