Repository navigation
[QUESTION] Is "could not restrict the ACL"-error expected after a --configure-network? #2093
Description
Which component is your question about?
Darling
Performance Monitor Version
3.3.0
Is your question about how it works, or the results?
Setup / installation
What's your question?
I am trying to open up for using the viewer from another VM, and used the --configure-network to do this. That process made a backup of the darling.json-file before writing changes. When the services was restarted, I got the following error:
2026-08-07 10:13:39.302 [ERROR] [DarlingWorker] Could not restrict the ACL on config backup C:\PerformanceMonitorDarling\darling.json.bak-20260807-094518 (Attempted to perform an unauthorized operation.). It carries the same DPAPI-protected credentials as the live config. From an ELEVATED prompt: icacls "C:\PerformanceMonitorDarling\darling.json.bak-20260807-094518" /inheritance:d then icacls "C:\PerformanceMonitorDarling\darling.json.bak-20260807-094518" /remove:g "BUILTIN\Users" then icacls "C:\PerformanceMonitorDarling\darling.json.bak-20260807-094518" /grant "NT SERVICE\PerformanceMonitor Darling:(F)"
I then followed the suggestions in the error message to run the different icacls-commands, and they ran with success. But when restarting the service, this same error message still comes up.
Does it have any impact of running the application?
Another question you might know in the same go: When the store is set up this way to listen over the LAN (local firewall has been set and our network team has opened in the network firewall), should I then be able to get a positive feedback in a Test-netconnection-call? (Will the service answer?)
Additional Context
I have not yet run the --print-viewer-connection
Activity
erikdarlingdata commentedon Aug 7, 2026
Both good questions:
1. The recurring ACL error — no impact, and your file is actually already secure. Here's the mechanics: on every service start, a hardening sweep (#1816) re-attempts an ACL rewrite on every
darling.json.bak-*it finds. Youricaclscommands worked — the proof is in your own log: the sweep is followed by an independent check that logs a CRITICAL "backup is READABLE by Users" line when a backup is actually exposed, and you're not seeing that line. What keeps failing is the rewrite attempt itself: rewriting an ACL requires ownership (or more than the service has), and your manual fix granted the service rights on a file that's still owned by the admin account that ran the wizard — so the sweep throws "unauthorized" before it can notice there's nothing left to fix. It's log noise about an already-closed exposure, not a security problem and not an operational one.Two clean ways to silence it today:
del "C:\PerformanceMonitorDarling\darling.json.bak-20260807-094518"(elevated).icacls "C:\PerformanceMonitorDarling\darling.json.bak-20260807-094518" /setowner "NT SERVICE\PerformanceMonitor Darling"(elevated).And I'm fixing the underlying annoyance — the sweep should check whether the exposure is already closed before attempting the rewrite, so an already-hardened backup never errors again. That'll be in the next release.
2. Test-NetConnection to the exposed store — yes, with one catch. PostgreSQL accepts the TCP connection first and enforces authentication afterwards, so a plain
Test-NetConnection <host> -Port 5641returnsTcpTestSucceeded: Truewhen the path is open. The catch: the firewall rule--configure-networkcreates is scoped to theallowFromCIDR you entered — a TNC from any machine outside that CIDR fails at the TCP level by design. So run the test from the actual viewer VM (inside the allowed range). If it fails from there: check the Windows rule's scope matches the VM's IP, and that your network team's rule covers the same source range.Merge pull request #2094 from erikdarlingdata/backup-acl-idempotent
erikdarlingdata commentedon Aug 7, 2026
The underlying fix is merged for the next release: the startup sweep now checks whether the exposure is already closed and skips the file entirely — so a hand-hardened backup (your exact situation) never errors again. The two silencing options above work today on 3.3.0.
erikdarlingdata commentedon Aug 7, 2026
Closing: the fix (skip already-hardened backups in the startup sweep) is merged and ships in 3.4.0; the workarounds above cover 3.3.0 meanwhile. The Test-NetConnection question was answered above — reopen if the scoped-firewall explanation doesn't match what you see from the viewer VM.
Skip already-hardened config backups in the startup ACL sweep (erikda…