Hello,
First of all, thank you for maintaining this excellent project.
I encountered an issue after upgrading to syno_hdd_db.sh v3.6.132 on my DS725+ running DSM 7.4-90075.
Environment
Problem
After upgrading to v3.6.132, I executed:
The script correctly detected my drives and reported that they already existed in the compatibility database:
SSD 870 EVO 4TB (SVT03B6Q) already exists in ds725+_host_v7.db
WD Red SN700 4000GB (11C120WD) already exists in ds725+_host_v7.db
However, during the compatibility refresh, the following errors appeared:
json_object_from_file: error opening file /run/synostorage/disks/sata1/compatibility_action: No such file or directory
json_object_from_file: error opening file /run/synostorage/disks/sata2/compatibility_action: No such file or directory
json_object_from_file: error opening file /run/synostorage/disks/nvme0n1/compatibility_action: No such file or directory
json_object_from_file: error opening file /run/synostorage/disks/nvme1n1/compatibility_action: No such file or directory
Despite these errors, the script finished with:
DSM successfully checked disk compatibility.
Unfortunately, DSM still marked both drives as "At Risk" instead of showing them as supported.
Resolution
I restored the original compatibility database first:
./syno_hdd_db.sh --restore
After the restore completed successfully, I immediately executed:
This time, instead of reporting:
already exists in ds725+_host_v7.db
the script recreated the entries:
Added SSD 870 EVO 4TB (SVT03B6Q) to ds725+_host_v7.db
Added WD Red SN700 4000GB (11C120WD) to ds725+_host_v7.db
The json_object_from_file errors disappeared completely.
DSM immediately updated the compatibility status and both drives are now displayed as Healthy / Supported (green).
Observations
It appears that an existing compatibility database (possibly modified by a previous version of the script) was left in a state that caused the compatibility refresh to fail after upgrading to v3.6.132.
Running --restore before applying the modifications again completely resolved the issue.
Suggestion
It might be worth checking whether the script can detect this situation automatically.
If the compatibility database was previously modified by an older version of the script, perhaps the script could:
-
detect an existing modified database,
-
offer to restore the original backup before patching,
-
or at least display a hint suggesting the use of --restore when these json_object_from_file errors occur.
This could prevent users from ending up with drives incorrectly shown as "At Risk" after upgrading the script.
Additional Information
After performing the restore and rerunning the script:
-
No reboot was required.
-
The compatibility status changed immediately.
-
Both SATA and NVMe drives became fully supported again.
-
The issue has not reoccurred after using the restored database.
I have attached screenshots showing:
-
The original json_object_from_file errors.
-
The successful execution after --restore.
-
DSM showing both drives as healthy afterward.
Hopefully this information helps. If any additional logs or testing would be useful, I'd be happy to provide them.
Thank you again for maintaining this project!
Hello,
First of all, thank you for maintaining this excellent project.
I encountered an issue after upgrading to syno_hdd_db.sh v3.6.132 on my DS725+ running DSM 7.4-90075.
Environment
Model: DS725+
DSM: 7.4-90075
Storage Manager: 1.1.0-2018
Script version: v3.6.132
Script location: USB drive (
/volumeUSB1/usbshare/STORAGE/Synology-HDD-DB/)Drives:
Samsung 870 EVO 4TB (SATA SSD) x2
WD Red SN700 4TB (NVMe) x2
Problem
After upgrading to v3.6.132, I executed:
The script correctly detected my drives and reported that they already existed in the compatibility database:
However, during the compatibility refresh, the following errors appeared:
Despite these errors, the script finished with:
Unfortunately, DSM still marked both drives as "At Risk" instead of showing them as supported.
Resolution
I restored the original compatibility database first:
After the restore completed successfully, I immediately executed:
This time, instead of reporting:
the script recreated the entries:
The
json_object_from_fileerrors disappeared completely.DSM immediately updated the compatibility status and both drives are now displayed as Healthy / Supported (green).
Observations
It appears that an existing compatibility database (possibly modified by a previous version of the script) was left in a state that caused the compatibility refresh to fail after upgrading to v3.6.132.
Running
--restorebefore applying the modifications again completely resolved the issue.Suggestion
It might be worth checking whether the script can detect this situation automatically.
If the compatibility database was previously modified by an older version of the script, perhaps the script could:
detect an existing modified database,
offer to restore the original backup before patching,
or at least display a hint suggesting the use of
--restorewhen thesejson_object_from_fileerrors occur.This could prevent users from ending up with drives incorrectly shown as "At Risk" after upgrading the script.
Additional Information
After performing the restore and rerunning the script:
No reboot was required.
The compatibility status changed immediately.
Both SATA and NVMe drives became fully supported again.
The issue has not reoccurred after using the restored database.
I have attached screenshots showing:
The original
json_object_from_fileerrors.The successful execution after
--restore.DSM showing both drives as healthy afterward.
Hopefully this information helps. If any additional logs or testing would be useful, I'd be happy to provide them.
Thank you again for maintaining this project!