mirror of
https://github.com/007revad/Synology_HDD_db.git
synced 2026-04-25 21:55:59 +03:00
[GH-ISSUE #520] M.2 NVMe's through M2D20 seems not to be added to compatibility list on DS1825+ running DSM 7.3-81180 #179
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/Synology_HDD_db#179
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @kennydm00 on GitHub (Oct 27, 2025).
Original GitHub issue: https://github.com/007revad/Synology_HDD_db/issues/520
I have successfully added the M2D20 to my DS1825+ running DSM 7.3-81180 using your new version of syno_enable_m2_card.sh script.
But now I have trouble getting the connected WD_Black SSDs to be added to the compatibility list using your syno_hdd_db.sh script.
Therefore I have trouble creating a storage pool or volume using the DSM storage manager.
I can however start the syno_hdd_db.sh script with the -f parameter to disable the compatibility check and create the storage pool and volume then, but with disabling the check I loose the ability to create the TRIM scheduler entry for any of the SSDs (the only storage pool setting is the description).
Output of the syno_hdd_db.sh script:
Screenshot of storage manager errors and disabled settings option:
Thank you again for your help for the M2D20 issue and I'm sorry to bother you again...
@007revad commented on GitHub (Oct 27, 2025):
Do you run syno_hdd_db with the -n option? You should always run it with the -n option. This prevents DSM from updating the db files.
Did you migrate the HDDs from a DS418play?
Lets remove those old ds418play db files.
@kennydm00 commented on GitHub (Oct 28, 2025):
Yes I'm running the script with the -n option and I have migrated from an DS418play.
In the /var/lib/disk-compatibility/ folder are many other entries of diskstations, should these also be deleted?
@kennydm00 commented on GitHub (Oct 28, 2025):
I have moved the files and run the script again:
but with the same result
@007revad commented on GitHub (Oct 28, 2025):
It's normal to have 89 dx, rx and fx files. It's as if Synology decided it was easier to include db files for every expansion unit for all NAS models.
Every time you run the script does it say it's added the NVMe drives to ds1825+_m2d20_v7.db ?
The 2nd time you run it it should say the NVMe drives already exist in ds1825+_m2d20_v7.db
@kennydm00 commented on GitHub (Oct 28, 2025):
Yes it does, for every run it says that it added the drives. I already thought that it's weird
@kennydm00 commented on GitHub (Oct 28, 2025):
Ok it seems, that the neither the WD_BLACK nor the WD Red are added to the ds1825+_m2d20_v7.db file.
The ds1825+_m2d20_v7.db file contains only:
@kennydm00 commented on GitHub (Oct 30, 2025):
I have edited the ds1825+_m2d20_v7.db file manually and after running your script again I got:
and now it's working :)
@007revad commented on GitHub (Oct 31, 2025):
If I write a debug version of the script are you willing to restore
{"disk_compatibility_info": {}, "nas_model": "ds1825+"}in ds1825+_m2d20_v7.db and test the debug version so I can figure out why the script didn't edit ds1825+_m2d20_v7.db when you ran it.It might be next week as I'm busy at the moment.
@kennydm00 commented on GitHub (Oct 31, 2025):
Yes of course