From bd52dde6a72088361bfa8c06ded1b7778ba6af79 Mon Sep 17 00:00:00 2001 From: Mike Swanson Date: Fri, 26 Jun 2026 08:03:21 -0700 Subject: [PATCH] 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 --- ...-06-26-mike-wolkin-smb-zerotier-adapter.md | 45 +++++++++++++++++++ errorlog.md | 2 + .../2026-06-26-mike-uos-rocky-update.md | 40 +++++++++++++++++ wiki/clients/wolkin.md | 30 ++++++++++++- 4 files changed, 116 insertions(+), 1 deletion(-) create mode 100644 clients/wolkin/session-logs/2026-06/2026-06-26-mike-wolkin-smb-zerotier-adapter.md create mode 100644 session-logs/2026-06/2026-06-26-mike-uos-rocky-update.md diff --git 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 new file mode 100644 index 00000000..6ce4e65d --- /dev/null +++ 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. diff --git a/errorlog.md b/errorlog.md index 78c01d00..560e31de 100644 --- a/errorlog.md +++ b/errorlog.md @@ -17,6 +17,8 @@ Categories (the `[type]` tag): _(none)_ = skill/command execution failure · +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:] diff --git 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 new file mode 100644 index 00000000..3d6aaa7f --- /dev/null +++ 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. diff --git a/wiki/clients/wolkin.md b/wiki/clients/wolkin.md index dc82b791..d2ee9d13 100644 --- 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