NetXMS Support Forum

Hi,

Bundled OpenSSL only exists in the Windows builds - the agent, server, client and web UI installers ship libcrypto-3/libssl-3 DLLs. Linux packages link against the system OpenSSL and the Docker images inherit Debian's, so on those platforms your distribution's updates already cover this and there's nothing for us to ship.

None of the 16 are exploitable in NetXMS. They land in code paths we don't use at all - CMS, PKCS#7, DANE, CRMF, OCB/SIV and the RSA KEM. NXCP encryption uses RSA with OAEP padding, and certificate revocation is handled by our own code rather than OpenSSL's CRL machinery. The remaining few need gigabyte-scale inputs that a TLS handshake can't deliver. That includes CVE-2026-45447, the only High on your list: PKCS7_verify() is not called anywhere in the codebase.

The Windows DLLs will still be updated, because version scanners flag them regardless of reachability. It's a bigger change than a patch bump this time: OpenSSL 3.0 reached end of life on 7 September and 3.0.22 is the final release of that branch, so we're moving the Windows build to 3.5 LTS rather than to a newer 3.0. Tracked in https://github.com/netxms/netxms/issues/3643 - no date yet.

If you need it cleared sooner, you can drop newer libcrypto-3/libssl-3 DLLs into the agent's bin directory yourself; OpenSSL keeps ABI stable across the 3.x series, so 3.5 works in place. Two caveats: they'll be overwritten on the next agent upgrade, and they won't carry our code signature.

Hi,

Confirmed bug, not a configuration problem - your community is configured in the right place. Filed as https://github.com/netxms/netxms/issues/3639

Discovery does try the communities from Network Credentials and does find the working one, but it is discarded before the node object is created, so every discovered node starts on the default "public". Affects all versions since 6.1.0.

Normally this repairs itself: the configuration poll that runs right after node creation tests "public", fails, falls back to the credentials list and writes the correct community back. It does not repair when the device answers "public" as well - the poll tests the node's current community first and stops as soon as it gets any response. That is most likely what you are hitting, since it happens on every device. Worth confirming on one:

nxsnmpget -v 2c -c public 10.61.200.26 .1.3.6.1.2.1.1.2.0
Anything other than a timeout means the device accepts "public" and the automatic correction will never kick in.

Correcting the community on the node stays the workaround until the fix ships - Node::setSNMPCommunity() is available in NXSL if you want to fix existing nodes in bulk.

Unrelated: SNMP.Agent.CommunityString is the community for the server's own built-in SNMP agent (disabled on your server), not for polling, so it has no effect on discovery.

Hi,

nxmc is already jakarta — it's built against jakarta.servlet-api 6.0 and its web.xml declares Jakarta EE 10, so ee10 in your setup is correct. What's failing is that the file you deployed as nxmc-6.2.4.war is not the web UI, it's the Legacy Web API war (netxms-websvc). That one is still javax/EE8 and under ee10 it fails exactly like this.

Two things in your log point at it: the missing class is javax/servlet/http/HttpServlet, which nxmc has no reference to at all, and the context starts as "NetXMS REST API" — that display name comes from the API war's web.xml, the web UI war has no display name.

Check with:

unzip -p /usr/share/jetty-base/webapps/nxmc-6.2.4.war WEB-INF/web.xml | head -8
The web UI war has xmlns="https://jakarta.ee/xml/ns/jakartaee" and version="6.0". What you have will show <display-name>NetXMS REST API</display-name> and version="2.4".

Re-download nxmc-6.2.4.war from the Web Interface Binaries section — the two files sit next to each other there — and it deploys into your existing ee10 setup unchanged.

The backtrace pins it exactly: it's a bug in our MariaDB driver, triggered by an oversized entry in the image library.

Since 6.2 images are stored in the database instead of as files, and the driver allocates the buffer for a field on the stack, sized by the length of that field. Server worker threads get a 1 MB stack by default, so an image over roughly 780 KB overflows it and the process dies the moment anything asks for that image - which is what opening the dashboard does. The upgrade migrates existing image files into the database, so an image that had been fine for years starts crashing the server right after.

Two steps to get you running again.

1) Add to netxmsd.conf and restart the server:

DefaultThreadStackSize=8M
That raises the worker stacks and stops the crash right away.

2) Find the image and replace it with a smaller one:

SELECT guid, name, category, LENGTH(image_data) FROM images ORDER BY LENGTH(image_data) DESC LIMIT 5;
Anything near or above 1000000 is the one. Re-upload a downscaled version through the image library - listing and re-uploading are safe, only fetching the image bytes crashes.

