On real Synology hardware, automatic updates are good practice. On a virtualised install they are the number one cause of a NAS that never boots again. Here is the discipline that replaces them.
Every other Synology guide tells you to keep DSM updated, and on hardware they are right. This install plays by different rules, because it boots through a bootloader emulating a specific model-and-DSM pairing. Change the DSM side carelessly and the emulation fails at boot — completely. This guide covers the setting, the safe manual routine, and the rescue if it already happened.
👆 The lab update posture — the opposite of the set-and-forget habit that is correct on real Synology hardware (settings recreated for illustration)
On a real Synology box, DSM updates are routine and safe enough that automatic updates are good practice. A virtualised install is different: it boots because a community bootloader emulates a specific Synology model and DSM pairing. A new DSM version can change drivers, boot behaviour or model checks — and the emulation that worked yesterday may not boot tomorrow. The failure mode is total: the NAS simply does not come up, usually right after an update you did not even choose. This is not a flaw in DSM; it is the price of running it somewhere it was never meant to run.
Open Control Panel → Update & Restore and set DSM updates to notify only — never automatic. Do it during the initial setup, before the lab holds anything, because the setup wizard cheerfully offers the automatic option and it is wrong for this build. Package updates inside DSM are a separate, milder question — still read what a package update changes, but it is DSM version jumps that carry the boot risk. Also export a DSM configuration backup (.dss file) after your initial setup; it weighs nothing and rebuilds your settings on a fresh install in minutes.
Sometimes you will want the newer DSM — to learn it, or because a tutorial needs it. Then update like a technician, in this order:
.pat, never the one-click newest.Do not start reinstalling over the top — that is how a recoverable lab becomes lost data. If you have a snapshot, reverting it is the whole fix. Without one, the usual rescue is to rebuild the bootloader side (a bootloader version matched to the DSM now on the disks) while leaving the data disks untouched, since DSM keeps its system on the disks and a correct bootloader can often start it again. Prevention is unglamorous and total: notify-only updates, snapshots before changes, and a config backup. Labs die from skipped snapshots, not from bad luck.
Watch the full installation video first — then set the update behaviour exactly as this guide describes.
▶️ Watch Full VideoA real box updates as a matched hardware-and-software product. The virtual install depends on a community bootloader emulating a specific model for a specific DSM range; a new DSM can change what it checks at boot, and the NAS then fails to start at all.
Much less so — the boot risk lives in DSM version changes. Still, read package update notes, and keep the same habit: snapshot before big changes so any surprise is reversible.
Usually not. The data disks hold the DSM system and your files; reverting a pre-update snapshot fixes it outright, and without one, matching the bootloader to the DSM version now on the disks often boots it again. Do not reinstall over the disks before trying those.