azcomputerguru/claudetools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

sync: auto-sync from HOWARD-HOME at 2026-06-18 09:36:06

Browse Source 
Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-06-18 09:36:06
This commit is contained in:
Howard Enos
2026-06-18 09:36:14 -07:00
parent 7a10dff74c
commit 4cb32703b9
1 changed files with 73 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

73
clients/cascades-tucson/session-logs/2026-06/2026-06-18-howard-synology-drive-sync-diagnosis.md Normal file
View File

@@ -0,0 +1,73 @@
## User
- **User:** Howard Enos (howard)
- **Machine:** Howard-Home
- **Role:** tech
## Session Summary
Howard reported that the Synology Drive sync from the Cascades Synology NAS (cascadesDS, 192.168.0.120) to CS-SERVER was not syncing all files/folders — some folders showed empty on the server, specifically the "Server" folder and its "ALdoc" content. Investigated end-to-end across both the CS-SERVER Drive Client (via GuruRMM) and the Synology Drive Server (via direct SSH over the site VPN).
Established the architecture: a Synology Drive **Client** (v7.5.0.16085) runs on CS-SERVER under the Windows `sysadmin` user, authenticating to the NAS as the DSM account **`Sync`** (uid 1116, home `/var/services/homes/Sync`), one-way **download** (mode:1) of that `Sync` user's "My Drive" (`/volume1/homes/Sync/Drive/`) into `D:\Shares\Main`. The folders Howard saw empty (`Server`, `homes`, `home`, `Managment`, `Sales Dept`, `Downloads`) are **empty stub directories at the source** inside the Sync user's My Drive — leftovers from the prior FreeFileSync/GoodSync migration (`sync.ffs_db`, `_gsdata_` are in the same folder). CS-SERVER was faithfully mirroring empty folders. The "ALdoc" data actually lives at `/volume1/homes/Sync/Drive/Documents/ALDocs` (under Documents, which syncs fine) and is already present on CS-SERVER at `D:\Shares\Main\Documents\ALDocs` (17,694 files). The real `/volume1/Server` share (2,486 files, 1.9 G) is a separate shared folder that is NOT in the Drive sync scope at all.
Ruled out several false leads: not encrypted/locked shares (data lists fine as admin), not a selective-sync blacklist (blacklist only excludes `/Backup`, `/Moments`, dotfiles, `.lnk/.pst/.swp/.tmp`), and not a dead Drive Server. `synopkg status` falsely reported the package "stopped" (status 263 "failed to get unit status"), but the systemd unit `pkgctl-SynologyDrive` is **active** with `cloud-daemon` running and 6690 listening; the `code: -2`/`bio error` lines in the client log are long-poll fallbacks, not a failed server.
Howard clarified intent: this is a **file-server migration** (Synology -> CS-SERVER); he needs all department-share data staged and kept current as users are moved, then the Synology retired. He accepted handling user home data separately (users move it into redirected profiles that already back up to the server), which removes `homes` from the bulk sync. With `homes` out of scope, a Synology Drive **Team Folder** sync of the department shares becomes viable. Produced a full setup walkthrough (Admin Console Team Folder enable + low versioning; Drive Client Download-only tasks into a clean `D:\Shares\_SynMigration\<share>` staging area; validation; per-share cutover choreography). No changes were made — diagnosis + plan only.
## Key Decisions
- **Use Synology Drive Team Folders (not robocopy) for the department shares**, now that `homes` is handled per-user. Earlier robocopy recommendation was driven by the homes 228 GB limitation; with homes excluded, the native real-time Team Folder path is acceptable and matches "permanent real-time sync."
- **Exclude `homes` from the bulk sync** — Synology Drive cannot enable Sync on the `homes`/`home` system shares, and Howard will migrate user home data via redirected profiles instead.
- **Sync into NEW empty staging folders (`D:\Shares\_SynMigration\<share>`), never into a live share** — a one-way download task makes the local folder mirror the NAS and could delete/overwrite an existing share's files. Keeps current shares + NTFS/SMB permissions untouched.
- **Set Drive version history low/off** on the migration team folders to limit space + indexing load on the aging NAS.
- **Per-share cutover rule:** a share is mirrored from Synology OR live on CS-SERVER, never both; disable the download task at cutover so the now-authoritative server copy is not overwritten.
- **Pilot on the `Server` share first** (smallest real share, 1.9 G / 2,486 files, and the one that triggered the report) before templating the rest.
## Problems Encountered
- **`synopkg status SynologyDrive` falsely reported "stopped"** (status 263, "failed to get unit status") while the service was actually running. Resolved by checking the systemd unit directly: `systemctl is-active pkgctl-SynologyDrive` = active, with `cloud-daemon.exe`/`cloud-monitor` under the slice and 6690 listening.
- **Initial RMM grep matched the wrong log** — searching for "Server" hit `auto_updater.log` ("update server"/"Windows Server"). Re-ran against `daemon.log` specifically to get the real sync connection + event lines.
- **Local-vs-NAS folder-name mismatch** initially confused the mapping (local `Documents`/`Company Web Docs`/`FD`/`ITSvc` are not `/volume1` share names). Resolved by `find`-ing those folder names on the NAS, which located the real sync root at `/volume1/homes/Sync/Drive/`.
- **Background NAS `du` jobs failed (exit 255)** after the temp askpass dir was cleaned mid-run; harmless (read-only) and the needed sizes were already captured.
## Configuration Changes
None. Diagnosis and planning only — no changes made to CS-SERVER, the Synology, or the repo (other than this session log).
## Credentials & Secrets
- No new credentials discovered or created. Synology admin creds already vaulted at `clients/cascades-tucson/synology-cascadesds.sops.yaml` (username `admin`); used read-only for SSH diagnostics via the unifi-wifi-style SSH_ASKPASS pattern (system OpenSSH).
- The Drive Client authenticates to the NAS as DSM account **`Sync`** (uid 1116). Its password is stored inside the Drive Client config on CS-SERVER, not in the vault; not needed for this work.
## Infrastructure & Servers
- **CS-SERVER** (192.168.2.254) — GuruRMM agent `c39f1de7-d5b6-45ae-b132-e06977ab1713` (online). Synology Drive Client v7.5.0.16085 installed, runs as Windows `sysadmin`. Client config/logs: `C:\Users\sysadmin\AppData\Local\SynologyDrive\` (logs in `\log`, sync session in `\data\session\2`, filters in `\data\session\2\conf\*.filter`).
- **cascadesDS Synology NAS** — 192.168.0.120. DSM 7.2.1-69057. Synology Drive Server **3.5.0-26088**, systemd unit `pkgctl-SynologyDrive` (active), protocol port **6690** (SSL). Reachable directly over the site VPN (ports 22/5000/5001/6690 open).
- **Sync architecture:** Drive Client connection conn_id 2, `username:sync`, `mode:1` (one-way download), `is_index_home:0`, `user_is_admin:1`; source `/volume1/homes/Sync/Drive/` -> dest `D:\Shares\Main`.
- **NAS shared folders (real data):** `/volume1/Server` (2,486 files, 1.9 G), `/volume1/Management` (13,712 files, 5.5 G), `/volume1/homes` (141,545 files, ~228 G), `/volume1/Public` (~50 G), `/volume1/SalesDept` (~12-23 G), `/volume1/chat`, `/volume1/Activities`, plus legacy `/volume1/Sandra Fish`, `/volume1/pacs`, `/volume1/web`.
- **Sync user My Drive (`/volume1/homes/Sync/Drive/`) per-folder file counts (source truth):** Documents=519 top (18,193 recursive, incl. `ALDocs`), Public=49, SalesDept=102, chat=1, Company Web Docs=79, FD=154, ITSvc=1; EMPTY stubs: Server=0, homes=0, home=0, Managment=0, "Sales Dept"=0, Downloads=0.
- **ALDocs:** source `/volume1/homes/Sync/Drive/Documents/ALDocs`; present on CS-SERVER at `D:\Shares\Main\Documents\ALDocs` (17,694 files). NOT under any "Server" folder.
## Commands & Outputs
- Locate CS-SERVER agent: `bash .claude/scripts/rmm-search.sh cs-server cascades` -> `c39f1de7-...` online.
- RMM recon of `D:\Shares\Main` showed empty `Server`/`homes`/`Managment`/`Sales Dept`/`Downloads`/`home` vs populated `Documents`(18 GB)/`SalesDept`(23 GB)/`Public`(2.7 GB)/etc.
- Drive Client connection line (daemon.log): `...server_ip:192.168.0.120, server_port:6690, ... username:sync, ... mode:1, ... is_index_home: 0, user_is_admin: 1 ...` and `... 'D:\Shares\Main/Server/New folder' ... is one-way downloading, ignore event.`
- SSH askpass pattern (system OpenSSH, no sshpass): `SSH_ASKPASS=<helper> SSH_ASKPASS_REQUIRE=force DISPLAY=:0 ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no admin@192.168.0.120 'sh -s' <<heredoc`.
- NAS source truth: `find /volume1/homes/Sync/Drive/Server -type f | wc -l` = 0; `find .../Documents/ALDocs -type f | wc -l` = 26 (top) with many subfolders.
- Drive Server real state: `systemctl is-active pkgctl-SynologyDrive` = `active` (synopkg reported stop falsely); `netstat -tlnp | grep 6690` = LISTEN.
## Pending / Incomplete Tasks
1. **Confirm in-scope share list** — default `Server, Management, Public, SalesDept, chat, Activities`; decide on legacy `Sandra Fish`/`pacs`/`web`. Note `Culinary, IT, Receptionist, directoryshare` already exist as CS-SERVER shares (exclude unless re-pull wanted).
2. **Confirm where ALDocs lives among the REAL shares** (not just the Sync user's My-Drive copy) so a Team Folder definitely captures it before the old My-Drive task is retired. Some curated folders (Company Web Docs, ITSvc, Quickbooks) were found to also exist under `/volume1/Public`.
3. **Execute the Team Folder migration** (pending go-ahead): Admin Console enable Team Folders + low versioning; Drive Client Download-only tasks into `D:\Shares\_SynMigration\<share>`; pilot on `Server`, validate, template the rest.
4. **Per-share cutover** later: create production SMB share + AD-group NTFS/SMB perms (per `phase2-server-prep.md`), repoint GPO drive maps, disable that share's download task.
5. Optional: save the walkthrough as a migration runbook under `clients/cascades-tucson/docs/migration/`.
## Reference Information
- Migration plan docs: `clients/cascades-tucson/docs/migration/phase4-synology.md` (§6 Synology transition), `phase2-server-prep.md` (§4c sync, §4d share perms).
- Synology DSM: `http://192.168.0.120:5000` (Synology Drive Admin Console for Team Folders + Version Control).
- Vault: `clients/cascades-tucson/synology-cascadesds.sops.yaml`.
- CS-SERVER Drive Client paths: `C:\Users\sysadmin\AppData\Local\SynologyDrive\{log,data\session\2}`.
- Proposed staging root: `D:\Shares\_SynMigration\<share>` (new, separate from live shares and from the existing `D:\Shares\Main` Drive staging).