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
2026-06-26 08:03:21 -07:00
parent 270e294938
commit bd52dde6a7
4 changed files with 116 additions and 1 deletions
--- a/clients/wolkin/session-logs/2026-06/2026-06-26-mike-wolkin-smb-zerotier-adapter.md
+++ b/clients/wolkin/session-logs/2026-06/2026-06-26-mike-wolkin-smb-zerotier-adapter.md
@@ -0,0 +1,45 @@
+# 2026-06-26 — Wolkin: Julie "SMB isn't working" — FRONT ZeroTier adapter was disabled
+
+## User
+- **User:** Mike Swanson (mike)
+- **Machine:** GURU-5070
+- **Role:** admin
+
+## Summary
+Julie (RSW-Laptop, remote worker) reported SMB to FRONT not working. **Root cause: FRONT's
+ZeroTier network adapter was administratively Disabled** — even though the ZeroTier *service*
+was ONLINE and `listnetworks` showed the Wolkin network OK with `10.147.19.199/24` assigned.
+A disabled adapter = no IP plumbed onto the interface = FRONT unreachable over ZeroTier = all
+remote SMB/print down (in-office machines unaffected, so easy to miss).
+
+Almost certainly disabled during the **2026-06-25** in-office scanner/static-IP work, where the
+ZeroTier IP `10.147.19.199` was the name-resolution confounder (laptop hosts override
+`10.147.19.199 FRONT` pinning "front" to the ZT IP) — disabled to take it out of play and not
+re-enabled. The disable itself was not logged verbatim 2026-06-25.
+
+## Diagnosis (via GuruRMM, FRONT = `877d311a-4b24-462c-97b1-d2a0f7730a71`)
+- RSW-Laptop offline in RMM (no check-in ~2.5h) at start; came back online mid-session.
+- FRONT SMB server healthy: `LanmanServer` running, 445 listening, shares present
+  (ClientFiles/Forms/Pleadings/Scans/Sharp). LAN IP `192.168.1.153` (static, set 2026-06-25).
+- FRONT had **no `10.147.19.199`**; `Get-NetAdapter` showed `ZeroTier One [17d709436c834c9b]` =
+  **Disabled**. ZT service ONLINE; `listnetworks` = `OK PRIVATE ... 10.147.19.199/24`.
+- FRONT could NOT ping `10.147.19.54` (Julie) over ZT (ICMP — reliable, not the error-67 artifact).
+
+## Fix
+- `Enable-NetAdapter -InterfaceDescription "ZeroTier Virtual Port" -Confirm:$false`
+  (adapter name `ZeroTier One [..]` has `[ ]` PS wildcards — target by `-InterfaceDescription`).
+- Verified: adapter **Up**, `10.147.19.199` restored, FRONT pings Julie's laptop (`10.147.19.54`)
+  = True. RSW-Laptop back online in RMM.
+- Did NOT use RMM `net use`/`net view` to judge SMB (documented false error-67 artifact against
+  FRONT) — plumbing confirmed via adapter state + ICMP. Julie to test her mapped drive; stale
+  red-X mappings clear with disconnect/reconnect or sign out/in.
+
+## Files changed
+- `wiki/clients/wolkin.md` — CRITICAL "ZeroTier required for Julie" callout (Infrastructure),
+  Patterns & Known Issues entry, History Highlights line, frontmatter `last_compiled: 2026-06-26`.
+
+## Follow-ups
+- (Optional) pull FRONT System event log to confirm when/who disabled the adapter, if recurrence
+  is a concern.
+- Still open from before: rotate `front\julie` (`clients/wolkin/front-julie.sops.yaml`); DHCP
+  reservation for FRONT on the Verizon Fios router.
--- a/errorlog.md
+++ b/errorlog.md
@@ -17,6 +17,8 @@ Categories (the `[type]` tag): _(none)_ = skill/command execution failure ·

 <!-- Append entries below this line -->

+2026-06-26 | GURU-5070 | bash/env | [friction] git-bash /mingw64/bin/curl quarantined by Windows Defender -> RMM helpers (rmm-ps.sh/rmm-auth.sh) fail 'Permission denied'; workaround use C:/Windows/System32/curl.exe [ctx: machine=GURU-5070 fix=defender-exclusion-on-git-mingw64-bin]
+
 2026-06-26 | GURU-5070 | agy/gemini | gemini CLI headless failed: throwIneligibleOrProjectIdError / _doSetupUser (auth-eligibility, needs interactive re-login) [ctx: task=verify-gws-migration-scopes]

 2026-06-26 | GURU-5070 | agy | gemini returned no response (empty after 3 attempts) [ctx: mode=search err=    at process.processTicksAndRejections (node:internal/process/task_queues:104:]
--- a/session-logs/2026-06/2026-06-26-mike-uos-rocky-update.md
+++ b/session-logs/2026-06/2026-06-26-mike-uos-rocky-update.md
@@ -0,0 +1,40 @@
+# 2026-06-26 — UOS Server: verify up-to-date + Rocky 9.1 -> 9.8 host patch
+
+## User
+- **User:** Mike Swanson (mike)
+- **Machine:** GURU-5070
+- **Role:** admin
+
+## Summary
+Verified the UOS Server (self-hosted UniFi OS Server, `172.16.3.29`) was up to date, then
+patched the host OS on request.
+
+- **UniFi layer (already current):** UniFi OS Server **5.1.19** / UniFi Network **10.4.57** —
+  the newest published builds (5.1.19 released 2026-06-18). The in-guest `uosserver-updater.service`
+  is working; it auto-stepped 5.1.15 -> 5.1.19 on 2026-06-21. App runs in the rootless podman
+  container `uosserver`; container reported Up (healthy).
+- **Host OS (was behind):** Rocky Linux **9.1** -> **9.8**. `dnf -y update` applied **362 packages**
+  (full security backlog), incl. new kernel `5.14.0-162.6.1.el9_1` -> `5.14.0-687.17.1.el9_8`.
+  Clean reboot (~24s back to SSH, ~4 min to container healthy). Controller web UI HTTP 200,
+  `uosserver status` healthy post-reboot. Old kernel retained as fallback boot entry.
+
+## Access used
+- SSH root via vaulted fleet key `infrastructure/uos-server-ssh-key`
+  (field `credentials.ssh-private-key-b64`, base64-decoded to a temp key, removed after).
+
+## Commands (key)
+- `dnf -q check-update | wc -l` (362), `dnf -q updateinfo list security`, `dnf check-update kernel`
+- `dnf -y update` ; `systemctl reboot`
+- Verify: `uosserver status` (container Up healthy), `uosserver version` (5.1.19),
+  `curl -sk -o /dev/null -w "%{http_code}" https://127.0.0.1:11443/` (200)
+
+## Files changed
+- `wiki/systems/uos-server.md` — guest line updated to Rocky 9.8 + kernel; new
+  "Host OS maintenance (Rocky)" section (procedure, safety-net autobackup path, reboot impact,
+  history line); frontmatter `last_compiled: 2026-06-26`.
+
+## Notes / follow-ups
+- Host OS is NOT auto-patched (only the UniFi container self-updates) — patch manually on a
+  cadence. Daily UniFi autobackups exist at
+  `~uosserver/.local/share/containers/storage/volumes/uosserver_var_lib_unifi/_data/backup/autobackup/`.
+- No VM snapshot taken (user opted to proceed on autobackup only); update was clean.
--- a/wiki/clients/wolkin.md
+++ b/wiki/clients/wolkin.md
@@ -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