Synology_HDD_db: adding third-party drives to DSM's compatibility database

The compatibility list problem Synology_HDD_db was written for

Synology NAS units ship with a database of drive models that DSM treats as compatible. Put in a drive that is not in that database and DSM reports it as unverified or unsupported, and on some models it refuses to create a storage pool at all. The drive usually works fine. The list is the obstacle.

Synology_HDD_db is a shell script that edits those database files so the installed drives appear in them. According to the README, it covers SATA and SAS HDDs and SSDs, SATA and NVMe M.2 drives, the Synology M.2 PCIe card database and the Expansion Unit database. It is aimed at the person who bought a DS423+ or DS223j, installed drives Synology does not list, and now sees warnings in Storage Manager or cannot build a pool. It is not a driver, not a kernel module, and not a replacement for DSM's storage stack. It changes text files that DSM reads.

The README also documents a second audience: owners of 2025-series and later Plus models, where the compatibility rules were tightened further. A separate document in the repository, 2025_plus_models.md, summarises which drive types are supported for new installations, cache creation and migration on those units once the script has run.

What the script actually does on each run

The README lists the sequence. The script detects the NAS model and DSM version so it knows which database files to edit, enumerates the installed drives, and reads each drive's model number and firmware version. It backs up the database files if no backup exists yet. It then checks whether each drive is already present and adds the missing ones.

That backup step matters more than it looks. The script edits files that live on the running system, and the restore option exists precisely because those edits need to be reversible. The README describes the restore option as undoing all changes made by the script, which is the only rollback path documented.

Beyond the database edit, the script exposes a set of optional behaviours, each described in the README: preventing DSM from auto-updating the drive database, disabling support_disk_compatibility and support_memory_compatibility, raising the max supported memory setting to match installed RAM, setting write_mostly on internal HDDs so DSM reads from internal SSDs, and disabling Western Digital Device Analytics. That last one targets the WDDA warning DSM shows for WD drives after three years, which the README links to press coverage describing the practice as age-shaming. DSM 7.2.1 already disables WDDA, so on that version the option is redundant.

The script also enables M2D20, M2D18, M2D17 and E10M20-T1 cards on NAS models that do not officially support them, and checks whether M.2 volume support is enabled on models with M.2 or PCIe slots. For DSM 7.2 and later it enables creating M.2 storage pools and volumes from Storage Manager, including drives in those PCIe adaptor cards, with the README noting that this needs the script scheduled to run at boot.

Installing Synology_HDD_db and running it the first time

The README does not give a git clone or a package manager command. It points at the releases page: download the latest Source code (zip) from https://github.com/007revad/Synology_HDD_db/releases and save it to a folder on the Synology. The README warns in bold not to save the download to a particular location, but the sentence is truncated in the repository text, so check the full README before choosing a folder.

After unzipping, the script is syno_hdd_db.sh at the top level of the repository. The README does not spell out a full command line for the first run, and the repository text available here does not include one, so the concrete instruction is to run that script on the Synology after saving it there. The README does state that you should not use the -f or --force option if you want to enable SSD TRIM on third-party SSDs and NVMe drives, so a first run aimed at TRIM should leave those options out.

Expect output listing the detected NAS model, the DSM version, each drive's model and firmware, and whether that drive was already in the database or was added. The script ends by reminding you that a reboot may be needed.

Whether you need that reboot depends on your hardware. The README states that DSM 7 rechecks disk compatibility without a reboot if you have no M.2 drives, and that if you have M.2 drives you may need to reboot.

A first run on a machine with third-party drives should end with those drives listed as added. If it does not, the README's troubleshooting direction is the restore option, not a second run.

The README also carries a warning about TRIM itself, separate from the force flag: TRIM on SSDs using the second method described in Synology's knowledge base article can result in data loss in RAID 5, RAID 6 and SHR arrays with three or more drives, and you should not use TRIM in those configurations unless you are certain your SSDs use the first method.

Where Synology_HDD_db is the wrong tool

The script edits DSM's compatibility files. It does not make an incompatible drive compatible in any physical or firmware sense. If a drive fails to initialise, drops off the bus, or reports SMART errors, adding its model number to a database will not change that. The README's 2025-series table is a good illustration of the boundary: it describes what becomes possible for new installations, cache creation and migration on those models, not a claim that every drive works everywhere.

IronWolf Health Monitor support has a hard hardware limit. The README states that updating it to v2.5.1 for recent IronWolf and IronWolf Pro drives is for NAS units with x86_64 CPUs only, and that installing IronWolf Health Management on 2022-series and newer models that lack it is untested. Untested is the word used. Treat that path as unverified.

The M.2 volume support line carries a parenthetical question mark in the README itself: enabling M.2 storage pools and volumes in DSM 7.2 and later is marked "(newer models only?)". A project that hedges on its own capability is telling you the support matrix is not fully mapped.

Finally, the script is a system-file editor that runs with elevated privileges. If you are not comfortable with that, or if your drives are already on the compatibility list and nothing is complaining, there is no reason to run it. The README's own restore option is the acknowledgement that a bad run needs an undo.

How it differs from just ignoring the warning

The obvious alternative is to do nothing. DSM shows an unverified-drive warning and, on many models, still lets you create the pool. That is a real option and costs nothing. The difference is what the warning blocks. On models where the compatibility check gates pool creation or M.2 volume creation, ignoring it is not available. Synology_HDD_db exists for that case, and for the secondary annoyances: the non-Synology memory notification, the WDDA age warning, and the max-memory setting that DSM uses when calculating the reserved RAM area for SSD caches.

A second alternative is to buy drives from Synology's list. That resolves the warning without touching system files, and it is the only path with vendor support behind it. The trade-off is price and model availability, which is the reason the script exists.

A third route is editing the database files by hand. The script does the same job with a backup step, a restore option, drive enumeration and firmware detection, and a version check that offers to download a newer release. The README notes that the new-version messages time out so they do not block a scheduled run. Hand-editing gives you none of that, and it is easy to leave the system in a state with no recorded backup.

Maintenance, licence and what to check before you commit

The repository is not archived and the last push was on 2026-09-10, which is recent. Releases are frequent: v3.6.139 on 2026-08-30, v3.6.138 on 2026-08-20, and v3.6.137 on 2026-08-03. That cadence matters because DSM updates can change the database files the script edits, and each release is a response to something in the field. The cost of adopting it is therefore not a one-time install but keeping the script current, which the built-in update check is designed to make easier.

The licence is MIT. That permits use, modification and redistribution with the licence and copyright notice retained. It does not make Synology support the result. Editing the compatibility database is outside the vendor's supported configuration, and the MIT grant comes from the script's author, not from Synology. Nothing here is legal advice; if you need a support contract to remain valid, that question is for Synology, not for this repository.

The README does not document a scheduled uninstall or a way to revert individual options. The documented undo is the restore option, which reverses all changes the script made. If you want to keep only some of the effects, the README does not describe how. Verify that the backup files exist after the first run before you rely on the restore path.

Editorial conclusion

Adopt it if you already own non-Synology drives and a NAS whose DSM keeps flagging them, or if you need M.2 storage pools on a model that hides them. Do not adopt it if your drives are on the official list and nothing is warning you, because every run edits database files under /etc and /var, and the script's own README warns that enabling TRIM on SSDs using the second TRIM method can cause data loss in RAID 5, RAID 6 and SHR with three or more drives. Before running it, read the -f and --force warning in the README, confirm your DSM version is covered (the README lists DSM 6 and DSM 7 through 7.4), and check that the backup the script makes of the database files actually exists on your system.

Frequently asked questions

Official sources

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