# Scileppi Law — Sylvia "can't connect to server": NAS reboot recovery, durable AFP mount + no-sleep fix, ScreenConnect deploy, ticket #32493

## User
- **User:** Howard Enos (howard)
- **Machine:** Howard-Home
- **Role:** tech

## Session Summary

Sylvia at The Law Offices of Chris Scileppi reported she "can't connect to the server" — a mapped drive that was no longer mapped. The wiki had the Mac context but the entire server/network layer was undocumented, so the infra was discovered live via GuruRMM. The client's Mac is `Mac-mini-2.localdomain` (macOS, user `sylvia`); "mapped drive" = an SMB/AFP mount of the `Data` share at `/Volumes/Data`. Auto-mount is driven by a GUI LaunchAgent `com.acg.mount-server`.

The internal RMM API (`172.16.3.30:3001`) and coord API (`:8001`) were both unreachable from Howard-Home (off ACG LAN). Authenticated instead against the **public** RMM endpoint `https://rmm.azcomputerguru.com` (same vault creds) and drove everything from there. Both Scileppi agents were online: `Mac-mini-2` and `SL-SERVER`. Root cause: **`SL-SERVER` (a Synology NAS, `192.168.242.5`) had rebooted ~09:34 local and was slow to bring SMB/AFP back up.** Diagnostics initially showed SMB not listening and no afpd/avahi processes; a few minutes later 139/445/548 were all listening again — the NAS simply took time to start file services after boot. The 25 TB btrfs `/volume1` pool (incl. `/volume1/Data`) was mounted and healthy throughout — no data risk.

