007revad
DSM 7.3 - works without major issues
I just wanted to state that i can confirm this script is still running on DSM 7.3 without any issues! After upgrade, the drive is showing as missing. After running script and rebooting, everything is back to normal 😄 Tested on DS920+
Thank you for testing that. Any issues, as far as You know, when using M.2 ssd as a storage pool?
The only issue i had is that the packages i installed (container manager, web station) on the NVME volume were not reachable, and after the update they got reinstalled on the wrong volume. This made it look like al my containers were gone. But after removing container manager and webstation and installing them on the nvme drive, everything worked without a problem.
That's exactly my situation, I've got Container Manager and ALL my containers on the NVME volume, Thank you for sharing your experience, you saved me a big headache.
I just wanted to state that i can confirm this script is still running on DSM 7.3 without any issues! After upgrade, the drive is showing as missing. After running script and rebooting, everything is back to normal 😄 Tested on DS920+
did you had the script as start-up script defined?
I haven't, so that's probably why it didnt work straight out of the box after the update.
~~Unfortunately, I'm having trouble with a DS1819+ that it's being recognized as a cache drive in the Storage Manager, and it also says "Not supported by the current DSM version." I've run the script several times and restarted the device several times. I use the drive in a storage pool with raid type "basic"- It is a: Samsung SSD 990 PRO 2TB I haven't used the --force option yet. Should I?~~
@MAngel666 i run the following as root: /volume4/homes/x/scripts/Synology_HDD_db-main/syno_hdd_db.sh -nr --autoupdate=3. Then, after a reboot, everything worked.
i have the force option enabled for a year now, without issues, but did not do the update to 7.3 yet
/volume1/scripts/Synology_HDD_db-main/syno_hdd_db.sh -nr -f --autoupdate=3
sorry I was on the wrong syno (have 2 of them) LOOOOOL. Everything works as expected!
Upgraded to 7.3 without any issues. Running the scheduled task at startup as mentioned here.
Running Docker and Mailstation plus from Volume2 (NVMe volume WD red) without issues.
DS923+ BTW.
I have read, that Synology now allows again thirdy party HDD since 7.3 , no more need for this tool?
https://nascompares.com/news/synology-reverse-the-hard-drive-policy-in-dsm-7-3-we-win/
I have read, that Synology now allows again thirdy party HDD since 7.3 , no more need for this tool?
https://nascompares.com/news/synology-reverse-the-hard-drive-policy-in-dsm-7-3-we-win/
Totally irrelevant. Pergo, you're referring to whether or not the Synology will accommodate drives that haven't been certified and labeled by Synology as compatible. The script on this github page is all about using M.2 drives for storage, rather than as cache.
My experience is similar - after updating DSM to 7.3, I had to run the script and reboot. Container manager (which had been installed on the volume created by the script initially) had been reinstalled to Volume 1 (hard drive) in the course of the DSM update. After the update, DSM invited me to "repair" container manager, which was of course futile. After "repairing," I uninstalled container manager and reinstalled to the drive created by the script, and all was well. Obviously, when uninstalling container manager, do NOT check the box that would uninstall your containers and content.
Hoping you all can clear up for me. I was on the fence about upgrading to the 1825 from my old 1817 due to the limitations on the drives but with the 7.3 change that seems like it has passed although I had planned to use the DB updater. My question is about using non Synology M.2 drives as cache in the 1825. I can't tell if that will work or not or if I will still need to use this tool or if there is an M.2 only tool assuming my Ironwolf drives work without attitude on 7.3?
Thanks all!!!!
@mswildma77
Yes, according to the latest version of this Synology page: https://kb.synology.com/en-us/DSM/tutorial/Drive_compatibility_policies, you'd still need this script.
That page says Plus Series models cannot create a volume or cache if the NVMe drives is not on the compatibility list:
Thanks for that. Good to know not really anything has changed yet and I will still save a ton of money buying Samsung SSDs that are better than the Synology ones and still have to work around to use them. Good times....
BTW: Where should I actually save the script so that it "survives" an update? I noticed that the "/scripts" directory I created for it was removed during the update.
I happen to have received my 1825+ today with 8x 24TB Seagates. I was going to use your great script but ended up not needing to use it. The disks got recognized. I did have a Synology drive laying around and did do the updates and first install with that and 1 seagate in slot 2. It did however give me the option right away to use the seagate for a 2 disk array. After initial updates and wizard i shut it down (without creating volumes). I removed the Synology drive and installed the 7 other Seagates. Created the volume and it's now doing its thing. I used the Synology drive to give it the best chance of working, but in hindsight i think it would have worked with just the Seagates
Maybe I’m the stupid one, but I didn’t think the script had anything to do with enabling the use of uncertified hard drives. I use it to use M2 drives as storage, when SYNOLOGY only intends them to be used as a cache. If the script can be used to allow running of uncertified hard drives, that’s news to me.
BTW: Where should I actually save the script so that it "survives" an update? I noticed that the "/scripts" directory I created for it was removed during the update.
—-
I store the script somewhere in the Homes file structure. Because Synology never messes with that structure when updating.
@MAngel666 The script should be in a shared folder that is on a HDD or 2.5 inch SSD so it survives DSM updates. And NOT on an NVMe volume as it may not be available until after the script has run.
Or you could create a root level /opt folder and store the script in there. DSM updates normally do not delete anything that is in /opt
I like to keep my scheduled scripts in /var/services/homes/Dave/.scripts/. Then I can schedule /var/services/homes/Dave/.scripts/<script-name>.sh instead of /volume1/homes/home/Dave/.scripts/<script-name>.sh. This way if I ever move the homes shared folder to a different volume the schedule still works.
@KorperICT Yes, with DSM 7.3 the initial setup would have worked with just the Seagates. But with DSM 7.2.2 you would have needed the Synology drives, or to use telnet to run a couple of commands.
If you decide you want an NVMe cache or volume with non-Synology NVMe drives you will need syno_hdd_db
@principalarchivist Synology_HDD_db was originally written for models that have had annoying warnings about unverified drives since DSM 7.0.1. These warnings used to only appear on business and enterprise models, but you could still use any drive.
Since DSM 7.2 was released the script also allows you to use non-Synology NVMe drives as a volume, and other things.
If the script can be used to allow running of uncertified hard drives, that’s news to me.
Allowing the use of uncertified hard drives (in models and DSM versions with restrictions) is just a bonus of how the script does what it does.
@MAngel666 The script should be in a shared folder that is on a HDD or 2.5 inch SSD so it survives DSM updates. And NOT on an NVMe volume as it may not be available until after the script has run.
Or you could create a root level /opt folder and store the script in there. DSM updates normally do not delete anything that is in /opt
I place it in /opt/own_scripts. It seems to me to be a more suitable place for global scripts. Thank you.
without any issues here, scheduled task for the script at startup. DS923+, nmve pool 4tb
The only issue i had is that the packages i installed (container manager, web station) on the NVME volume were not reachable, and after the update they got reinstalled on the wrong volume. This made it look like al my containers were gone. But after removing container manager and webstation and installing them on the nvme drive, everything worked without a problem.
same problem here... my m.2 is volume11 and after update the most apps are still there but: 22) /volume1 Antivirus by McAfee 23) /volume1 Log Center 24) /volume1 Node.js v20 25) /volume1 Snapshot Replication 26) /volume1 Synology Application Service 27) /volume1 Synology Drive Server 28) /volume1 Synology Photos 29) /volume1 Universal Viewer
It's possible that this is because the HDD script was deleted during the update to 7.3 (it was located in /scripts). If it's copied to a location that isn't deleted (e.g., /opt/...) and started via the Task Scheduler during startup and shutdown, as described in the documentation, then the problem it's probably not there. Can anyone confirm this?
My HDD script was NOT deleted during the update to 7.3, I have it set to run at every bootup, and I had the same problem. I believe it's because the reboot from the update doesn't run the script for some reason, or perhaps runs it unsuccessfully. Following my update, I got notifications that DSM couldn't find Volume 2 or somesuch. I wish I had written down the exact wording, but I didn't. In Storage Manager, the M.2 drive was a red box. I found that I had to reboot after the update to get DSM to recognize the M.2 drive as a storage device. YMMV.
I have always noticed that on the more major build updates like 7.2.x to 7.3 that first reboot runs a more in depth startup something like how Microsoft after major updates will run through the startup questionnaire all over again even though you have answered it a million times and have said you don't want Edge to be your default browser....;). Maybe that type of initial startup skips some of those scheduled tasks or mount points? Mind you I haven't gotten my 1825+ yet so I am just speculating. I was also thinking maybe trying to keep the script on a permanently installed old thumb drive stuck in a USB port, maybe that will work better and not risk getting wiped during an update plus always be outside of any RAID volume. Lord knows I have a bazillion useless USB2 slow thumbdrives sitting around collecting dust.
Same here: No problems after the update with the NVMEs on a DS1522+, script task running on bootup.
But I needed to reconnect the UPS, that was not recognized after first bootup...
Thank you for this great script!
One additional info: DSM 7.3 will show the status of your drives as healthy, but synology migration assistant will not recognize 3rd party drives as healthy. It will prevent migration with a notice that you should check the abnormal storage status (i waited out the verification of the pool as I initially assumed it was caused by that).
I then ran your script (thanks!) and now the migration is running.
