NetXMS Support Forum

Hi,

"Driver Error" is as generic as it looks - it only means the driver loaded, your config parsed, and the POST to the webhook came back with something other than HTTP 200 and a body of exactly "ok". A transport failure, a non-200 code and an error string from Slack all end up as that same message. (If the driver itself were missing or unloadable you'd get "Driver not initialized" instead, so that part is fine.)

To get the actual error, in Tools -> Server Debug Console:

debug ncd.slack 7
debug nc 7

then send again and look in the server log (path is set by LogFile in netxmsd.conf, /var/log/netxmsd by default). It will be one of:

• Call to curl_easy_perform() failed - transport level: DNS, TLS, firewall. Note the Slack driver has no proxy option, so if this server reaches the internet through a proxy, that alone will stop it.
• Error response from webhook: HTTP response code is N
• Error response from webhook: <text> - Slack's own error, e.g. channel_not_found or invalid_payload.

Two things worth checking before you do that:

• url must be a classic incoming webhook - https://hooks.slack.com/services/T.../B.../... - which replies with the literal string "ok". A Workflow Builder trigger URL (https://hooks.slack.com/triggers/...) replies with JSON instead, and the driver will report Driver Error even though Slack accepted the message. This is the easiest one to get wrong right now, since Slack pushes you towards Workflow Builder.
• Recipient is mandatory for this driver and goes out as the Slack channel override. If it names a channel that doesn't exist you get channel_not_found back.

Your post shows url= with nothing after it - assuming that's just removed for the forum, but worth confirming the value actually saved.

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.

Your fresh install working is the useful data point - this is something about that specific server, not the pinboard code.

Here's what's actually happening: all web UI settings live in a single properties file on the machine running the web UI, under the servlet container's work directory, named nxmc.preferences.<uuid>. The uuid comes from a cookie called nxmcStoreId in your browser. If that cookie doesn't come back on the next login, the web UI generates a new uuid and opens an empty file - and the old one stays on disk with all your settings still in it. Pinboard, the "Show server clock" checkbox and column widths all live in that one file, which is why they go together.

Three things to check, and they split the problem cleanly:

• How many contexts are deployed. Look at /var/lib/tomcat10/work/Catalina/localhost/ - if more than one nxmc context is there (nxmc and nxmc-6.2.4, say), each has its own state directory, and the files you find may belong to a context you are no longer using. The web UI logs a line "State directory:" at every startup naming the one actually in use.
• Whether a new file appears per login. List the state directory, log in again, list it again. A new nxmc.preferences.<uuid> each time means the cookie is not coming back. The same file with a new timestamp means it is, and the problem is elsewhere.
• The cookie itself. Browser dev tools, Application - Cookies, look for nxmcStoreId. It is set with a 90 day lifetime, so it should survive a logout. If your nginx config caches or strips Set-Cookie on the proxied responses, it won't.

If you already have a file there containing pinboard$<number> entries, that settles most of it on its own: saving works, and the session that comes up empty is reading a different file.

The web UI log goes to catalina.out on a Tomcat install - grep it for "State directory", "local preferences" and "Invalid store ID". (-Dnxmc.logfile is only set in our Jetty instructions, so on Tomcat everything lands in the console log.)

Note: even once this works, that directory is Tomcat's per-context work directory and it is cleared on war redeploy. So web UI settings are lost on every web UI upgrade by design - that is likely part of what you saw across the three version upgrades.

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.

I have installed a new NetXMS system on an Ubuntu server to test the newest release and some new ideas for our existing install.

Previously we had used email for our alerting platform, but it has some issues, and we would like to attempt to use Slack as a possible alterantive, however when I configure the Notification Channel for Slack I am not getting anywhere and the error on the Notification Channel setup is Status: failure, Error Message: Driver Error

It is a brand new base install of NetXMS with the WebGui added... and a few nodes monitored.

I have configured a webhook for slack, and added the following configuration in the Notification Channel setup for Slack:

username=monitor
url=[https://hooks.slack.com/services/***** private info here *****]

I am not sure what I am doing wrong?

Thank you.
 

On a different server, I performed a fresh installation of nginx+tomcat+nxmc-6.2.4.war, and when I tested it, Pinview started working normally.

Im still seeing this after installing  6.2.3 agent from 5.2.8 server is 6.2.2  windows agents repeatedly update installed packages.

Thank you for your feedback. I have tried the following possibilities:

• I tried different NETXMS versions, currently 6.2.4 (the problem has persisted since the last 3 version upgrades).
• I recently installed TomCat 10 and re-uploaded the war file
• I tried with different browsers (Chrome, Opera, Firefox), but the result was the same.
• I select "Show server clock" in Client Preferences, save, and exit, but when I re-enter, it's still not set.
• I set the Alarms page using PinView F7, but the situation remains the same even after closing the browser or logging out.

Hi,

Not a setting — there's nothing to enable, pinboard is saved when the session ends and restored on the next login. Looks like a regression, but two different things can produce an empty pinboard in the web UI and they need different fixes.

So: 1) which exact version are you on? 2) does it stay empty after an explicit Logout, or only after closing the browser? 3) do other web UI settings survive — last active perspective, splitter positions, table column widths — or do those reset too?

That last one matters because web UI settings are not stored in the server database. They live in a file on the machine running the web UI, in the servlet container's temp directory, keyed by a cookie in your browser. If everything resets, you're losing that file — typically a web UI restart that recreates the temp dir — and that's a separate problem from the pinboard itself.

PinView, which used to work, seems to have stopped working in the last couple of versions.

For example, after pinning some dashboards with PinView and then logging out or closing the browser and reopening, the dashboards I had previously set would reappear active.

Now, when I open the Pinboard panel, it's always empty.

Has anyone else encountered this?

Could this be a setting change or a bug?