Two deeper problems surfaced. (1) The mount LaunchAgent targeted the **Bonjour AFP service name** `afp://SL-SERVER._afpovertcp._tcp.local/Data`, which the Synology **stops advertising after a reboot** (`NORESOLVE`), while `SL-SERVER.local` → `192.168.242.5` resolves fine and AFP:548 was open. A manual `.local` mount as `sylvia` succeeded immediately. (2) The Mac mini is on **Wi-Fi (en1)** with `displaysleep 10` — when the display slept the Wi-Fi link dropped, which caused the RMM agent to bounce offline repeatedly (compounded by the user cycling Sylvia's login). This "screensaver kills the internet" behavior was the meta-cause of all the churn.

Applied fixes over RMM: `pmset -a sleep 0 displaysleep 0 womp 1 powernap 1 tcpkeepalive 1` (system sleep was already 0; the only effective change was `displaysleep 10 -> 0`, which stopped the network drops); rewrote `com.acg.mount-server.plist` to use `afp://SL-SERVER.local/Data` (backed up original, reloaded), and retired the stale duplicate agent `com.azcomputerguru.mount-slserver`. Installed the ScreenConnect macOS access agent (built a parameterized pkg installer via the `screenconnect` skill, pushed + installed via `installer -pkg -target /`); session `Mac-mini-2` registered self-tagged Company="The Law Offices of Chris Scileppi" / Site="Main Office" / Tag="Mac". Declined to install ScreenConnect on `SL-SERVER` (headless Synology; unsupported/no value).

Finally, via the `/syncro` skill, documented the work on ticket **#32493** (id 113284439): a customer-visible resolution comment (issues + fixes, `do_not_email: true`) and a **0.5h Labor - Remote Business** line ($150/hr = $75.00), left un-invoiced per Howard's choice (customer has no prepaid block). Updated the Scileppi wiki with the previously-missing Network/Servers/GuruRMM sections and a dated event.

## Key Decisions

- **Drove RMM via the public endpoint** `https://rmm.azcomputerguru.com` because the internal `172.16.3.30:3001` is LAN-only and unreachable from Howard-Home. Same vault creds work.
- **Client-side `.local` fix over a server-side Bonjour fix.** The durable, minimal fix was repointing the Mac's mount to the resolvable `SL-SERVER.local` rather than chasing why the Synology stopped advertising `_afpovertcp._tcp` after reboot. `.local` is robust regardless of AFP Bonjour advertisement.
- **Kept AFP (didn't switch to SMB).** AFP:548 works and the Keychain creds are AFP; switching to `smb://` would change mount type, permissions, and the stored credential. Noted SMB/AFP-deprecation as a future consideration only.
- **`displaysleep 0` (display never sleeps) as the connectivity fix.** System `sleep` was already 0; the display-sleep-triggered Wi-Fi drop was the actual fault. Recommended Ethernet as the bulletproof long-term fix.
- **Grabbed the Mac on first reconnect to slam `pmset` first**, before doing anything else, because the machine kept dropping when idle — pmset is instant, so once applied the machine stayed up for the rest of the work.
- **Did not install ScreenConnect on `SL-SERVER`** — headless Synology DSM is not a supported/useful SC target; it stays managed via GuruRMM + DSM web UI.
- **Added time but did not invoice** ticket #32493 — per Howard's explicit choice at the preview (no prepaid block, so an invoice would bill $75).

## Problems Encountered

- **Both internal APIs (RMM 3001, coord 8001) timed out** from Howard-Home (off-LAN). Resolved by using the public RMM endpoint.
- **Repeated agent drops (`undeliverable`/`interrupted`/`pending`)** on `Mac-mini-2` mid-command. Root-caused to display-sleep dropping Wi-Fi plus the user cycling Sylvia's login. Resolved by applying `displaysleep 0` on first stable reconnect.
- **False-positive mount check (self-inflicted).** `mount | grep -qi "/Volumes/Data"` matched `/System/Volumes/Data` (the macOS system volume) as a substring and reported "MOUNTED-OK" when the AFP share was absent. Corrected to the precise `grep -q "on /Volumes/Data "` (trailing space) that the LaunchAgent itself uses. Logged to `errorlog.md` (`--friction`).
- **Bonjour AFP name `NORESOLVE`.** The plist's `_afpovertcp._tcp.local` name didn't resolve post-reboot; `SL-SERVER.local` did. Fixed the plist.
- **SC install command returned overall exit 1** — cosmetic only: the final `ls /Applications/ScreenConnect*` glob didn't match the actual app dir name `connectwisecontrol-*.app`. Install itself succeeded (`installer` rc=0, daemon + processes present, cloud session registered).

## Configuration Changes

- **On `Mac-mini-2` (via RMM, not in repo):**
  - `pmset -a sleep 0 displaysleep 0 womp 1 powernap 1 tcpkeepalive 1` (effective change: `displaysleep 10 -> 0`).
  - `/Users/sylvia/Library/LaunchAgents/com.acg.mount-server.plist` — mount URL changed `afp://SL-SERVER._afpovertcp._tcp.local/Data` -> `afp://SL-SERVER.local/Data`; reloaded (`bootout`+`bootstrap` gui/501). Backup: `com.acg.mount-server.plist.bak-20260701`.
  - Retired stale duplicate agent: `com.azcomputerguru.mount-slserver.plist` -> `.disabled-20260701` (bootout + rename).
  - Installed ScreenConnect macOS agent: `/Applications/connectwisecontrol-1912bf3444b41a08.app` + LaunchDaemon `connectwisecontrol-1912bf3444b41a08.plist`.
- **Repo:**
  - `wiki/clients/scileppi-law.md` — added Network + Servers detail, updated GuruRMM section (enrolled agents, public endpoint note, ScreenConnect), added 2026-07-01 Key Events entry, `last_compiled` -> 2026-07-01.
  - `errorlog.md` — one `--friction` entry (grep `/System/Volumes/Data` false-match).
- **Syncro ticket #32493:** resolution comment (id 421638088) + line item (id 43099595).

## Credentials & Secrets

None created, rotated, or newly discovered. RMM auth used existing vault entry `infrastructure/gururmm-server.sops.yaml`; ScreenConnect used `msp-tools/screenconnect.sops.yaml`; Syncro used the baked-in per-user key (howard). Temp files holding the RMM JWT were removed at end of session.

## Infrastructure & Servers

- **Scileppi subnet:** `192.168.242.0/24`; gateway/DNS `192.168.242.1`.
- **`SL-SERVER`** — Synology NAS, `192.168.242.5` (bond0). btrfs `/volume1` (25 TB pool, `/dev/mapper/cachedev_0`), share `Data` at `/volume1/Data`. Serves AFP (548) + SMB (445/139). Resolves reliably as `SL-SERVER.local`; the `_afpovertcp._tcp.local` Bonjour name is unreliable after NAS reboots. netatalk cedarview build; no systemd (Synology init). GuruRMM agent `0186e9d5-e1cc-4603-a81a-adb1f2230702` (os_type reported linux).
- **`Mac-mini-2.localdomain`** — Sylvia's Mac, macOS, user `sylvia` (uid 501). On Wi-Fi `en1` = `192.168.242.154`. GuruRMM agent `1386d9fd-ac16-423c-ada0-5abad5b61838`. Mount agent `com.acg.mount-server` (RunAtLoad + StartInterval 300). Has an unused wired Ethernet port (recommended for durable connectivity).
- **GuruRMM:** internal API `http://172.16.3.30:3001` (LAN-only); **public** API `https://rmm.azcomputerguru.com` (works off-LAN, same vault creds). Auth helper `.claude/scripts/rmm-auth.sh` hardcodes the internal URL — for off-LAN use, auth manually against the public host.
- **ScreenConnect:** `https://computerguru.screenconnect.com`; new session `Mac-mini-2`, CP1="The Law Offices of Chris Scileppi", CP2="Main Office", CP3="Mac".

## Commands & Outputs

- Off-LAN RMM auth: `POST https://rmm.azcomputerguru.com/api/auth/login` with vault email/password -> JWT; then `GET /api/agents`.
- Mount diagnosis on Mac: `dscacheutil -q host -a name SL-SERVER._afpovertcp._tcp.local` -> NORESOLVE; `SL-SERVER.local` -> `192.168.242.5`; `nc -z -G 3 192.168.242.5 548` -> open.
- Working manual mount: `launchctl asuser 501 sudo -n -u sylvia /usr/bin/osascript -e 'mount volume "afp://SL-SERVER.local/Data"'` -> `//Sylvia@SL-SERVER.local/Data on /Volumes/Data (afpfs)`.
- Precise mount check (use this, not a bare grep): `mount | grep -q "on /Volumes/Data "`.
- pmset BEFORE: `sleep 0 / displaysleep 10 / womp 1 / powernap 1 / tcpkeepalive 1`; AFTER: `displaysleep 0`.
- SC installer build: `sc.py build-installer --platform pkg --name Mac-mini-2 --company "The Law Offices of Chris Scileppi" --site "Main Office" --tag Mac`; install: `curl -fsSL -o /tmp/sc.pkg "<url>"; installer -pkg /tmp/sc.pkg -target /` -> "upgrade was successful", client processes running.
- Syncro: ticket #32493 id 113284439; comment 421638088; line item 43099595 (Labor - Remote Business, 0.5, $150, taxable false).

## Pending / Incomplete Tasks

- **Verify auto-mount from a clean state.** The share was already mounted when the new `.local` plist loaded, so the kickstart didn't exercise a from-scratch remount via the new config. The `.local` mount path is proven working manually; a full clean-boot verification is still outstanding (avoided force-unmounting Sylvia's active drive).
- **Move `Mac-mini-2` to wired Ethernet** — the durable fix for the Wi-Fi idle drops (pmset `displaysleep 0` is the interim mitigation). Requires onsite.
- **Ticket #32493 not invoiced** — 0.5h remote ($75) sits on the ticket for the normal billing run. Customer has no prepaid block.
- **Optional:** if desired, re-post the resolution comment with `do_not_email: false` to email the client (currently suppressed).
- **`rmm-auth.sh` enhancement idea:** fall back to the public RMM host when the internal IP is unreachable (would have saved the manual auth this session).

## Reference Information

- **Syncro ticket:** #32493 (id 113284439) — https://computerguru.syncromsp.com/tickets/113284439 ; customer The Law Offices of Chris Scileppi (customer_id 9601863, Syncro).
- **GuruRMM agents:** Mac `1386d9fd-ac16-423c-ada0-5abad5b61838`; SL-SERVER `0186e9d5-e1cc-4603-a81a-adb1f2230702`.
- **ScreenConnect:** app `connectwisecontrol-1912bf3444b41a08`; extension `2d558935-686a-4bd0-9991-07539f5fe749`.
- **Skills used:** `/rmm`, `screenconnect`, `/syncro`.
- **Wiki:** `wiki/clients/scileppi-law.md` (updated this session).
- **Bot alerts posted:** #dev-alerts (RMM remediation summary), #bot-alerts (Syncro #32493).
