From 98fab394a14c036c76ec4a6f2d3a86fa955869a5 Mon Sep 17 00:00:00 2001 From: Gmer4Lfe Date: Sun, 16 Aug 2026 13:43:02 -0400 Subject: [PATCH] Resolve the partner through the shared Tailscale resolver, so a shared-tailnet peer is findable --- Plugin/unraid/api/setup.php | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/Plugin/unraid/api/setup.php b/Plugin/unraid/api/setup.php index c95c72c..60ffc05 100644 --- a/Plugin/unraid/api/setup.php +++ b/Plugin/unraid/api/setup.php @@ -234,11 +234,24 @@ if ($action === 'pull') { exit; } - // Resolve HOST1 Tailscale IP - $ip = trim(shell_exec('tailscale ip -4 ' . escapeshellarg($host1Hostname) . ' 2>/dev/null') ?: ''); + // Resolve HOST1's Tailscale IP through the shared resolver, not a bare `tailscale ip -4`. + // + // master.conf records the OS hostname (unRAID-Gmer4Lfe). Tailscale knows the same machine by + // its own name, and when the two nodes are in different tailnets linked by node sharing, a + // shared peer is only addressable by its full name — `unraid-gmer4lfe.tonkinese-monster.ts.net` + // resolves while both `unRAID-Gmer4Lfe` and `unraid-gmer4lfe` fall through to public DNS and + // fail. A bare lookup therefore reported "is Tailscale running on both servers?" on a mesh + // where Tailscale was running perfectly on both. + // + // vv_resolve_tailscale_ip() already handles this: it tries the direct lookup, then falls back + // to an unambiguous prefix match against `tailscale status` with the domain stripped, and + // refuses to guess when more than one peer could qualify. + $ip = vv_resolve_tailscale_ip($host1Hostname); if (!$ip) { echo json_encode(['ok' => false, 'error' => - "Cannot resolve Tailscale IP for $host1Hostname — is Tailscale running on both servers?"]); + "Cannot resolve a Tailscale address for $host1Hostname. Check `tailscale status` on " + . "this server — the name in master.conf must match a peer there, or be an unambiguous " + . "prefix of one."]); exit; }