Articles reference, NFS, updated 2026-10-02

NFS file: a backup on an NFS server

An NFS file sensor asks an NFSv4 server whether one file exists, and if so how big it is and how old. It is for checking that something landed on a NAS or file server: last night's backup, a router's config export, a nightly report. Nothing is mounted and nothing is read from the file. The probe walks the path from the server's root and gets the file's size and modification time back in a single request.

Version 4.0 is used where the server allows it, and 4.1 or 4.2 where it does not. Older servers that only speak NFSv3 are not supported by this sensor: mount the export on the probe host and use a file sensor instead.

Before you start

  • Put the probe's address on the export's list of allowed clients, read-only. NFS of this kind has no password. The server trusts the address the request comes from, so that list is the whole of the access control. Use the probe's own LAN address, not the address it reaches the internet from.
  • Allow connections from ordinary ports. Linux NFS servers, and the NAS products built on Linux, only answer requests from a source port below 1024 unless told otherwise. The probe does not run as root, so it cannot use one. On a Linux server add insecure to the export's options. On a Synology, edit the NFS rule for the shared folder and tick Allow connections from non-privileged ports.
  • NFSv4 must be enabled, and TCP port 2049 open from the probe to the server. Nothing else is needed: no portmapper and no separate mount service.
  • Exports that require Kerberos are not for this sensor. Mount them on the probe host, where the operating system holds the keys, and use a file sensor.
  • No credential is needed. Who the probe says it is comes from the User ID and Group ID settings.

Setting it up

SettingWhat to put
TargetLeave the target override empty and the sensor asks the device's own address, which is right when the sensor sits on the NAS or file server.
File pathThe path from the server's root, as a client would mount it, then on to the file. On a Synology that starts with the volume, such as /volume1/backups/edge1.cfg. A dated file can be named with tokens, filled in on UK time: /volume1/backups/edge1-{{yesterday}}.cfg. See Dated files below before using {{isodate}}.
PortLeave empty for 2049.
User ID and Group IDWho the probe says it is. 0 is root, which most exports map to an anonymous user, so the folders on the way to the file need to be readable by everyone. If they are not, set the IDs of an account on the server that may read them.
IntervalA file that changes once a day does not need checking every minute. 15 minutes to an hour suits a nightly backup. An NFS file sensor is 2 credits a reading.
Failures before a probe calls it down1 is reasonable on a long interval, since a missing backup is not going to reappear on the next poll. Keep 3 on a short one.

What it reads

SlotReading
SV01 File sizeBytes.
SV02 File ageSeconds since the file was last modified, measured against the probe's clock, so a server whose clock is wrong shows a wrong age.
SV03 Lookup timeMilliseconds for the lookup, including any session set-up.
SD01 ModifiedThe modification time, in UTC.
SD02 Kindfile or directory.
SD03 NFS version4.0, 4.1 or 4.2, whichever the server accepted.
SD04 Source portreserved or unreserved: whether the probe managed a port below 1024. Normally unreserved.

The sensor is OK while the file is found, whatever its age, until rules say otherwise. A file that is there but three weeks old is still found, so for a backup the rules below are what make the sensor worth having.

A nightly backup

  1. In Rules, add SV02 greater than 93600 gives CRIT. 93600 seconds is 26 hours: a day plus a margin for a backup that runs a little late.
  2. Add SV01 less than a sensible minimum, such as 1000, gives CRIT. A backup job that ran but wrote an empty or truncated file still updates the age, and only the size catches it.

A file that is missing altogether fills no slot, so these rules do not judge it: it is a failed reading, and the failure threshold turns it into CRIT.

Dated files

Where a device writes a new file each day with the date in its name, the path can follow it with {{isodate}} (today) or {{yesterday}}. Be careful with today. From midnight until the backup runs, today's file does not exist yet, so a sensor looking for it fails every night, and an alarm at ten past midnight soon gets ignored. Look for yesterday's file instead, and a missing one means a backup really did not run.

Where the names cannot be predicted, because they carry a time or a serial number, point the sensor at the folder instead. A folder's modification time changes whenever a file is added to it or removed from it, so the folder's File age is the time since anything last landed there, and the same 26 hour rule works on it. Something deleted from the folder counts too, so this suits a folder that only ever receives.

When it fails

ErrorWhat it means
No error classThe file is not there. Where a folder on the way is missing, the message names it, which usually means the path does not start where the server's root does: check the volume and the exported folder's name. A server that speaks only NFSv3 fails here too, and the message gives the versions it does speak.
AUTHThe server refused the probe. If the message says the address is not on the export's client list, add it. Otherwise the export needs to allow non-privileged ports, as above, or the User ID may not read a folder on the way, or the export wants Kerberos.
REFUSEDNothing is listening on port 2049, or a firewall rejected the connection. Check NFSv4 is enabled.
CONNECTTIMEOUTNo connection within the connect timeout: the server is off or unreachable, or a firewall is dropping the traffic.
RESPONSETIMEOUTConnected, but the server did not answer in time.
DNSThe hostname could not be looked up on the probe.