# Synology_M2_volume: Creating M.2 Storage Pools on DSM 7 > Synology_M2_volume is a Shell script that creates a RAID storage pool from supported NVMe drives on DSM 7, after which the filesystem volume is created in Storage Manager. It fills a hardware and DSM support gap, but carries version, interface, and drive-type constraints. **007revad/Synology_M2_volume** — Easily create an M.2 volume on Synology NAS - Repository: https://github.com/007revad/Synology_M2_volume - Stars: 1,442 · Forks: 80 - Language: Shell - License: MIT - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/007revad-synology-m2-volume ## The NVMe Pool Gap Synology_M2_volume Addresses Synology_M2_volume targets Synology NAS administrators who have one or more NVMe devices but cannot create the required storage pool through the normal Storage Manager workflow. The repository is written primarily as a Shell project and centers on one script, `syno_create_m2_volume.sh`. Its stated purpose is to avoid a lengthy manual procedure and typed command sequences while also avoiding a dependency on Synology-branded NVMe drives. The script handles the RAID and storage-pool stage only. After it finishes, the administrator must open Storage Manager and use the Create Volume action to add the filesystem volume. That division of work matters because the project does not present itself as a complete replacement for DSM storage management. It is intended for DSM 7 and later. A DSM 6 installation requires release v1 and, according to the README, the script must run without its auto update option. Version 2 also removed SATA M.2 support, so administrators using SATA-connected M.2 drives must remain on v1 and apply the same version warning. The target is therefore narrower than the phrase "create an M.2 volume" suggests: DSM generation, bus type, and script release all have to align. ## How syno_create_m2_volume.sh Builds the Storage Pool Version 2 uses the `synostgpool` command to create the selected storage pool from available NVMe drives. The administrator runs `syno_create_m2_volume.sh`, answers several questions, types `yes` to confirm, and selects options by entering the displayed number. The README says that drives may come from internal NVMe slots or a Synology M.2 PCIe card, and version 2 labels them as "M.2 Drive #" to match Storage Manager terminology. The supported choices are Basic, RAID 0, RAID 1, RAID 5, RAID 6, RAID 10, SHR, SHR 2, JBOD, and RAID F1. Availability depends on drive count and script version. Basic needs one drive and permits only one. RAID 1 needs at least two and supports up to four according to the table. RAID 5 and RAID F1 require at least three, while RAID 6 and RAID 10 require at least four. SHR 2 also requires four or more. SHR, SHR 2, JBOD, and RAID F1 are listed as DSM 7 features introduced in version 2. The pool can contain either a single volume or multiple volumes. According to the README, selecting multiple volumes allows overprovisioning. RAID F1 is enabled on supported systems even when the Synology model does not officially advertise that RAID level. This is an explicit compatibility extension rather than an incidental interface option. The script can also skip its drive check. It no longer performs a separate reboot or online assemble after pool creation. Drive-check progress is instead left visible in Storage Manager. The pool creation is therefore the automated stage, while final volume creation remains a DSM task. ## DSM, NVMe Bus, and Release Constraints The clearest limitation is version coupling. Version 2 and later support DSM 7 only, and DSM 6 users are directed to v1 without auto update. A recent release does not remove that boundary. The repository lists `v1.3.26` dated 2025-11-16, while other listed releases include `v2.1.31` dated 2025-04-20 and `v2.0.30` dated 2025-01-10. Release tags are not ordered by their displayed version numbers, so the correct line must be selected for the DSM generation rather than simply choosing the highest-looking number. Physical support is equally specific. Version 2 supports NVMe drives, including drives installed through a Synology M.2 PCIe card, but it removed support for SATA M.2 drives. The README does not claim that every SATA adapter works under v1, so the DSM 6 guidance should not be generalized into broader SATA support for version 2. Some listed model combinations also require another project. The DS1821+ entries in the README state that certain M.2 cards need `Synology enable_M2_card`. That is a separate prerequisite rather than an option inside this script. For Xpenology users, the README states that the script supports unlimited numbers of NVMe drives except for RAID 1 and Basic. It also provides more drive choices than ordinary branded Synology configurations may expose. That makes the script more flexible for Xpenology, but the repository does not provide a complete compatibility matrix for every DSM build or Xpenology release. ## Preparing for the First DSM 7 Pool Creation The repository identifies `syno_create_m2_volume.sh` as the implementation, but the README does not give an installation command, download command, transfer method, invocation syntax, flags, or dependency-installation procedure. It also does not document a rollback procedure. Consequently, there is no documented shell command to include for a first run, and the reader should not infer whether the file must be copied over SSH, uploaded through a DSM interface, or executed through a particular menu. The first documented use begins with obtaining the appropriate release from the GitHub Releases page and ensuring the NAS runs DSM 7 or later for version 2. The DSM 6 path uses v1 and must not use auto update. The hardware must expose the intended NVMe devices through internal slots or a supported Synology M.2 PCIe card. Any model-specific M.2 card prerequisite must also be satisfied. The administrator then runs `syno_create_m2_volume.sh` through the available execution method and follows its numbered prompts. The README says to type `yes`, then enter `1`, `2`, `3`, or `4` for the questions. Those numbers are menu choices, not necessarily drive counts, and the README does not reproduce the complete menu. It would be unsafe to prescribe a specific choice before the script displays it. After the script creates the RAID and storage pool, open Storage Manager and select Create Volume. Version 2 no longer requires a separate reboot or online assemble. If a multi-volume pool was selected, verify that its layout matches the intended allocation behavior before creating volumes. ## Drive Checks, Single Volume, and Multiple Volume Choices Version 2 adds a choice that affects how usable capacity is allocated. A single-volume storage pool is straightforward when one filesystem volume is expected. A multi-volume pool permits overprovisioning, which can make thin allocation available across later volumes. The README states this capability but does not describe a command for changing the choice after creation or explain the precise capacity behavior inside DSM. The script also offers an option to skip the drive check. This makes the workflow shorter, but the project does not state that the check is redundant. It merely removes the script-side operation and directs users to Storage Manager for drive-check progress. Because the README does not define the consistency or failure semantics of skipping it, an administrator who needs a drive check should not treat this option as equivalent to an inspected-and-passed check. Version 2 removed the dry run mode because it was not possible with `synostgpool`. That is a direct operational limitation. There is no documented preview of the exact commands that will be issued against selected drives. Dry runs can be requested in the questions section and users should not claim one is available. The repository also omits a detailed failure recovery guide. It says version 2 no longer needs an online assemble after normal creation, but it does not explain what to do if pool creation is interrupted or if a particular RAID configuration is rejected by DSM. ## Release History, MIT Terms, and Script-Level Alternatives The repository is not archived, and its last push was on 2026-09-10. That is recent activity, but the repository remains a small, model and DSM dependent script rather than a conventional storage application with a documented service lifecycle. Upgrade work consists primarily of choosing the correct release line for the installed DSM version and reviewing `CHANGES.txt` for changes relevant to the selected RAID type. The listed release history does not present a single linear progression. `v1.3.26` is newer than the listed `v2.1.31`, which is consistent with a maintained legacy branch for DSM 6 alongside a v2 line for DSM 7. The README instructs DSM 6 users to use v1 without auto update, so switching between branches requires care. The repository is released under the MIT License. That grants the permissions and conditions stated in the `LICENSE` file, including use, modification, distribution, and sublicensing subject to its notice requirements. This is a factual summary of the license type, not legal advice about compatibility with DSM, drive warranties, or a particular deployment. The real alternative is to create the pool through Synology Storage Manager. That approach stays inside DSM and does not require this Shell script, but the project exists because some NVMe configurations lack the expected Storage Manager path. Another alternative is to keep compatible SATA M.2 handling on the documented v1 branch. Version 2 cannot replace either approach because it excludes SATA M.2 support and has no dry run. ## Conclusion Adopt Synology_M2_volume if the DSM interface does not expose the required NVMe pool creation path for a compatible Synology or Xpenology system. Do not choose version 2 for DSM 6, SATA M.2 drives, or workflows requiring a dry run. Verify the DSM version, NVMe attachment method, selected RAID level, and whether creating the filesystem volume separately in Storage Manager is acceptable before running `syno_create_m2_volume.sh`. ## FAQ ### Which DSM versions does Synology_M2_volume support? Version 2 and later support DSM 7 only. DSM 6 users must use v1 and run it without the auto update option. ### Does Synology_M2_volume create the filesystem volume automatically? No. The script creates the RAID and storage pool, after which the administrator selects Create Volume in Storage Manager. ### Can Synology_M2_volume use SATA M.2 drives or NVMe drives in a PCIe card? Version 2 supports NVMe drives, including those in a Synology M.2 PCIe card, but removed SATA M.2 support. The README directs SATA M.2 users to v1. ### Does Synology_M2_volume have a dry run mode? No. Version 2 removed dry run mode because it was not possible with `synostgpool`. ### Does Synology_M2_volume require branded Synology NVMe drives? No. The project description specifically states that Synology-branded NVMe drives are not required. ## Sources - [007revad/Synology_M2_volume on GitHub](https://github.com/007revad/Synology_M2_volume) - [Issues](https://github.com/007revad/Synology_M2_volume/issues) - [License: MIT](https://github.com/007revad/Synology_M2_volume/blob/main/LICENSE) - [README](https://github.com/007revad/Synology_M2_volume/blob/main/README.md) - [Releases](https://github.com/007revad/Synology_M2_volume/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/007revad-synology-m2-volume