| name | synology-operations |
| description | Use when the user wants to connect to their Synology NAS for file operations, share management, storage health checks, or general maintenance. Reads connection details from `$CLAUDE_USER_DATA/synology-mgmt/config.json` (populated by the `onboard` skill in this plugin). Triggers on phrases like "synology operations", "connect to the nas", "check the nas", "nas storage", "list shares". |
synology-operations
Operate against a Synology NAS over SSH (and optionally DSM HTTP API). All host- and credential-specific values come from the plugin's config — never hard-code them.
Pre-flight
Resolve the plugin data directory (${CLAUDE_USER_DATA:-${XDG_DATA_HOME:-$HOME/.local/share}/claude-plugins}/synology-mgmt/) and load config.json. If it doesn't exist or is incomplete, tell the user to run the onboard skill first and stop.
Available fields after load: host, ssh_user, ssh_port, ssh_key_path, dsm_web_url, volume_root, model, dsm_version, dsm_user_ref.
SSH access
SSH_OPTS=( -p "$SSH_PORT" )
[ -n "$SSH_KEY_PATH" ] && SSH_OPTS+=( -i "$SSH_KEY_PATH" )
ssh "${SSH_OPTS[@]}" "$SSH_USER@$HOST" "<command>"
Synology limits the default user shell. Prefix privileged commands with sudo (DSM will prompt or accept the user's password depending on config).
Typical tasks
File operations on shares
- List shares:
ls -la "$VOLUME_ROOT" (each top-level dir is a share)
- Check a specific share:
ls -la "$VOLUME_ROOT/<share>"
- Free space per volume:
df -h | grep -E "^/dev|volume"
Storage health
sudo synostorage --info
sudo smartctl -a /dev/sata1
sudo smartctl -a /dev/sata2
sudo btrfs scrub status "$VOLUME_ROOT"
Share / permissions
- List shared folders via DSM:
sudo synoshare --enum ALL
- Inspect ACL on a folder:
sudo synoacltool -get "$VOLUME_ROOT/<share>"
Snapshots (Btrfs / Snapshot Replication)
- List snapshots for a share:
sudo synosnap --list "$VOLUME_ROOT/<share>"
- Read-only inspection only — never delete snapshots without explicit confirmation.
System
- DSM version and model:
cat /etc.defaults/VERSION
- Uptime / load:
uptime
- Running services:
synoservicectl --list 2>/dev/null | head -50
- System log tail:
sudo tail -100 /var/log/messages
DSM HTTP API (optional)
If the user has populated dsm_user_ref, you can authenticate to the DSM API at $DSM_WEB_URL/webapi/. Login flow:
curl "$DSM_WEB_URL/webapi/auth.cgi?api=SYNO.API.Auth&version=3&method=login&account=$USER&passwd=$PASS&session=FileStation&format=cookie"
Resolve the password from dsm_user_ref at runtime (1Password, env var, file). Don't log it.
Useful endpoints:
| API | Purpose |
|---|
SYNO.Core.System | System info |
SYNO.Storage.CGI.Storage | Volume / RAID overview |
SYNO.FileStation.List | List share contents |
SYNO.Core.Share | Share management |
Guidelines
- Confirm before any destructive operation on shared storage — delete, overwrite, snapshot removal, ACL change.
- Prefer read-only inspection first. Mutate only with explicit user confirmation.
- Don't run package installs / updates without confirmation — DSM updates can require reboot.
- Mind the volume path. The default in onboard is
/volume1; multi-volume NASes have /volume2, /volume3, etc. Re-check volume_root and ask the user if a path doesn't exist.
- SSH session weight matters on small models. Don't open many parallel SSH sessions on entry-level units (DS220+, DS923+, etc.) — chain commands in a single session instead.
