Give a family member a corner of your personal tailnet (and a headless Mac mini that stays up)

Explanation

The short version

1. Fix the policy before you invite anyone. A new tailnet starts with an allow-all policy (S11). Invite someone into that and they get every device.
2. They log in as themselves. Ownership follows the Tailscale login. autogroup:self only works if the Mini is their device.
3. Limit Funnel. Funnel publishes a local service to the internet. Turning it on from the CLI gives every member that power by default (S3).
4. A headless Mac has to survive three things: idle sleep, a reboot, and a power cut. For us that meant sleep 0, autorestart 1, auto-login into a standard account, and therefore FileVault off.

Verdict

Not yet. The policy and invite are done, and the Mac settings are applied or queued. The proof is still missing: the family member's device actually being boxed in, and the Mini coming back from a restart nobody touched. The tests block in the policy is the part we'd recommend today without reservation, because it makes the policy refuse to save if isolation ever regresses.

Fit

Goal: Let one more person (a family member, a guest, a contractor) use your tailnet for their own laptop and their own always-on Mac without being able to reach anything else of yours.

Environment

• Tailscale personal tailnet, policy managed in the admin console
• Apple-silicon Mac mini on a current macOS release (26 or later), intended to run headless
• Tailscale grants syntax as documented 'Last validated Apr 8, 2026'
• macOS 26 or later (FileVault-over-SSH unlock needs 26+)

Prerequisites

• You are the tailnet Owner or an Admin
• The family member has their own identity-provider login (e.g. their own email account)
• Physical or screen-sharing access to the Mac with an admin password for the one-time macOS steps

Permissions required

• Edit the tailnet policy file
• Invite users
• macOS admin (sudo) on the Mini, once

Don't use this when

• Organisation tailnets with groups synced from an identity provider: use groups, not this pattern.
• Tagged devices: autogroup:self does not apply to tagged devices, so a tagged Mini would not be 'theirs'.
• Laptops: turning FileVault off is a poor trade on anything portable.

Expected output: A saved policy whose tests prove the isolation, an accepted invite, the Mini logged into Tailscale as the family member, and a Mini that comes back on its own after a reboot or power cut.

Procedure

Policy first (so the invite never lands on an allow-all tailnet), invite second, the family member's own Tailscale login third, Mac power and login settings last. Each write step is gated on the owner.

This pack is reference material, not an instruction to change anyone's tailnet. A consuming agent drafts the changes; the owner applies or approves them.

1. Read the current policy read-only

   Open the policy file and check for the default allow-all rule (S11): a grant (src '*', dst '*') or an equivalent legacy ACL, plus any nodeAttrs funnel entry targeting autogroup:member.

   Expect: You know whether inviting someone today would give them everything.

2. Draft the replacement policy read-only

   Start from packs/assets/bo-002-family-policy.hujson: owner → '*', autogroup:member → autogroup:self, Funnel only for the owner, and tests asserting the isolation. Replace the placeholder addresses.

   Expect: A draft that names real identities and keeps any existing tag grants your bots need. Add those grants back explicitly; the example has none.

3. Save the policy WRITE (gated)

   Paste into the admin console policy editor and save. The tests block makes the save fail if isolation is wrong (S1).

   Expect: Save succeeds; tests pass. Your own devices and bots still reach what they did (check with bo-001 step 4).

   Gate: Tailnet owner. Keep a copy of the old policy text first so it can be restored.

4. Invite the person WRITE (gated)

   Admin console → Users → Invite external users, role Member, by email (S4).

   Expect: Invite shows under status:invited until they accept. Unused invites expire after 30 days.

   Gate: Tailnet owner. Inviting adds a billable user if they're active.

5. Give them their own Mac account WRITE (gated)

   On the Mini, create a standard (not admin) account for them. Apple advises against auto-login into an administrator (S7).

   Expect: A standard account that is theirs.

   Gate: Owner, at the machine or over Screen Sharing, with the admin password.

6. Decide FileVault vs auto-login WRITE (gated)

   Headless and must come back after a power cut → auto-login needs FileVault off (S6). Keep FileVault → someone has to unlock it after every restart, locally or (macOS 26, untested here) over LAN SSH (S8).

   Expect: A written decision. If FileVault goes off: Users & Groups → Automatically log in as → their account.

   Gate: Owner decides; this is a security trade, not a default.

