synology-nas-cli

Audit a Synology NAS against the C3RB3R / .L0CK3D ransomware campaign with one command, fix what it finds with a second, and keep running DSM from the terminal afterwards.

English · 繁體中文 · 简体中文 · 日本語 · 한국어 · Deutsch · Español · Français

Canonical repository, releases and issues: https://gitlab.com/aa22396584/synology-nas-cli

nas is a zero-dependency Python CLI (standard library only, Python 3.8+, so it also runs on DSM itself) and stdio MCP server for the Synology DSM 7 Web API: status, health, logs, packages, volumes, Tailscale, DSM upgrades, scheduled health alerts pushed to a webhook, and an incident audit and remediation tool built during the October 2026 C3RB3R / .L0CK3D campaign against internet-exposed Synology NAS boxes (Synology-SA-24:20, SA-26:13, SA-26:14).

Not affiliated with Synology Inc. "Synology", "DSM" and "QuickConnect" are trademarks of Synology Inc.

• Hand it to your agent
• What it checks and fixes
• Install
• Pick your setup
• Configuration
• Credentials
• Backends
• Incident quick start
• nas incident fix
• MCP server and agent skills
• Alerts and webhooks
• Command reference summary
• What changes the NAS
• Tests

Hand it to your agent

Paste either prompt into Claude Code, Codex, Cursor, Gemini CLI, OpenCode, Grok Bot, or any tool-using AI agent (Grok Bot setup, skills and alert routine: docs/GROK-BOT.md):

English prompt:

Use https://github.com/akari-sora/synology-nas-cli to audit and fix my Synology NAS at https://192.0.2.10:5001. Follow docs/AGENT-RUNBOOK.md.

繁體中文提示詞：

使用 https://github.com/akari-sora/synology-nas-cli 檢查並修復我的 Synology NAS（位址：https://192.0.2.10:5001），照著 docs/AGENT-RUNBOOK.md 的步驟執行。

What the agent does, step by step

1. Install: Clones the repository (or installs the package) and verifies ./bin/nas --version.
2. nas setup: Runs nas setup --json --no-input ... to write ~/.config/synology-nas-cli/config.json (mode 0600), signs in once to verify credentials, and pins DSM's TLS certificate SHA-256 fingerprint on first use.
3. nas doctor: Runs nas doctor --json to verify configuration, credentials, origin reachability, TLS pin, login, DSM version against SA-26:13, 2-step verification status, administrator capabilities, and clock skew.
4. nas incident: Runs nas incident --json (and optionally --probe --scan) for a read-only audit of DSM version, vulnerable packages, firewall, QuickConnect, UPnP router rules, public ports, external and failed sign-ins, AutoBlock, SMB1, built-in admin, snapshot schedules, the unsupported-model WORM lock trap, ransom notes, and CVE-2024-10441 exploit attempts.
5. Plan: Runs nas incident fix --dry-run --json --ransom-scan and shows every planned change (before -> after), the exact DSM Web API calls, and the corresponding DSM web UI path.
6. nas incident fix --yes: Applies the approved plan in order (snapshot_worm → snapshots → packages → smb_min_protocol → quickconnect → router_port_forwarding → autoblock → admin_account → firewall, plus optional --rotate-password and --upgrade), reads every setting back to verify, and re-runs the audit.
7. Optional --deep and alert-deploy: Runs nas incident --deep --json (one read-only root collector via Task Scheduler checking root-only logs, crontabs, /bin binaries, accounts, SSH keys, and /proc) and nas alert-deploy --json --test (10-minute health and security monitoring pushed to a webhook).

What you provide along the way

