Monitor NAS via SNMP

A NAS is the one box on the network you notice only when it's too late — the volume that filled overnight, the disk that dropped out of the array while nobody was looking. SNMP NAS monitoring turns that around: it lets you poll the appliance for free space, CPU, memory, and uptime on a schedule, so a filling volume shows up as a trend line days before it becomes a 2 a.m. incident. Both Synology and QNAP ship an SNMP agent in their firmware, and most of what you'll read comes from a standard, cross-vendor MIB. Here's what to enable, which OIDs to watch, and why polling from outside the box matters.

SNMP support on NAS

Practically every mainstream NAS speaks SNMP. On Synology, DSM includes an SNMP service; on QNAP, QTS does the same. In both cases the agent is built into the operating system — you're enabling a feature, not installing anything — and both support SNMPv1, SNMPv2c, and SNMPv3.

For a NAS sitting on your LAN, SNMPv2c with a read-only community is the common, sensible default. It's simple and every collector understands it. The usual caveat applies: a v2c community crosses the wire in clear text, so if the appliance is reachable from anywhere you don't trust, enable SNMPv3 with authentication and privacy instead. Both DSM and QTS expose a v3 user with SHA/AES options in the same settings panel where you toggle the service.

The reason SNMP is such a good fit for a NAS is that the metrics you care about are exactly the ones SNMP was built to report: how full is each volume, how hard is the CPU working, how much RAM is left, has it rebooted unexpectedly. You get numbers you can trend and alert on without ever mounting a share or opening an SSH session. That's the whole appeal — cheap, read-only visibility into a device whose main job is to quietly not lose your data.

There's a second reason it's worth doing properly. A NAS tends to accumulate responsibility: it starts as file storage, then it's hosting backups, then a few containers, then a media library, and suddenly a full volume takes down more than you expected. Polling it over SNMP gives you the early-warning trend — the slope of a volume filling up is far more useful than the single number you'd glance at in the web UI once a month. Catch the slope and you order disks on your schedule instead of the volume's.

What you can monitor on NAS

The high-value readings — storage, CPU, memory, uptime — all come from the standard Host Resources MIB (RFC 2790), which means the same OIDs work whether the badge on the front says Synology or QNAP. Storage is a table: hrStorageDescr names each volume, hrStorageSize gives its size in allocation units, and hrStorageUsed gives what's consumed. To convert units to bytes, multiply by hrStorageAllocationUnits. Percent-full is then just used divided by size — the single most useful number a NAS can hand you.

RAM and swap show up as their own rows in that same storage table, named in hrStorageDescr — so a single walk of the tree inventories physical memory, swap, and every mounted volume together. What the Host Resources MIB does not cover is vendor-specific health: drive temperature, fan RPM, array/RAID status, per-disk SMART state. Those live in each vendor's own MIB — a Synology NAS MIB and a QNAP NAS MIB respectively — and the numeric OIDs differ between them and across firmware. Load the appropriate vendor MIB and walk it on your own unit rather than trusting a copied number. For the storage numbers themselves, disk space usage and storage capacity own the deep dive, and CPU utilization covers hrProcessorLoad in full.

Where each NAS reading lives, at a glance:

• Volume size, used, percent-full — Host Resources MIB storage table, identical on Synology and QNAP.
• RAM and swap — extra rows in that same storage table, named in hrStorageDescr.
• CPU load and uptime — Host Resources MIB, standard.
• Drive temperature, fan RPM, RAID/array health, SMART — vendor NAS MIB only; walk it on your own model.

Enabling SNMP — steps

The exact menu differs by vendor, but the shape is the same. For a read-only v2c agent:

1. Open the SNMP settings. On Synology: Control Panel → Terminal & SNMP → SNMP. On QNAP: Control Panel → Network & File Services → SNMP.
2. Enable the SNMP service and choose the version — SNMPv2c for a trusted LAN, SNMPv3 if the path is exposed.
3. Set a read-only community string — a long, random value, never left as public.
4. Restrict access to your poller's subnet where the firmware allows it, and confirm the appliance firewall isn't blocking UDP 161.
5. Verify from a workstation by walking the storage table:

   snmpwalk -v2c -c <community> 10.0.0.10 1.3.6.1.2.1.25.2.3.1
   

   Then read a single value, for example uptime:

   snmpget -v2c -c <community> 10.0.0.10 1.3.6.1.2.1.25.1.1.0
   

A couple of things save grief later. Treat the community as a credential and scope it tightly. If you want machine-wide CPU rather than per-core, walk 1.3.6.1.2.1.25.3.3.1.2 and average the rows. And decide your alert thresholds up front — a volume alert at, say, 85% full gives you room to act. The wider setup section covers the collector side and hardening.

Monitoring it externally

Getting the agent answering is only half of it. The half that decides whether you actually hear about trouble is where you poll from. A collector running as a container on the very same NAS — a tempting shortcut — vanishes the instant that NAS does, so the one failure it exists to catch is the one it can't report. Same story for a monitor sharing the appliance's power feed or switch.

That's the argument for double durability: watch the device from somewhere it doesn't depend on. ostr.io Monitoring polls your NAS's SNMP agent from outside your network — zero-setup SaaS, nothing extra installed on the appliance — and fires real-time email and SMS alerts when a volume crosses a fill threshold or the box stops responding. Because the check is independent and external, a full outage still reaches you. Point it at your public monitoring endpoint and you've got a watcher the NAS can't accidentally take down with itself.