[Transfer] Synology DiskStation Administration CLI Guide: Reading Notes and Command Cheatsheet

Short version

Synology’s official CLI administration guide is not a beginner manual for the DSM web interface. It is a compact reference for scripting, automation, and system integration. The useful parts cover local users, local groups, shared folders, network configuration, service management, Windows workgroup or ADS domain settings, and DSM error numbers.

This post is an English reading note and command cheatsheet based on Synology’s official PDF, CLI Administrator Guide for Synology NAS. Because the original PDF is a copyrighted Synology document, this post does not reproduce or translate the full document verbatim. Instead, it reorganizes the material into a bilingual blog-friendly guide for quick reading and daily operations. For exact wording, parameter definitions, version-specific behavior, and legal notices, use the official PDF linked at the end.

1. Who should read this guide

If you only create users, shared folders, and services through the DSM Control Panel occasionally, the graphical interface is usually enough. The CLI guide becomes useful in these situations:

1. You need scripts to create, modify, or remove accounts in batches.
2. You want to initialize a NAS with predefined shares, network settings, and domain settings.
3. You are integrating an external program with DSM management capabilities.
4. You need to understand DSM command error numbers.
5. You want to verify system objects quickly from an SSH session.

These commands are administrative tools. Many actions require root or equivalent privileges. Do not treat them as casual user commands, especially when deleting users, deleting groups, changing network settings, or restarting services. Confirm the target object and your current access path before running destructive or connectivity-sensitive operations.

2. Document structure

The official PDF is short, but dense. It can be read as three parts:

Chapter 2 is the most useful part for day-to-day operations. It groups the tools by object: synouser for users, synogroup for groups, synoshare for shared folders, synonet for network interfaces, synoservice for services, and synowin for Windows workgroup or ADS domain settings.

3. User management: synouser

synouser handles local user account operations. The official guide describes these core actions:

For automation, the easiest mistakes are argument order and username validation. Usernames are case-insensitive and have defined length and character restrictions. Their first and last characters also have extra rules. A script should validate input before handing it to DSM commands.

Password handling needs the same caution. Do not store plaintext passwords in long-lived scripts, logs, or CI output. A safer approach is to read secrets from a controlled secret store, temporary environment variable, or read-only configuration, then make sure command logs do not expose the arguments.

4. Group management: synogroup

synogroup manages local groups. Its model is similar to user management, but the focus shifts from account attributes to group objects and membership.

In practice, avoid attaching every user directly to every shared folder. A more maintainable model is to create role-oriented groups such as media-admin, backup-writer, or project-readonly, then put users into those groups. Later user changes only require membership updates instead of repeated permission edits across multiple shares.

5. Shared folder information: synoshare

synoshare deals with shared folder information. On a NAS, shared folders are where permissions, storage, and service entry points meet, so these commands deserve more care than simple account metadata.

The guide includes synoshare because scripted environments often need to read or configure shared directory information. Common cases include:

Read-only queries are relatively low risk. Creating, deleting, or changing shared folders is different. Always run a dry run when possible, or at least print the target list before making changes. Shared folders usually hold real data, so a bad change has a much larger impact than a wrong metadata field.

6. Network settings: synonet

synonet is related to network configuration. This is especially risky over remote SSH because a wrong network change can immediately disconnect the current session and may require local access or another management channel to recover.

Read this area as two categories:

Before changing network settings remotely, confirm these points:

1. You have a second management path, such as a console, an out-of-band channel, a standby address, or someone onsite.
2. You have recorded the current IP address, gateway, DNS, interface name, and routes.
3. You can roll back automatically if the change fails.
4. You are not in the middle of backups, sync jobs, downloads, or business access windows.

Network commands can be automated, but the rollback path must be designed before the automation.

7. Service control: synoservice

synoservice is a common tool in operational scripts because it can inspect, start, stop, or restart DSM services. It fits tasks such as:

Avoid the reflex of restarting a service as soon as it looks abnormal. The service failure may be only a symptom. The real cause could be low disk space, database corruption, a port conflict, permission errors, or invalid configuration. A better order is: check status, read logs, verify dependencies, and only then decide whether a restart is appropriate.

8. Workgroup and ADS domain settings: synowin

synowin covers Windows workgroup and ADS domain settings. For home or small-team NAS use, a workgroup may be enough. In company environments, a NAS is often joined to a domain so accounts and permission policies can be managed centrally.

The key question is not whether the command can run, but whether the authentication path remains intact after it runs. Before joining or changing domain settings, confirm:

1. DNS can resolve the domain controllers.
2. NAS time is synchronized with the domain.
3. Administrator credentials are valid.
4. A local fallback administrator account can still log in.
5. SMB, ACLs, and shared-folder permissions match expectations.

A failed domain change can affect every access path that depends on domain authentication, not just one user.

9. Error numbers: do not read numbers alone

Chapter 3 of the official PDF lists Synology error numbers. Error codes are useful for script decisions, but they are not a full diagnosis. Read them together with the command, arguments, object state, and system logs.

For example, an error that looks like “object not found” may mean:

1. The target user or group really does not exist.
2. The script passed arguments in the wrong order.
3. Username case or special-character handling is inconsistent.
4. The command ran on the wrong DSM instance.
5. Insufficient privileges caused an incomplete query result.

An error number is an entry point, not the complete explanation.

10. Suggested workflow

If you plan to include these tools in your own operational scripts, structure the workflow like this:

# 1. Query the current state
# 2. Compare current state with desired state
# 3. Print the planned changes
# 4. Modify only after explicit confirmation
# 5. Query again and verify the result

For users, groups, and shared folders, scripts should be idempotent: do not recreate objects that already exist, do not delete blindly when the target is missing, and do not make unnecessary updates when attributes already match. For network and domain configuration, prepare a rollback plan as well.

11. One-page cheatsheet

12. Summary

The value of Synology’s CLI administration guide is not its length. It is useful because it gathers the command entry points for several important DSM management objects. For daily NAS users, it is a reference for SSH-based operations. For automation, it is a boundary checklist for script design. For troubleshooting, it provides command-level entry points and error-number references.

Three rules matter most in practice:

1. Query first, modify later.
2. Record or back up the current state before high-risk changes.
3. Treat the official PDF as the final reference; this post is only a reading note and quick lookup aid.

Source

This article is an English reading note, quick reference, and translation-oriented adaptation based on Synology’s official document. It is not a full reproduction of the official PDF.

Official PDF: https://global.download.synology.com/download/Document/Software/DeveloperGuide/Firmware/DSM/All/enu/Synology_DiskStation_Administration_CLI_Guide.pdf