[GH-ISSUE #343] Expansion units not verified after scrub #830

Closed
opened 2026-03-12 17:21:03 +03:00 by kerem · 2 comments
Owner

Originally created by @AndrewLuebke on GitHub (Aug 16, 2024).
Original GitHub issue: https://github.com/007revad/Synology_HDD_db/issues/343

I just got a DS1823xs+ and after running Synology_HDD_db and getting rid of the unverified drives I ran a scrub. After the scrub the two expansion units showed all the drives as unverified. Ran Synology_HDD_db again and it said Re-enabled support disk compatibility. I think the scrub turned it off, but I can't be sure unless I run the script again, but it takes about 3 days. Is there any reason that it would disable compatibility on just the expansion units?

I do see that the system automatically updated the drive database yesterday. Still not sure why that would only affect the expansion units and auto updates should have been disabled by the script anyway.

Script output:
Synology_HDD_db v3.5.98
DS1823xs+ DSM 7.2.1-69057-5
StorageManager 1.0.0-0017

ds1823xs+_host_v7 version 8029

Using options: -nr
Running from: /volume1/scripts/Synology_HDD_db/syno_hdd_db.sh

HDD/SSD models found: 3
WD121KFBX-68EF5N0,83.00A83,11999 GB
WD141KFGX-68FH9N0,83.00A83,14000 GB
WD181KFGX-68AFPN0,83.00A83,17999 GB

M.2 drive models found: 1
Samsung SSD 990 PRO 2TB,4B2QJXD7,2000 GB

No M.2 PCIe cards found

Expansion Unit models found: 1
DX517

Added WD121KFBX-68EF5N0 to ds1823xs+_host_v7.db
Edited unverified drives in ds1823xs+_host_v7.db
WD121KFBX-68EF5N0 already exists in dx517_v7.db
Added WD141KFGX-68FH9N0 to ds1823xs+_host_v7.db
WD141KFGX-68FH9N0 already exists in dx517_v7.db
Added WD181KFGX-68AFPN0 to ds1823xs+_host_v7.db
WD181KFGX-68AFPN0 already exists in dx517_v7.db
Added Samsung SSD 990 PRO 2TB to ds1823xs+_host_v7.db

Re-enabled support disk compatibility.

Support memory compatibility already disabled.

Max memory already set to 64 GB.

NVMe support already enabled.

M.2 volume support already enabled.

Disabled drive db auto updates.

DSM successfully checked disk compatibility.

You may need to reboot the Synology to see the changes.

Originally created by @AndrewLuebke on GitHub (Aug 16, 2024). Original GitHub issue: https://github.com/007revad/Synology_HDD_db/issues/343 I just got a DS1823xs+ and after running Synology_HDD_db and getting rid of the unverified drives I ran a scrub. After the scrub the two expansion units showed all the drives as unverified. Ran Synology_HDD_db again and it said Re-enabled support disk compatibility. I think the scrub turned it off, but I can't be sure unless I run the script again, but it takes about 3 days. Is there any reason that it would disable compatibility on just the expansion units? I do see that the system automatically updated the drive database yesterday. Still not sure why that would only affect the expansion units and auto updates should have been disabled by the script anyway. Script output: Synology_HDD_db v3.5.98 DS1823xs+ DSM 7.2.1-69057-5 StorageManager 1.0.0-0017 ds1823xs+_host_v7 version 8029 Using options: -nr Running from: /volume1/scripts/Synology_HDD_db/syno_hdd_db.sh HDD/SSD models found: 3 WD121KFBX-68EF5N0,83.00A83,11999 GB WD141KFGX-68FH9N0,83.00A83,14000 GB WD181KFGX-68AFPN0,83.00A83,17999 GB M.2 drive models found: 1 Samsung SSD 990 PRO 2TB,4B2QJXD7,2000 GB No M.2 PCIe cards found Expansion Unit models found: 1 DX517 Added WD121KFBX-68EF5N0 to ds1823xs+_host_v7.db Edited unverified drives in ds1823xs+_host_v7.db WD121KFBX-68EF5N0 already exists in dx517_v7.db Added WD141KFGX-68FH9N0 to ds1823xs+_host_v7.db WD141KFGX-68FH9N0 already exists in dx517_v7.db Added WD181KFGX-68AFPN0 to ds1823xs+_host_v7.db WD181KFGX-68AFPN0 already exists in dx517_v7.db Added Samsung SSD 990 PRO 2TB to ds1823xs+_host_v7.db Re-enabled support disk compatibility. Support memory compatibility already disabled. Max memory already set to 64 GB. NVMe support already enabled. M.2 volume support already enabled. Disabled drive db auto updates. DSM successfully checked disk compatibility. You may need to reboot the Synology to see the changes.
kerem closed this issue 2026-03-12 17:21:09 +03:00
Author
Owner

@007revad commented on GitHub (Aug 18, 2024):

It sounds like the system automatically updated the drive database before starting the data scrub.

Running syno_hdd_db with the -n option should have prevented DSM from being able to update the drive database. Maybe a data scrub uses a hard coded URL.

<!-- gh-comment-id:2295162493 --> @007revad commented on GitHub (Aug 18, 2024): It sounds like the system automatically updated the drive database before starting the data scrub. Running syno_hdd_db with the -n option should have prevented DSM from being able to update the drive database. Maybe a data scrub uses a hard coded URL.
Author
Owner

@007revad commented on GitHub (Aug 18, 2024):

Is there any reason that it would disable compatibility on just the expansion units?

Maybe the data scan was scanning the expansion unit drives first.

I've seen cases where, after a drive database update, just 1 drive changes to unsupported. And then another drive, and later another drive until eventually all unsupported drives are shown as unsupported.

<!-- gh-comment-id:2295163519 --> @007revad commented on GitHub (Aug 18, 2024): > Is there any reason that it would disable compatibility on just the expansion units? Maybe the data scan was scanning the expansion unit drives first. I've seen cases where, after a drive database update, just 1 drive changes to unsupported. And then another drive, and later another drive until eventually all unsupported drives are shown as unsupported.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/Synology_HDD_db#830
No description provided.