Synology’s NAS lineup has long been the preferred choice amongst consumers looking to buy a new NAS drive. However, Synology's 2025-Plus Series NAS models now come with a catch — your drives need to be “compatible,” or DSM starts locking you out of core features like the ability to use your brand-new NAS. And as of today, the only drives on that list are Synology-branded drives. It’s frustrating, unnecessary, and very un-Synology. But here’s the good news. There are ways you can bypass it. In fact, there are two ways. Here's how.

The problem with Synology’s new policy

It's all about the lock-in

With the 2025 generation of NAS models, Synology has officially crossed into locked-down territory. No more plug-and-play flexibility. Unless your hard drives are on a short list of approved models, mostly Synology’s own rather expensive models, DSM throws up warning messages and disables key features like the ability to install DSM and get started with using your NAS.

Moreover, unsupported drives do not have access to drive health stats and can't be used to create new storage pools. But the worst part is that Synology will refuse technical support for using incompatible drives. It’s not about performance or reliability — it’s about control. The company claims that technical support claims arising out of incompatible hard drives are not worth the hassle, so Synology wants to turn your NAS into a walled garden. The same company that once encouraged customization now wants to sell you overpriced, rebranded drives or penalize you for going elsewhere. If that sounds harsh, it is, and I say that as someone who has invested thousands of dollars in Synology hardware.

The simple fix

GitHub to the rescue

The easiest and cleanest way around Synology's move is a community script called Synology_HDD_db. This tool modifies the internal hard drive compatibility database on your NAS and tricks DSM into believing your drives are certified.

You don’t need to hack firmware or modify system partitions. Just SSH into your NAS, run the script, and let it scan your connected drives. It then adds them to DSM’s internal compatibility list. After a reboot, DSM stops complaining. In fact, you can even get full SMART monitoring back and create storage pools using these unsupported drives. Everything works quietly and cleanly, like it should have from the start.

I used this on a DS925+, and it worked flawlessly. In fact, the script is astonishingly easy to get up and running and does most of the work for you. You've got the option to run the script over SSH, but I recommend setting it up via the Task Scheduler built into DSM. This will let the operating system automatically run the script every time it reboots. Using a combination of Synology-branded hard drives and incompatible drives, I was able to easily add the unsupported disks to the database, and DSM stopped throwing up the array of warnings after a quick reboot. Moreover, since the script backs up the original database, there’s no risk if you ever want to roll it back. It’s about fifteen minutes of setup, tops — and it restores the functionality Synology tried to take away.

Bypassing restrictions at install

This community script lets you install DSM with unsupported drives

But what if you hit drive restrictions before DSM is even installed? That’s where a second community tool comes in, and it takes things a step further. Synology's latest NAS drive, the DS925+ won't even let you install the company's NAS-oriented operating system on an unsupported drive. This script lets you install DSM on newer Synology models like the DS925+ even when using unsupported drives. And this time, it’s aimed at users who run into compatibility issues during the initial install process, not just afterward in DSM.

This method is a little more hands-on. The Python script logs into the NAS over Telnet and patches the installation process to proceed with the unsupported drive. Once DSM is installed on the drive, you can then use the first script to add your unsupported drive to the compatibility list and continue using the NAS as normal.

Alternatively, you can log in to your NAS via telnet using this command:

http://ip-address of NAS:5000/webman/start_telnet.cgi

Once logged in via root, input the following command:

printf '#!/bin/sh\nexit 0\n' >"/usr/syno/share/get_hcl_invalid_disks.sh"

Refreshing the web installation page will now let you proceed with the incompatible hard disk.

I didn’t need this method myself, but going through the documentation, the process is straightforward and should work as normal. Additionally, community members have validated that the method works as expected. For anyone setting up a new NAS and getting stuck at the installation stage due to drive restrictions, this script is a lifesaver.

Between this and the HDD database patch, users now have two excellent options whether they’re setting up a new NAS or fixing one that’s already running. Of course, it goes without saying that dabbling in system-level scripts comes with risks, including the fact that Synology will no longer offer technical support. Nor does it get around the fact that you shouldn't have to make system-level tweaks to bring back basic functionality. While Synology's operating system has long been the gold standard and a major reason why I continue to recommend the NAS drives, there are plenty of alternatives from Ugreen, QNAP, and more that can do the job without jumping through loopholes. Additionally, it has never been easier to build your own powerful NAS.

Reclaiming what we already own.

These scripts aren’t about breaking rules — they’re about restoring freedom. Synology is taking away choice under the pretense of support and reliability. However, the real goal seems obvious: to sell more of their branded hardware, even when identical third-party drives perform just as well or better.

This kind of lock-in is a slippery slope. First, it’s drives. Next could be RAM, SSD cache, or even expansion cards. It’s not hard to imagine DSM becoming increasingly locked down unless you play entirely within Synology’s closed ecosystem. Community-driven fixes like these are a reminder that hardware ownership should still mean something. We paid for the NAS. We paid for the drives. We should get to decide how they work together.