sync: auto-sync from GURU-5070 at 2026-06-26 08:02:22

Author: Mike Swanson
Machine: GURU-5070
Timestamp: 2026-06-26 08:02:22
This commit is contained in:
2026-06-26 08:03:21 -07:00
parent 270e294938
commit bd52dde6a7
4 changed files with 116 additions and 1 deletions

View File

@@ -2,10 +2,12 @@
type: client
name: wolkin
display_name: Wolkin Law
last_compiled: 2026-06-11
last_compiled: 2026-06-26
compiled_by: GURU-5070/claude-main
aliases: [wolkin-law, rswolkin, robert-wolkin, "Wolkin, Robert"]
sources:
- 2026-06-26 SMB-down incident - FRONT ZeroTier adapter re-enabled (mike)
- clients/wolkin/session-logs/2026-06/2026-06-25-howard-scanner-scan-to-folder-front-static-ip.md
- clients/wolkin/session-logs/2026-06-05-julie-guda-provisioning.md
- clients/wolkin/session-logs/2026-06-06-mike-gemini-install-rmm-diagnostic-tailscale-planning.md
- clients/wolkin/session-logs/2026-06-07-mike-zerotier-setup.md
@@ -75,6 +77,17 @@ backlinks: []
- **ZeroTier VPN Network:** 17d709436c834c9b (mesh topology, connects remote workers to office)
- **Printer:** Sharp MX-B557F (driver "Sharp Universal v2 XL") at 192.168.1.158, raw TCP 9100. Shared as `\\front\Sharp`. (FRONT was moved from a flaky WSD port to a Standard TCP/IP 9100 port.)
> [CRITICAL] **ZeroTier on FRONT must stay ENABLED — it is Julie's only path to her work.**
> Julie works remotely from RSW-Laptop and reaches FRONT's file shares + printer **solely over
> the ZeroTier mesh** (`10.147.19.0/24`). If FRONT's ZeroTier adapter is disabled/down (even
> with the ZT *service* running), FRONT loses its `10.147.19.199` IP and **all remote SMB/print
> for Julie breaks**, while in-office machines are unaffected (so it's easy to miss). Do NOT
> disable FRONT's ZeroTier adapter during in-office troubleshooting (e.g. name-resolution/scanner
> work) — if you must, **re-enable it before leaving**. Re-enable:
> `Enable-NetAdapter -InterfaceDescription "ZeroTier Virtual Port" -Confirm:$false` (the adapter
> name `ZeroTier One [..]` has `[ ]` PowerShell wildcards — target it by `-InterfaceDescription`).
> Verify `10.147.19.199` returns and FRONT can ping `10.147.19.54` (Julie's laptop).
**SMB Shares on FRONT (LAN `\\front\` or ZeroTier `\\10.147.19.199\`):**
- `\\front\ClientFiles``C:\Shared Data\CLIENT FILES` (canonical 413-matter repo; corrected 2026-06-08, share ACL Authenticated Users, `front\julie` NTFS Modify)
- `\\front\Forms``C:\Users\Owner\OneDrive\Desktop\Forms`
@@ -92,6 +105,16 @@ backlinks: []
- **Vault path:** `clients/wolkin/`
## Patterns & Known Issues
- **FRONT ZeroTier adapter disabled -> all of Julie's remote SMB/print is down (2026-06-26):**
Julie reported "SMB isn't working." FRONT's SMB server was healthy (LanmanServer up, 445
listening, all shares present) but FRONT had **no `10.147.19.199`** — its ZeroTier adapter
(`ZeroTier One [17d709436c834c9b]`) was **administratively Disabled**, even though the ZeroTier
*service* was ONLINE and `listnetworks` showed the network OK with the IP assigned. A disabled
adapter = no IP plumbed = FRONT unreachable over ZT = remote SMB/print fails for every remote
worker (in-office unaffected). **Fix:** `Enable-NetAdapter -InterfaceDescription "ZeroTier
Virtual Port"` -> IP `10.147.19.199` returned, FRONT pings RSW-Laptop. Almost certainly
disabled during the **2026-06-25** in-office scanner/static-IP work (where the ZT IP was the
name-resolution confounder) and not re-enabled. See the CRITICAL callout in Infrastructure.
- **macOS Syncro JSON parsing:** Syncro customer lookup from Mac failed due to JSON parsing issues (2026-06-07). Use Windows PC for Syncro API operations or manual web portal lookups.
- **ZeroTier print RPC needs Private profile:** File-and-Printer-Sharing inbound rules (incl. Print Spooler RPC) apply to the Private profile only. The ZeroTier interface was Public on both FRONT and RSW-Laptop, which blocked print/RPC over ZT while file SMB still worked. Fix: set the ZT interface Private on both ends. (Confirmed still Private both ends 2026-06-11.)
- **[MEASUREMENT ARTIFACT — not a real fault] SMB/printer tests via the GuruRMM agent give FALSE error 67 / RPC 1702; the real interactive session works.** The printer to `\\front\Sharp` **works** for Julie when she is logged in (confirmed 2026-06-11 by remoting in). But every SMB test run through the **GuruRMM agent's `user_session` context fails**`net use \\FRONT\IPC$` (and by IP) → System error 67, `net view` → RPC 1702, `Add-Printer -ConnectionName` → 67 — **even with valid `FRONT\julie` creds.** Cause: still unresolved, but NOT a naive impersonation defect — the agent runs these AS the user correctly (`WTSQueryUserToken``DuplicateTokenEx(TokenPrimary)``CreateProcessAsUserW`; `whoami` returns `rsw-laptop\julie`), and error 67 persists even with explicit creds (so not an SSO/credential gap). Suspect UAC split-token (`EnableLinkedConnections`) or missing window-station/profile in the spawned context. Tracked in GuruRMM RMM_THOUGHTS. Regardless of cause, RMM is NOT measuring what Julie's real logon sees. The underlying plumbing is genuinely fine (ZeroTier up, 445/139 open, MTU 2800 full DF, FRONT shared + Private + SMB-In, bindings present) — which is why it prints interactively. **Rule: do NOT use RMM `net use`/`net view`/`Add-Printer` to judge SMB/printer health to a remote host — its 67/1702 means "can't tell," not "broken." Verify via the real session (ScreenConnect).** The 2026-06-07 "wall" was this same artifact (Mike's "manual fix" worked only because it was interactive). See [[../../.claude/memory/feedback_rmm_user_session_smb_false_negative]]. Unrelated tip: `Get-NetAdapterBinding -Name "ZeroTier One [..]"` returns empty because `[ ]` are PowerShell wildcards — use `-InterfaceDescription "ZeroTier Virtual Port"`.
@@ -112,6 +135,11 @@ backlinks: []
- [ ] Bob to file the 67 loose docs in `CLIENT FILES\Closed Files\_From OneDrive Documents`.
## History Highlights
- **2026-06-26:** Julie "SMB isn't working." Root cause: FRONT's **ZeroTier adapter was Disabled**
(no `10.147.19.199`), breaking the only path remote workers have to FRONT's shares; SMB server
itself was fine. Re-enabled the adapter via RMM, IP restored, FRONT pings the laptop. Likely
disabled during the prior day's scanner/static-IP work. Added a CRITICAL "ZeroTier required for
Julie" callout + Patterns entry so this isn't repeated.
- **2026-06-11:** Printer re-reported down (Julie "no printers"). Full re-diagnosis via RMM: confirmed the error-67 SMB wall (see Patterns) — plumbing all clean, needs interactive fix. **Data-hygiene remediation:** consolidated the four fragmented client slugs into canonical `wolkin`; moved all scattered logs/baselines into `clients/wolkin/`; vaulted `front\julie` + the M365 user passwords (which had been sitting plaintext in the wiki / only in session logs); corrected the cross-client FRONT agent-id error; captured the error-67 gotcha as a memory.
- **2026-06-08:** ClientFiles corrected to the real local repo + full consolidation + VSS
- Repointed `\\front\ClientFiles` to canonical `C:\Shared Data\CLIENT FILES` (413 matters); tightened share ACL; `front\julie` NTFS Modify