ACL Tagging: "no associated IPs for user"

I shared a machine with another person outside my network. They accepted the invite and installed Tailscale on their machine.

I can’t seem to use that user in my ACL tags. In the ACL editor I get the error:

Error: test(s) failed
test(s) failed for user:
no associated IPs for user (check spelling, or they may not have an approved machine)

This is my ACL JSON:

// Example/default ACLs for unrestricted connections.
  // Declare static groups of users beyond those in the identity service.
  "Groups": {
    "group:admins": [""],
    "group:parsec": ["", ""],
  // Declare convenient hostname aliases to use in place of IP addresses.
  "Hosts": {
    "viewscreen": "",
  "TagOwners": {
    "tag:untrusted-server": ["group:admins"],
  // Access control lists.
  "ACLs": [
    // Match absolutely everything. Comment out this section if you want
    // to define specific ACL restrictions.
    { "Action": "accept", "Users": ["group:parsec"], "Ports": ["viewscreen:8000-8010"] },
    { "Action": "accept", "Users": ["group:admins"], "Ports": ["*:*"] },
  // Declare tests to check functionality of ACL rules
  "Tests": [
		"User": "",
		"Allow": ["viewscreen:8000"],
		"User": "",
		"Allow": ["viewscreen:8000", "viewscreen:8001"],

I’ve obviously changed the email addresses above but in the actual editor they are correct and I checked for typos.

Can I only create ACL rules against users in my network and not users I’ve shared machines with?

External users in ACLs are not currently supported as per the docs: ACLs, ABAC, RBAC, and network security policies · Tailscale

For explicitness, you must include the full email address of each user (or alice@github for GitHub user @alice ). However, Tailscale currently only lets you share your nodes with users inside the same domain as you. If you write an ACL that permits users outside your domain, it will be silently ignored. Eventually, we will allow inviting users outside your domain.

1 Like

So I read that but it wasn’t entirely clear to me. Technically we’re on the same domain, Gmail, but I suppose it means “same custom domain”? Or “same account”?

Also these limitations are hard to reason about and scattered around the docs. For example, I got pretty far into understanding ACL Tags before reading that you couldn’t use them on Windows hosts.

So I can share my Windows VM with my friend, but essentially that means letting them access that host and through it anything in my private Tailscale network, since they’ll have access to my Tailscale account on that VM. Seems like a pretty simple use case that doesn’t work with Tailscale, unless I’m missing something?

I think I read somewhere that they treat domains like differently than custom domains but can’t quite find where that was, which just emphasizes your point about the docs being a bit scattered so far. I’m giving them a bit of leeway on the docs since they’re obviously still in a pretty early stage.

Really hoping they add tags to non-Linux hosts pretty soon though since I need that to move my current business implementation out of a pilot phase since it’s really hard to scale the ACLs to even dozens of hosts without that feature in the Windows client for us.

1 Like

Ah, while I was looking for something else, I found the reference about domains: Inviting others to your network · Tailscale

Signups using shared email hosts such as or GitHub personal accounts are limited to the solo plan, and can currently only have one user.
We recommend you check out our sharing feature instead that lets you securely share machines with other Tailscale networks.

1 Like

The same error message appears when you have no devices of your own. This happens when you put tags on all your devices, which basically removes you as an owner from all those devices.

What is not immediately clear from the error message, is that the “test” field seems to run a connectivity test from a device owned by yourself. Which of course will not work if you do not own any devices anymore.

So I don’t think this is correlated to the restrictions per se. Took me some time to figure out.

The solution was to always keep one of the devices under your own control, which is nothing but normal. However, I think this could be mentioned/alerted somewhere more explicitly.