Ticket is https://github.com/netxms/netxms/issues/3637 - the driver should allocate large fields on the heap, not the stack.

Hi,

Fastest way to pin this down is to run the server under gdb and let it stop at the crash - the backtrace names the code path directly.

apt install netxms-dbg
systemctl stop netxms-server
gdb /usr/bin/netxmsd
run -D3
# open the dashboard in the client, wait for the crash
bt

Post the bt output here.

netxms-dbg is required - without it the backtrace is just hex addresses and tells us nothing. Without -d or -S netxmsd stays in foreground, which is what we want; it also starts interactive console there, so add -q if that gets in the way of gdb.

Note: Scripts.RestrictWriteAccess has no effect here. Dashboard element scripts run under user security context, not the read-only one that parameter controls, so toggling it changes nothing either way.

Hi,

Not fixed - I've reopened https://github.com/netxms/netxms/issues/3137. It was closed against a different fix (#3240) that only covered part of the problem.

Your combination is not the version mismatch Filipp mentioned - agent 6.2.3 and server 6.2.2 both contain everything from that work, so the "server must also be 6.2" note does not apply to you.

What is left: the agent can still change the reported user name, and sometimes the display name, for the same Store package between two polls, without signalling that the data is incomplete. Since 6.1 the server treats package name plus user as the package identity, so any such change comes out as a remove plus an install. Most likely triggers are a user profile whose registry hive is not on disk while the user is logged off (roaming profiles, FSLogix, UPD), and a failed SID-to-username lookup.

To tell which one you are hitting, please post:

• nxagentd log with debug level 6 for tag "winnt", covering a full logon and logoff
• System.InstalledProducts table taken twice - once with a user logged on, once without
• whether these are RDS/terminal servers, and whether profiles are roaming, FSLogix or UPD

Workaround is poor. There is no way to exclude Store packages from the inventory, and the inventory is collected on every configuration poll. Since 6.1 SYS_PACKAGE_INSTALLED and SYS_PACKAGE_REMOVED carry the user name as an event parameter, but filtering on it only removes half of each pair - the other half is reported as a system-wide package with empty user.

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.

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.

Добрый день,

Метрика указана неверно. System.Registry.Value(*) — это шаблон из каталога метрик агента, а не готовая метрика: у неё два аргумента, путь к ключу и имя value. Для вашего случая:

System.Registry.Value(HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers,{instance})
{instance} нужно добавить и в description, иначе все шесть DCI получатся с одинаковым именем.

С литеральной * агент не может разобрать первый аргумент как корневой ключ и возвращает "unknown metric", поэтому созданные DCI сразу уходят в статус unsupported — в event log ноды должно быть шесть SYS_DCI_UNSUPPORTED. В Data Collection в режиме просмотра проверьте, что включён показ unsupported DCI.

Instance discovery настроен правильно, external list здесь не нужен — System.Registry.Values(...) возвращает именно имена values.

Отдельно: сам DCI, на котором настроен instance discovery, в режиме просмотра не отображается, в списке видны только созданные по нему DCI. Это ожидаемое поведение.

Hi,

That error means the server is not counting your license as valid — it falls back to the built-in limit of 250 managed nodes and blocks creation above it. "Unlimited" in the key is not enough by itself: a key is ignored if it is expired, capped to a version below 6.2, or bound to a different machine, and none of that is logged.

Run nxlicmgr list from the server's bin directory. Check that the key is actually listed, and that Quantity, Hardware Id, System Id, Version and Expiration are all green. Red in any column is your answer — Version red means the key predates 6.2, Hardware Id or System Id red means it was issued for a different machine.

If the key is missing from the list, or anything is red, write to [email protected] with that output — those cases need the key re-issued.

update: another issue is fixed. this one is tracked here: https://github.com/netxms/netxms/issues/3593

it's fixed already, will be included in next release

Ключ ни на что не влияет в работе программы — собирать без него правильно.

Он добавляет в сборку только libipfix, библиотеку разбора NetFlow/IPFIX. Демон-коллектор nxflowd, для которого она предназначалась, в сборку не входит вообще, а сервер и консоль с flow-данными не работают: обработка так и не была реализована. В 7.0 ключ удалён вместе с кодом.

Вместо собственного коллектора в 7.0 планируется интеграция с внешними анализаторами трафика, первый коннектор — ntopng: https://github.com/netxms/netxms/issues/3429