I recently upgraded our NetXMS server (and agent) listed below:
netxms-agent:amd64 (6.0.1-1+bookworm, 6.2.3-1+bookworm)
netxms-server:amd64 (6.0.1-1+bookworm, 6.2.3-1+bookworm)
and later (due to this issue)
netxms-agent:amd64 (6.2.3-1+bookworm, 6.2.4-1+bookworm)
netxms-server:amd64 (6.2.3-1+bookworm, 6.2.4-1+bookworm).

I had two similar DCIs like this: origin: script, metric: Ping("1.1.1.1",1)

And the following script behind:

if ($2) {
cmd = "ping-suli";
} else {
cmd = "ping-voda";
}
println("Using: " .. cmd);
res = $node.executeAgentCommandWithOutput(cmd, $1);
if (res.length == 0) return null;
return res;
Both DCIs error with the following: Script (Ping) execution error: Error 14 in line 8: Function or operation argument is not an object

But if I use the execute script function with params: "1.1.1.1",1 to run the ping on the same node I get the expected result:

Using: ping-suli


*** FINISHED ***

Result: 25.2
This issue started after the first upgrade and persisted after the second.

Hi,

Not your script - 6.2 added a server configuration parameter Scripts.RestrictWriteAccess, enabled by default on new installations and on in-place upgrades. With it on, script-origin DCIs run under a read-only security context, and executeAgentCommandWithOutput() is one of the denied operations: https://netxms.org/documentation/adminguide/scripting.html#script-write-access-restrictions

Here's what's actually happening: the denied call does not raise an error. It returns null, the script keeps running, and it dies one line later where res.length hits that null - which is why the error points at line 8 and says "argument is not an object" instead of naming the restriction. In the Script Executor the same script runs under your user's rights, which include the control permission, so it works there and only there.

To confirm, enable debug tag nxsl.security at level 7 - the denial logs "Read-only script access denied" with the object name and id. Nothing appears at default levels.

Two ways out:

• Turn the restriction off: Server Configuration -> Scripts.RestrictWriteAccess -> 0. Takes effect immediately, no restart. It's a global switch though - it re-enables writes for every restricted script type, not just your DCI.
• Move the ping to the agent. Better fit here, since you're collecting a value rather than modifying anything. In nxagentd.conf, pointing at the same commands your ping-suli / ping-voda actions run:

ExternalMetric = PingSuli(*):["/path/to/ping-suli", "$1"]
ExternalMetric = PingVoda(*):["/path/to/ping-voda", "$1"]
Then two Agent-origin DCIs with metrics PingSuli(1.1.1.1) and PingVoda(1.1.1.1). No NXSL, so the restriction doesn't apply - and the if ($2) switch disappears, since you had two DCIs anyway.

I've opened https://github.com/netxms/netxms/issues/3619 on whether script-origin DCIs should be restricted at all - they're a data source, not an analysis script - and https://github.com/netxms/netxms/issues/3620 on the denial being invisible and surfacing as an unrelated error.

Thanks for the info, after reading the docs about Agent External Metrics I converted the actions to shell form metrics and now it works fine.

(Before I read the docs I tried the format you provided, but that had some issues which didn't trigger an alarm so I have no idea what was wrong with that.)