Synology_enable_M2_volume: a DSM patch that lets Storage Manager use third party NVMe drives

What the script changes on the NAS

The repository enables creating volumes with non-Synology M.2 drives, and the README lists the two effects of running it. The first is that creating M.2 storage pools and volumes becomes possible entirely from within Storage Manager, so you get the normal Synology interface rather than a command line workaround. The second is that Health Info is enabled for non-Synology NVMe drives, with the parenthesis that this one does not apply in DSM 7.2.1 or later.

That parenthesis is the important operational detail. The behaviour differs by DSM release, and the compatibility table in the README is organised by DSM version precisely because the patch touches internals that Synology changed between releases.

The primary language is Shell, the licence is MIT, and the release history shows v1.1.22 in July 2024, v1.1.21 in February 2024 and v1.1.19 in January 2024. The last push to the repository was on 2026-09-10, so the work continues even though the tags are infrequent.

The project topics place it in the Synology ecosystem with diskstation, dsm, rackstation and synology-nas among them, and the description is short enough to be the whole pitch: enable creating volumes with non-Synology M.2 drives.

The compatibility table is the real documentation

The README has a long confirmed working table, and it is the part to read before anything else.

The pattern it reveals is that there are two projects and a version boundary. For models on DSM 7.2.1 and later, several entries point at Synology_HDD_db instead, and for older DSM versions the same models point at Synology_M2_volume. The DS923+ on the R1000 platform is listed as working across a range of DSM versions from 7.1.1-42962 Update 4 upward, with a note to use only the Synology_HDD_db approach. The DS723+ and DS423+ appear as well, and the table includes a 23 Series section with the DS1823xs+ on the V1000 platform marked as not working on DSM 7.2.1 and later.

So the question you actually have is not whether the script works but which project works for your DSM release, and the answer changes at 7.2.1. That is why both projects are linked from the same table.

The author is also direct about the limits of that knowledge. The README says the script will work for DSM 7.2 and some models running DSM 7.1.1, and that for a full list of which models it will work with, the author does not know yet. What is known is that it works on models Synology lists as supported for creating M.2 volumes, and on some of the 21 and newer enterprise models.

That combination of a careful table and an admission of incomplete knowledge is more useful than a confident claim would be, because it tells you the table is the source of truth and that the author has tested rather than assumed.

What the project expects from you

This is a patch to the DSM installation, and the practical requirements follow from that.

The script writes into the DSM installation on the NAS, so it needs the administrative access that a DSM shell session provides, and the changes are not something Synology supports. Running it means the storage stack no longer matches the vendor's tested configuration, which is exactly the kind of thing a support contract excludes.

The MIT licence covers the script itself, and it is a personal project with donation and sponsorship links, which tells you who maintains it and on what basis. The README also carries a visitor counter badge, which is a small signal of a project maintained by one person for their own devices first.

The scope is narrow in a useful way. This is not a general DSM modding framework. It does one thing, it does it by patching the storage manager components that decide which drives are acceptable, and it is versioned against DSM releases so that a DSM update that breaks it is a known event rather than a surprise. The alternative approach, which the README references through the sibling project, is closer to what Synology_HDD_db does, and the table tells you which to reach for.

The two repositories and the DSM 7.2.1 boundary

The naming in the compatibility table is worth unpacking, because the two projects are not interchangeable.

Synology_M2_volume is the project that patches the M.2 volume path specifically, and it is what the table points to for older DSM versions. Synology_HDD_db is the sibling that works with the newer DSM storage database, and the table points there for DSM 7.2.1 and later. The Health Info note in the description lines up with the same boundary, since the health reporting path changed along with the storage database.

What that means practically is that a reader arriving at the wrong repository will find a script that does nothing useful on their system, and the way to tell which is which is the DSM version in the table rather than the model. The model matters too, since the table is organised as model, platform, DSM version, whether it works, and a note pointing at the other project.

The table also shows a hardware split. Some entries carry a platform column value of R1000 or Geminilake or V1000, which are the board revisions, and the same model can appear against several platform values with different DSM versions listed.

For a reader planning an install, the sequence is therefore: find the model and board in the table, find the DSM version, and take the note. Anything not in the table is genuinely unknown rather than known bad, and the README says so directly.

What running the patch costs you

There is no way to run a storage patch on vendor firmware and keep every guarantee the vendor gave you, and the project does not pretend otherwise.

The warranty point is the obvious one. Synology's support covers the configuration Synology ships and tests, and a patched storage manager is not that. The practical consequence is that a future support interaction may be complicated by the state of the system, and a disk failure investigation may be harder.

The data risk is the second. A pool built on a drive the vendor did not certify means the failure prediction, the health information and the firmware update behaviour for that drive are the vendor's generic handling rather than anything specific to that drive. The Health Info feature the patch enables is exactly the thing that exists to give you that information, and on a drive Synology did not test, that information is less trustworthy than the same feature on a certified drive.

There is also the update axis. DSM updates replace the patched files, so a major or minor DSM release can undo the patch, and the version-specific table means you then need to find out whether a newer script exists for the new release. The project's own release history shows versions tracking DSM releases, which is the pattern you would expect, and the last push well after the last tag suggests work continues between releases.

None of that is a reason not to use it if you need it. It is a reason to know what you are trading, and to run the script on a device you can rebuild rather than one holding your only copy of anything.

Editorial conclusion

Synology_enable_M2_volume fits a Synology owner whose model has an M.2 slot Synology refuses to use with a third party drive, and who is willing to modify vendor firmware and accept the consequences. It does not fit a business that depends on warranty, and it does not fit a model the compatibility table marks as unsupported. Before running it, read the confirmed model table rather than the general description, because the README says outright that a full list of working models is not known, check which DSM release you are on, and note that the related project for newer DSM versions may be the one you actually need.

Frequently asked questions

Official sources

1. 007revad/Synology_enable_M2_volume on GitHub
2. Issues
3. License: MIT
4. README
5. Releases