7. Stop it sleeping, restart after power loss WRITE (gated)

   Read first with 'pmset -g', then set system sleep and disk sleep off and auto-restart on.

   pmset -g; sudo pmset -a sleep 0 disksleep 0 autorestart 1

   Expect: pmset -g shows sleep 0, autorestart 1.

   Gate: Owner with sudo on the Mini. Note the old values from 'pmset -g' for rollback.

8. Sharing allow-lists WRITE (gated)

   System Settings → General → Sharing: add their account to Remote Login's 'Only these users' (S9) and to Screen Sharing if they need it. Remove anyone who shouldn't be there.

   Expect: Both lists name exactly the people intended.

   Gate: Owner.

9. Install Standalone Tailscale and log in as them WRITE (gated)

   Install the Standalone variant from Tailscale's package server, not the App Store, and never both (S5). Log out of the admin account. In their session they sign in to Tailscale with their own identity, approve the VPN/system-extension prompt, and enable start at login.

   Expect: The Mini appears in the admin console owned by them, not by you.

   Gate: Installer needs the admin password; the Tailscale login is theirs.

10. Verify isolation from their side probe (no state change)

    From their laptop or the Mini: tailscale status should list only their own devices; a ping or SSH no-op to one of yours should fail. From your side, run bo-001 step 4 against the Mini.

    Expect: They see only theirs; you can still reach the Mini (because the example policy grants you '*').

11. Verify reboot survival probe (no state change) untested

    Restart the Mini (owner-approved), walk away, and from another device wait for it to reappear in tailscale status without anyone touching it.

    Expect: Back online in a few minutes with auto-login and Tailscale running in their session.

Verification

Success check: Policy tests pass on save; tailscale status on the family member's device lists only their devices; the Mini is owned by them in the admin console; after an unattended restart the Mini reappears on the tailnet; pmset -g shows sleep 0 and autorestart 1.

Rollback: Policy: paste back the saved previous policy text, or revert the change from the admin console's Configuration logs page (S11). Invite: delete the invite or remove the user on the Users page. pmset: restore the values captured with 'pmset -g' in step 7. FileVault: can be turned back on in System Settings → Privacy & Security (auto-login turns off). Sharing lists: remove the account.

