claudetools/clients/cascades-tucson/session-logs/2026-06/2026-06-18-howard-synology-drive-sync-diagnosis.md

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).