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?

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.

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.

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.

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.