1. NAS address and account (once):
   • DSM URL (for example https://192.0.2.10:5001, plus a VPN/Tailscale URL if used).
   • An administrator username and where its password comes from (op://VAULT/ITEM/password, a password command, or the OS keychain).
   • Your LAN/VPN subnet CIDR(s) to keep allowed in the firewall (for example 192.0.2.0/24).
   • An optional shared folder path for temporary staging (for example /docker/.nas-cli-deploy, used by --deep and alert-deploy).
2. A 6-digit 2FA code (once, if 2-step verification is on):
   • When nas setup exits 3 with "field": "otp", provide the current 6-digit code; --trust-device stores DSM's trusted-device token (0600) so subsequent commands do not need a code.
3. Plan confirmation:
   • Review the dry-run plan before nas incident fix --yes runs (and choose whether to include --rotate-password or --upgrade).

Full agent specification: docs/AGENT-RUNBOOK.md.

flowchart LR
    A["nas incident<br/>read-only audit"] --> B["nas incident fix --dry-run<br/>plan: before → after"]
    B --> C["nas incident fix --yes<br/>apply, read back, audit again"]
    C --> D["nas alert-deploy<br/>check every 10 min → webhook"]
    A -.->|files being encrypted| E["nas incident contain<br/>freeze the encryptor"]
    E --> F["nas incident rescue<br/>memory capture → key search"]

What it checks and fixes

nas incident is read-only. Each item prints PASS, WARN, FAIL or SKIP with a one-line hint (--json outputs structured JSON; schema in schemas/incident.schema.json). Exit status is 1 when any item is FAIL.

SKIP always states the reason: the item needs a flag (--probe, --scan), the API returned an error, or the NAS does not use that feature (no Btrfs/Snapshot Replication, no router configured in DSM).

Install

From a Git checkout (zero install)

git clone https://gitlab.com/aa22396584/synology-nas-cli.git synology-nas-cli
cd synology-nas-cli
./bin/nas --help                     # runs directly from the checkout (Python 3.8+ stdlib only)
ln -s "$PWD/bin/nas" ~/bin/nas       # optional: put `nas` on PATH

With pip from a GitLab release or local checkout

pip install https://gitlab.com/aa22396584/synology-nas-cli/-/archive/v1.0.0/synology-nas-cli-v1.0.0.tar.gz
# or from a local checkout:
pip install -e .                     # or: pipx install .
nas --help

On Windows (with py)

git clone https://gitlab.com/aa22396584/synology-nas-cli.git synology-nas-cli
cd synology-nas-cli
py -3 bin\nas --help
# or install the console script:
py -3 -m pip install -e .
nas --help

Initialize and verify login

Interactive or agent-driven one-step setup:

nas setup --origin https://192.0.2.10:5001 --user ops --password-source op:op://VAULT/ITEM/password --allowed-network 192.0.2.0/24
nas doctor

Or create the config file from the template and edit it by hand:

nas config init                      # writes ~/.config/synology-nas-cli/config.json (mode 600)
$EDITOR ~/.config/synology-nas-cli/config.json
nas config show                      # effective config, commands masked
nas whoami                           # one login: account, admin flag, DSM version, credential source

Pick your setup

Configuration

One JSON file: $NAS_CONFIG, else ~/.config/synology-nas-cli/config.json. Every key is optional. Unknown keys are an error, so typos do not silently fall back to defaults. Keys beginning with _ are comments. Environment variables override the file; command-line flags override both. nas config show prints the result with commands masked.

Example (config.example.json, what nas config init writes; the addresses are documentation examples):

{
  "name": "my-nas",
  "origins": ["https://192.0.2.10:5001", "https://my-nas.example-tailnet.ts.net:5001"],
  "lan_ip": "192.0.2.10",
  "snapshot_shares": ["photos", "documents"],
  "credentials": {
    "op_username": "op://VAULT/ITEM/username",
    "op_password": "op://VAULT/ITEM/password"
  },
  "webhook": {"file": "~/.config/synology-nas-cli/webhook.json"},
  "deploy": {"stage_dir": "/SHARE/.nas-cli-deploy"}
}

Environment variables: NAS_CONFIG, NAS_BACKEND, NAS_YES, NAS_NO_INPUT, NAS_ORIGINS (comma-separated; older name NAS_LAN_ORIGIN), NAS_CHROME_ORIGINS (older NAS_ORIGIN), NAS_OP_ITEM (op://VAULT/ITEM), NAS_OP_TOKEN_FILE, NAS_USER, NAS_PASSWORD_COMMAND, NAS_PASSWORD, NAS_OTP_COMMAND, NAS_CREDENTIAL_SOURCE, NAS_SESSION_FILE, NAS_SID + NAS_SYNOTOKEN, OP_SERVICE_ACCOUNT_TOKEN.

Credentials

The password comes from the first configured source in this chain (credentials.source or NAS_CREDENTIAL_SOURCE can force one: op, command, keychain, env, prompt):

1. 1Password (op): credentials.op_password = op://VAULT/ITEM/FIELD (and op_username, or a literal username). op authenticates with OP_SERVICE_ACCOUNT_TOKEN; if that is unset and credentials.op_token_file (default ~/.config/op/service-account-token) exists, its content is used as the token; otherwise op uses its own sign-in (1Password app integration or op signin). op is only run when an op:// reference is configured. op read fails on item names with non-ASCII characters: use the item ID.
2. Command (command): NAS_PASSWORD_COMMAND, else credentials.password_command, run with /bin/sh -c (cmd.exe on Windows); the first line of output is the password. Examples:
   • macOS Keychain: security find-generic-password -s synology-nas -a USER -w
   • Linux Secret Service: secret-tool lookup service synology-nas account USER
   • pass: pass show nas/USER
   • Bitwarden CLI: bw get password synology-nas (needs BW_SESSION from bw unlock)
   • Windows: powershell -NoProfile -Command "(Get-StoredCredential -Target synology-nas).GetNetworkCredential().Password" with the CredentialManager module (Install-Module CredentialManager). cmdkey /generic:synology-nas /user:USER /pass stores a credential but has no way to print the password again.
3. OS keychain (keychain): the entry nas login --save wrote. macOS Keychain through security (the password goes through security -i on stdin, not the command line) or the Linux Secret Service through secret-tool (password on stdin). credentials.store = auto (default), keychain, secret-tool, or "" (off); service name credentials.store_service. nas logout --forget deletes it.
4. Environment (env): NAS_USER + NAS_PASSWORD. The value sits in the process environment (readable by processes of the same user, and by ps e on some systems).
5. Prompt (prompt): getpass, only when stdin is a terminal and nothing above is configured.

The username comes from NAS_USER / credentials.username, else op_username, else the keychain entry's account, else a prompt.

2-step verification. When DSM answers 403 the login is retried once with a code from credentials.otp_command / NAS_OTP_COMMAND (e.g. oathtool --totp -b SECRET), else op item get --otp when the password came from 1Password (add the DSM 2FA secret to the item as a one-time password), else a prompt. nas login --trust-device (or session.trust_device: true) asks DSM for a trusted-device token and stores it (mode 600); later logins send it and skip the code until DSM forgets the device.

Sessions. By default every command signs in and out (each sign-in adds a "signed in successfully" line to DSM's connection log). nas login signs in once and caches the SID and SynoToken in session.cache_file (mode 600); later commands reuse it, and when DSM rejects it (106 timeout, 107 duplicate login, 119 invalid SID) they sign in again and rewrite the cache. nas logout ends and deletes it. NAS_SID + NAS_SYNOTOKEN reuse a session you already have (for example copied from a browser): nothing signs in or out, and a rejected session is an error.

TLS

The password backend never uses HTTP(S)_PROXY, ALL_PROXY or the system proxy settings for DSM. With tls.verify: false (default) the SHA-256 of the certificate an origin presents on the first connection is stored in tls.known_certs_file (mode 600; nas: trusting the certificate of ... on first use on stderr) and every later connection must present the same certificate, otherwise the command stops with the TLS certificate of ORIGIN changed. After replacing the DSM certificate: nas trust --reset https://HOST:PORT. nas trust lists the stored fingerprints. With tls.verify: true the system CAs decide and nothing is pinned. A notice is printed when the 1Password token file is readable by other users.

AutoBlock. DSM blocks an address after 10 failed sign-ins within 5 minutes by default, often permanently. nas never retries a failed password. A wrong password in your source costs one attempt per command, so fix the source before running again. Code 407 means the address is already blocked: remove it from Control Panel > Security > Protection > Allow/Block List from another address. See docs/TROUBLESHOOTING.md for recovery paths.

Backends

Incident quick start

nas incident                       # read-only audit
nas incident --probe               # also test the public address from this machine
nas incident --scan                # also search every share for ransom notes (minutes)
nas incident --deep                # also indicators of compromise via one read-only root script (needs deploy.stage_dir)
nas --json incident                # machine-readable

nas incident fix --dry-run         # the plan: every change (current -> new), the API calls, the DSM UI path
nas incident fix                   # same plan, asks before applying
nas incident fix --yes             # apply without asking
nas incident fix --only firewall,smb_min_protocol
nas incident fix --skip admin_account
nas incident fix --ransom-scan --yes          # a clean scan also allows the snapshot fixes
nas incident fix --upgrade --rotate-password --yes   # opt-in extras

nas incident contain                       # list processes that look like an encryptor (signals nothing without --yes / NAS_YES=1)
nas incident contain --yes                 # SIGSTOP them (all threads) so their memory and keys stay intact
nas incident contain --yes --stop-sync     # also stop Cloud Sync, Synology Drive, Hyper Backup, Container Manager
nas incident contain --yes --save-exe /volumeUSB1/usbshare/evidence   # copy each executable (sha256 recorded)
nas incident contain --release             # SIGCONT the frozen PIDs and start the packages --stop-sync stopped

nas incident rescue --yes --capture-dir /usbshare1/rescue                  # freeze, capture memory, recover key candidates
nas incident rescue --yes --capture-dir /usbshare1/rescue --sample /share/a.pdf.L0CK3D   # test each candidate on a copy
nas incident rescue --yes --capture-dir /usbshare1/rescue --decrypt-from /share/docs --decrypt-to /Volumes/USB/out

While files are being encrypted, nas incident contain --yes is the first command: it freezes the encryptor (SIGSTOP, never killed) so the session keys stay in its memory, then prints the next steps.

• Candidates: known names (libgld, qnetd, xdy5*, incident.ioc_process_names), executables in /tmp, /var/tmp, /dev/shm, /volume*/@tmp, processes with *.L0CK3D / read-me3.txt files open for writing, and high CPU outside Synology paths (containers excluded). A process whose executable is under a Synology path (/usr/syno, /var/packages, /bin, ...) needs a reason besides the open files; the scan lists it under skipped with the --pid that adds it. PID 1, kernel threads and the scanning script with its parents are never signalled, also with --pid.
• The freeze signals exactly the processes the scan listed: same PID, start time (/proc/PID/stat field 22) and executable; a PID reused in between is reported and skipped.
• --stop-sync: after the freeze, each of the packages Cloud Sync, Synology Drive, Hyper Backup and Container Manager (or Docker) that is running is stopped with SYNO.Core.Package.Control stop. Stopping Container Manager stops every container. The IDs it stopped are recorded in contain-packages.json next to the session cache on this computer.
• --release: SIGCONT to the PIDs recorded on the NAS (incident.contain_state_file) and any --pid, then SYNO.Core.Package.Control start for each recorded package; the record is deleted once every package started. It starts packages, not single containers: a container comes back when its restart policy (auto-restart in Container Manager) starts it with the package.

nas incident rescue does the memory capture and key recovery with soimy/c3rb3r-rescue, fetched at run time at the commit in incident.rescue_commit:

1. contain: the freeze above (--no-contain skips it).
2. toolkit: clones the toolkit and checks the commit. --rescue-dir DIR uses an existing checkout when git status --porcelain is empty and HEAD is that commit (--force-unpinned-toolkit for any other).
3. capture: as root on the NAS (temporary Task Scheduler task, or directly with --backend local), the toolkit's capture_process_memory.py inspect and capture for each frozen PID into a new case folder under --capture-dir. The folder has to be on a USB disk or another volume than the affected data; volumes are compared by mount source in /proc/self/mountinfo (every Btrfs shared folder is its own subvolume with its own device number, so device numbers do not tell volumes apart); --force-same-volume captures onto the same volume. A --capture-dir with a symlink in its path is refused. With --backend password the capture tool goes through deploy.stage_dir (DSM answers 4803 to a task script that carries it inline) and runs (from stdin) only if its sha256 matches the uploaded file. The case folder is then handed to the signed-in DSM account (id -u, chown) so File Station can list and download it.
4. pull: downloads the capture to the workdir on this computer after checking free space there (the capture's readable bytes plus 256 MiB); with --backend local a workdir on the NAS's system partition is refused. --keep-on-nas stops after the capture.
5. venv: a venv (Python incident.rescue_min_python, 3.11, or --python) with the toolkit's requirements installed by pip --require-hashes: the sha256 of every PyPI file of numpy 2.3.5, cryptography 50.0.2, cffi 2.1.1 and pycparser 3.12 is kept in nas/rescue.py for the pinned commit; other pins install without hash checks with --force-unpinned-toolkit. Then the toolkit's self-tests.
6. keys: recover_process_key.py on each capture; candidates are files with mode 400, never printed. A process that is not the reviewed encryptor stops here with ValueError: Executable does not match the reviewed sample profile.
7. sample (--sample NAS_FILE [--expected-sha256 HEX]): copies the file and tries each candidate on the copy.
8. decrypt (--decrypt-from NAS_FOLDER --decrypt-to DIR): decrypts copies with the verified candidate (--force-unverified-key: the first candidate when no --sample verified one).

--force turns on --force-same-volume, --force-unverified-key and --force-unpinned-toolkit together.

Each step is recorded in <workdir>/state.json (--workdir, default ~/.local/share/synology-nas-cli/rescue/<time>); the same command continues where it stopped. What it writes on the NAS:

• the case folder --capture-dir/case-<time>-<random>/pid-N (kept; owned by the signed-in account; delete it when the capture is safe elsewhere). The capture tool runs from stdin (the verified bytes); no copy of it is written to the case folder. The chown/chmod walk goes through file descriptors opened with O_NOFOLLOW and leaves symlinks alone. In testing on a DSM shared folder, folders created with mode 0700 were listed as 0755 afterwards (files kept 0400); check who can read that shared folder.
• with --backend password: the uploaded tool deploy.stage_dir/nas-rescue-tool-<random>.py and the result file deploy.stage_dir/nas-incident-rescue-<token>.json, both deleted after the run, and the temporary root task nas-incident-rescue, deleted after the run.
• the contain step: the temporary task nas-incident-contain and its result file (deleted), and the freeze's state file incident.contain_state_file (/root/.nas-incident-contain.json), removed by nas incident contain --release.

JSON: schemas/incident-rescue.schema.json.

If the audit shows ransomware_files FAIL or external_signins FAIL you are past hardening: follow docs/INCIDENT-C3RB3R.md (isolate first, keep evidence, restore from snapshots).

nas incident fix

Runs the audit, prints the plan, asks for confirmation (--yes, NAS_YES=1 or assume_yes: true answer yes; without a terminal and without those it exits 3 with Not applied: add --yes (or NAS_YES=1).), applies the changes in this order, reads each one back, then runs the audit again and prints before -> after. --dry-run prints the plan and the exact calls and sends no write. Exit status 1 when a change fails or the final audit still has a FAIL.

Order: snapshot_worm -> snapshots -> packages -> smb_min_protocol -> quickconnect -> router_port_forwarding -> autoblock -> admin_account -> firewall -> rotate_password (opt-in) -> upgrade (opt-in, reboots).

Firewall lockout check. Before the firewall change the CLI checks, and lists in the plan: HTTP(S) proxies are configured for the origin; the origin is a loopback address (SSH tunnel, local proxy) or a public address; the newest successful sign-in of this account in DSM's connection log shows a loopback, IPv6 or public source; or that logged source differs from the local address this computer uses to reach the NAS (NAT, a proxy, or the sign-in came from another device). When a check does not pass, the change waits for --force-firewall (or --force), which applies it with the check result in the plan note. The allowed set contains the address DSM logged. After applying, it signs in again over the same origin from scratch; if that fails it prints rescue steps: another computer on the LAN, Synology Assistant / find.synology.com, Tailscale userspace mode (DSM sees 127.0.0.1, which the firewall did not filter in testing), and the RESET button (mode 1). IPv6 allow-list entries are not written as rules, so IPv6 sources are dropped. 100.64.0.0/10 (Tailscale) is also the range CGNAT ISPs use on the WAN side: on a NAS that dials PPPoE itself, a global allow rule for it would admit other subscribers, which is why the rules go on the LAN interfaces.

A NAS with its own public address (it dials PPPoE itself, or sits in a DMZ) has no router NAT in front of it: the DSM firewall is then the only layer between every DSM service and the internet. QuickConnect and UPnP port forwarding open DSM to the internet even behind NAT.

MCP server and agent skills

MCP server (nas mcp)

nas mcp runs a Model Context Protocol server over stdio (JSON-RPC 2.0; protocol versions 2025-11-25, 2025-06-18, 2025-03-26, 2024-11-05) exposing 15 tools: setup, doctor, whoami, status, health, net, services, logs, alert, incident_audit, incident_fix, pkg_list, volume_list, tailscale_status, and api_read.

claude mcp add synology-nas --scope user -- /path/to/synology-nas-cli/bin/nas mcp
claude mcp add synology-nas --scope user -- /path/to/synology-nas-cli/bin/nas mcp --auto-confirm

incident_fix applies its plan when a call has confirm: true, or has no confirm on a server started with --auto-confirm; confirm: false is always a dry run. NAS_YES and assume_yes do not change MCP calls. The setup tool fills fields the configuration does not have yet and takes op:, keychain and env credential sources; changing a value already in effect (config file, environment such as NAS_ORIGINS, or the server's --lan-origin) for origins, user, password_source, otp_source, tls, allowed_networks, stage_dir or webhook_file, and command: sources, go through nas setup on the command line (the tool answers exit 2 naming the field). Built-in defaults (tls pin, otp_source op) do not count as set; public allowed_networks entries are added on the command line. Fields such as user, descr, log text, cmdline and file names carry text chosen by whoever sends sign-ins to the NAS or runs processes on it.

Full tool list, schemas and configuration for Claude Code, Claude Desktop, Cursor and Codex: docs/MCP.md.

Agent skills installer

The skills/ folder contains skills/synology-nas/SKILL.md and skills/synology-ransomware-response/SKILL.md. Install them into existing skill directories (~/.claude/skills, ~/.cursor/skills, ~/.codex/skills, ~/.agents/skills, ~/.grok/skills, ~/.gemini/skills, ~/.config/opencode/skills, ~/.hermes/shared-skills):

./skills/install.sh                  # symlink skills into detected agent folders
./skills/install.sh --copy           # copy instead of symlink (--dry-run, --uninstall also available)

On Windows PowerShell:

.\skills\install.ps1                 # supports --copy, --dry-run, --uninstall

Alerts and webhooks

nas alert runs every health and security check once and exits 1 when something is at warning/critical level. Every finding is {level, code, kind, message}. With --push FILE it POSTs only what changed since the last successful push to {"url", "header"} from FILE: new conditions, a reminder every 24 h for warning/critical ones still present, every event, resolved keys, and one heartbeat a day. Codes, the body format and receiver examples are in docs/ALERTS.md.

Three ways to run it:

1. On the NAS, set up for you: nas alert-deploy copies the code into a root-only folder (deploy.root_dir), creates a root Task Scheduler task running nas --backend local alert --push every 10 minutes, and points DSM's own notification webhook (Control Panel > Notification > Webhooks) at the same URL.
2. On the NAS, by hand: the same three pieces done in DSM's UI. Steps in docs/ALERTS.md.
3. From another always-on machine: cron or launchd running nas alert --push ... with the password backend. See docs/ALERTS.md.

Receivers: any HTTPS endpoint that takes a JSON POST with one header (generic JSON receiver), a chat-bot "routine" webhook that starts an agent run per POST (Grok-Bot-style), or no webhook at all: DSM's built-in notifications (email, Synology mobile push through the DS finder / Synology app) cover DSM's own warning/error events. All three are in docs/ALERTS.md.

Command reference summary

nas setup --origin URL --user USER --password-source SOURCE   # write the config, sign in once, pin the certificate
nas doctor        # config, credentials, origin, TLS, login, DSM version, 2FA, capabilities, clock
nas whoami        # backend, origin, credential source, session, account, admin flag, DSM version
nas status        # model, DSM version, uptime, SA-26:13 verdict
nas net           # interfaces, PPPoE (public address), firewall, gateway
nas services      # SSH / FTP / SMB / AFP / NFS / rsync / QuickConnect / AutoBlock / DSM ports
nas inventory     # shares, packages (SA-26:14 flags), containers, users (2FA), scheduled tasks
nas health        # disks (SMART, temperature), pools, volumes, UPS, CPU, memory
nas logs --since "2026-10-30 00:00" --top 5   # failed sign-ins by user/IP, external successes
nas ransom-scan   # File Station search for *.L0CK3D, *.LOCK3D, read-me3.txt (one task per pattern)
nas exposure      # TCP probe of LAN and public addresses from this machine
nas incident [--probe] [--scan] [--deep] [--hours 24] [--failed-threshold 20]
nas incident fix [--dry-run] [--yes] [--only LIST] [--skip LIST] [--share S] [--ransom-scan] [--upgrade] [--rotate-password]
nas upgrade --dry-run | nas upgrade | nas upgrade --yes | nas upgrade --wait-only
nas pkg list | start ID | stop ID | install ID [--volume /volume1] | uninstall ID [--remove-data] | default-volume [/volumeN]
nas volume list | volume atime volume_1 noatime
nas tailscale status | tailscale login-url [--force]
nas alert [--no-update] [--push webhook.json]
nas alert-deploy [--test] [--interval 10] [--webhook-item op://VAULT/ITEM] [--no-dsm-webhook]
nas login [--save] [--trust-device] [--no-cache] | nas logout [--forget]
nas config init [--force] | nas config show
nas trust | nas trust --reset https://HOST:PORT                # TLS certificates trusted on first use
nas api SYNO.Core.System info --version 1                     # any DSM API; writes need --allow-write
nas --json <command>                                          # JSON output for everything
nas --no-input <command>                                      # prompts answer with exit 3 (also NAS_NO_INPUT=1; automatic without a terminal)
nas --yes <command>                                           # accept every confirmation (also NAS_YES=1, config assume_yes; see "What changes the NAS")
nas --force incident fix --yes                                # apply changes whose checks do not pass (--force-firewall, --force-admin, snapshot rotation, reinstall)
nas mcp [--auto-confirm]                                      # MCP server on stdio (docs/MCP.md)

Documentation index

• docs/AGENT-RUNBOOK.md — Step-by-step sequence for AI agents (setup → doctor → incident → incident fix → --deep → alert-deploy).
• docs/INCIDENT-C3RB3R.md — Public incident page for the 2026 C3RB3R / .L0CK3D ransomware campaign, advisories, timeline, IOCs, decision steps, recovery and prevention.
• docs/HARDENING.md — Synology DSM security hardening checklist with sourced explanations, English / 繁體中文 DSM UI paths, and matching nas commands.
• docs/TROUBLESHOOTING.md — Solutions for firewall/AutoBlock/2FA lockouts, Mode 1 reset, reverse proxies and Tailscale 127.0.0.1, unsupported WORM models, Google Drive 750 GB/day quota, SMB1 devices, DSM API error codes, "up to date" branch traps, and TLS pin resets.
• docs/MCP.md — MCP server tools, arguments, schemas, and client setup.
• docs/GROK-BOT.md — Grok Bot: nas on the bot's cloud computer (Tailscale) or on a computer with the Grok Bot app, skills, the alert routine webhook, and a bot description.
• docs/ALERTS.md — Alert codes, webhook payload, receivers, and deployment (alert-deploy, manual DSM task, cron/launchd).
• docs/DSM-API-NOTES.md — DSM 7 Web API quirks and parameter encoding rules relied on by nas.
• docs/EXIT-CODES.md — CLI and MCP _meta.exit_code definitions (0–7, 130).
• schemas/ — JSON Schemas for incident, incident-fix, incident-contain, incident-rescue, alert, status, health, and whoami.
• llms.txt — Entry-point index for LLM agents.

What changes the NAS

• Commands that change the NAS: incident fix (asks, or --yes), incident contain (SIGSTOP with --yes; --stop-sync stops packages; --release), incident rescue (asks, or --yes: freeze, temporary root tasks, the capture folder), upgrade (without --yes it still uploads the .pat and runs PreCheck, then deletes the upload; --yes installs), pkg start|stop|install|uninstall|default-volume VOL, volume atime, tailscale login-url, alert-deploy, login --save / logout --forget (local keychain only), trust --reset (local file), and api with --allow-write. ransom-scan, incident --scan and incident fix --ransom-scan create temporary File Station search tasks on the NAS (stopped and cleaned afterwards). nas api sends methods that are not reads with --allow-write, --yes or NAS_YES=1.
• --yes, NAS_YES=1 and config assume_yes: true answer every confirmation of the CLI: incident fix applies its plan (with --upgrade it installs DSM and the NAS reboots, a PreCheck with notes included; with --rotate-password it changes the password); upgrade installs after PreCheck and the NAS reboots; incident contain freezes the candidates (and with --stop-sync stops the packages); incident rescue runs its steps; api sends write methods as with --allow-write. nas mcp takes its answer from each call's confirm and from --auto-confirm, not from these.
• incident fix --dry-run prints every write call it would send. The plan always shows current -> new values.
• Passwords, SIDs and SynoTokens are never printed. nas api prints raw DSM output, which can include serial numbers and account names; the other commands filter those.
• Each password sign-in that fails counts toward AutoBlock; the CLI reports a failed sign-in once and stops.
• alert-deploy installs code that runs as root on the NAS in a root-only folder outside the shared folders.

Tests

tests/run_offline.sh      # all offline tests with python3, and with Python 3.8 when `uv python find 3.8` works
tests/smoke_live.sh       # optional: read-only commands against your NAS (uses your config)

License

MIT, Copyright (c) 2026 Akari Sora. See LICENSE.