Not yet tested. Scope: Steps 1–4 and 6–8 were performed on one real tailnet and one Mini in November 2026. Step 9 was pending (the family member's devices had not joined). Steps 10–11, the actual proof of isolation and reboot survival, have not been run. Until they have, treat the verdict as Not yet.

Evidence

Sources

1. S1 Syntax reference for the tailnet policy file, Tailscale (primary). Fetched 2026-11-15; source shows “Last validated Apr 8, 2026”. Supports: autogroup:self selects a user's own devices, doesn't apply to tags; nodeAttrs funnel; tests block rejects a policy save if an assertion fails; tests can't use wildcards.
2. S2 Grants, Tailscale (primary). Fetched 2026-11-15; source shows “Last validated Jul 24, 2026”. Supports: Deny-by-default; grants preferred over legacy ACLs; src/dst/ip structure.
3. S3 Tailscale Funnel, Tailscale (primary). Fetched 2026-11-15; source shows “Last validated Jan 20, 2026”. Supports: Enabling Funnel from the CLI adds a nodeAttrs entry that lets every autogroup:member use it by default; admins can restrict it.
4. S4 Invite any user to your tailnet, Tailscale (primary). Fetched 2026-11-15; source shows “Last validated Jan 5, 2026”. Supports: Invite by email with a chosen role; one account per person; unused invites expire after 30 days; invited users are billed if active; user approval may apply.
5. S5 Three ways to run Tailscale on macOS, Tailscale (primary). Fetched 2026-11-15; source shows “Last validated Jan 5, 2026”. Supports: Standalone variant recommended; neither Standalone nor App Store runs before login; never install both variants.
6. S6 How to log in automatically to a Mac user account, Apple (primary). Fetched 2026-11-15; source shows “Published Date: May 19, 2026”. Supports: Automatic login is unavailable while FileVault is on.
7. S7 If you don't see a login window when you start your Mac, Apple (primary). Fetched 2026-11-15. Supports: Don't let automatic login sign in an administrator; auto-login lets anyone with physical access in.
8. S8 Managing FileVault in macOS (Unlock FileVault using SSH), Apple Platform Security (primary). Fetched 2026-11-15; source shows “Published Date: January 28, 2026”. Supports: On Apple silicon with macOS 26+, FileVault can be unlocked over SSH after a restart if Remote Login is on and a network connection is available.
9. S9 Allow a remote computer to access your Mac, Apple (primary). Fetched 2026-11-15. Supports: Remote Login 'Allow access for: Only these users' list.
10. S10 pmset(1) reference, SS64 (mirror of the pmset man page) (secondary). Fetched 2026-11-15. Supports: sleep / disksleep / autorestart semantics; 'pmset -g' to read current settings. Cross-check with 'man pmset' on the machine itself.
11. S11 ACL policy examples: Allow all (default ACL), Tailscale (primary). Fetched 2026-11-15; source shows “Last validated Feb 2, 2026”. Supports: New tailnets start with an allow-all policy; policy changes can be reverted from the Configuration logs page.

Original observations

• 2026-11 · Personal tailnet, new Apple-silicon Mac mini for a family member: The tailnet still had the default allow-all policy. Inviting anyone into it would have given them every device.
• 2026-11 · Same Mini: System sleep was 1 minute. The Mini answered fine while someone was screen-sharing and would have gone to sleep about a minute after they disconnected.
• 2026-11 · Same Mini: FileVault was on, so automatic login was greyed out. The owner turned FileVault off so the family member's standard account could log in automatically. That trade is deliberate; see Uncertainty.
• 2026-11 · Same Mini: Remote Login and Screen Sharing allowed only the owner's admin account. The family member's account had to be added to each list separately.
• 2026-11 · Same Mini: Automatic installation of macOS updates was on, and a newer macOS release was being offered. A headless machine that upgrades and reboots by itself is a surprise reboot you didn't schedule. We recommended turning automatic macOS installs off and updating on purpose.
• 2026-11 · Same tailnet: The new policy saved and the invite was accepted. When we checked, none of the family member's devices had joined yet, so the isolation is configured but not yet observed working.

Test environment: One personal tailnet and one Apple-silicon Mac mini on a current macOS release, November 2026. Policy edits made in the admin console by the owner.

Measured outcomes

None.

Uncertainty

• Turning FileVault off removes the extra at-rest protection. Apple silicon still encrypts the disk, but without FileVault it unlocks with no password (Apple's FileVault overview). For a Mini that never leaves the house this was our owner's call. For anything portable, don't.
• macOS 26 can unlock FileVault over SSH after a restart (S8). We have not tested it. The Standalone Tailscale client doesn't run before login (S5), so we expect that unlock to work only from the local network, not over the tailnet. That's inferred, not tested.
• Community reports say pre-boot SSH unlock broke or was flaky on some 26.x point releases and on Wi-Fi. Treat it as a bonus, not a plan.
• The 'lock the screen right after auto-login' preference some admins set is not in Apple's public docs; we don't cite a command for it.

Counterexamples

• If the owner logs the Mini into Tailscale with the owner's own account, the device belongs to the owner and autogroup:self gives the family member no access to it. Ownership follows the login, not who uses the machine.

Files shipped with this pack

• packs/assets/bo-002-family-policy.hujson

Rights and integrity

License: CC BY 4.0 for text; policy example CC0. Provenance: Gus, from a real setup with all names, addresses and device identifiers removed. Vendor behaviour tied to sources fetched 2026-11-15.

Permissions: Dry-run by default. Every write step names who must approve it. The pack itself authorises nothing. Telemetry: None.

Content digest: sha256:3bd41361d6cf92feb0651cb1f94dc99f96a70181cf3d134e465707eb76e21f3a
SHA-256 of the canonical source file packs/bo-002-guest-on-personal-tailnet.md as built. Identifies content; does not prove authorship.

Changelog

• 0.1.0 · 2026-11-15: First private draft, written from a setup we did this month. Policy saved in production; isolation not yet verified end to end.

Related packs

• bo-001-tailnet-connection-triage