The most common way a virtual NAS dies is not a crash or a disk failure. It dies politely, overnight, by updating itself. This page sets the discipline that prevents that — and the rescue order for the day it happens anyway.
Real QNAP hardware and a virtualised QTS sit in opposite worlds when a firmware update arrives. On hardware, the update was built and tested for exactly that box. In a VM, the new QTS version may expect hardware behaviour your virtual machine does not present, and the first symptom is a NAS that never finishes booting. Everything on this page follows from that one fact: updates here are deliberate projects with a way back, never background events.
👆 The six-step checklist for any deliberate update on a virtual QTS — skip a step and the update owns you (panel recreated for illustration)
A QTS update can change drivers, boot behaviour and hardware checks. On a genuine QNAP those changes are tested against the exact machine in front of you. On a virtual install, your emulated hardware is an approximation — close enough to run today's version, not guaranteed to satisfy tomorrow's. Add that community-style images are matched to specific QTS versions, and the picture is complete: an update is effectively a small migration, and migrations get planned, not clicked.
The correct setting is made during the setup wizard and checked ever after: notify me about new firmware, never install it automatically. If your install already updates itself, change that today, before it chooses a night for you. A notification costs you nothing — you learn a version exists. The decision about when, and whether at all, stays where it belongs: with you, on a day when you have time to test.
Before anything else in an update, export the QTS system configuration — users, shares, permissions and settings — and save the file off the NAS. If the worst happens and you rebuild, this small file turns a weekend of re-creating users and shares into an import. It takes two minutes, it weighs nothing, and skipping it is the step every rebuild story regrets out loud.
With the configuration exported, shut the NAS down cleanly and take a VM snapshot. Now install the update manually, reboot, and test like you mean it: log in, open your shares, start your apps, copy a file in and out. Only when all of that passes do you delete the snapshot and call the update done. If anything fails, the snapshot is your time machine — power off, revert, and your NAS is back on the old version, untouched.
Stay calm and work the order. First: revert the VM snapshot if you took one — this is the moment it exists for. Second: if there is no snapshot, do not keep rebooting and hoping; check whether the community route for your install has a known pairing between the image and the new QTS version. Third: if you must rebuild, your data disks and the exported configuration are the recovery — rebuild the system disk, reattach the data, import the settings. The lesson to carry forward is the checklist above, not the panic.
Pin this above the host: on a virtual QTS, the newest firmware is a stranger until your snapshot says otherwise. Update a few times a year, deliberately, for security fixes you have actually read about — not every time a badge appears. Real hardware gets the opposite advice, and that contrast is the whole point: the update button is only boring when the platform underneath it is the one the update was built for.
The video shows the install this discipline protects — watch it, then set your update rule before your first reboot.
▶️ Watch Full VideoYes — deliberately, a few times a year, for fixes you have read about. Export the configuration, shut down cleanly, snapshot the VM, update by hand, test everything, then delete the snapshot. What you must never do is let it install automatically, because a version pairing problem shows up as a NAS that will not boot.
Usually not. Your data lives on the data disks, separate from the system. If you took a VM snapshot, revert it. If not, the recovery route is to rebuild the system side — with a version pairing known to work — and reattach the data disks, then import your exported configuration if you have one.
They matter, and on real QNAP hardware you should install them promptly. On a virtual lab the risk balance flips: an untested update can take the whole NAS down at boot. The answer is not to skip security fixes — it is to install them within days, by hand, with a snapshot first, instead of automatically at 3 a.m.