Repository navigation
[QUESTION] Is there changes to installation for Darling headless since version 3.7.1? #5627
Description
Which component is your question about?
Darling
Performance Monitor Version
3.9.0
Is your question about how it works, or the results?
Setup / installation
What's your question?
Today I downloaded the 3.9.0 version and followed the usual setup steps I have used before:
Stopped the service
Extracted the zip-file over the existing folder (C:\PerformanceMonitorDarling)
Ran the installscript (.\install-darling.ps1) from a Powershell-session running under Administrator-settings.
I then got some errors as shown below. I have not changed any permissions on the install folder since the last time I did an upgrade. Are there some new security-settings in this version?
The error message when trying to run install-script is as follows:
ERROR: Ordinary users can already write to this install folder, before this script has locked anything down:
BUILTIN\Users on C:\PerformanceMonitorDarling
C:\PerformanceMonitorDarling\pg-runtime (owned by NT SERVICE\PerformanceMonitor Darling)
C:\PerformanceMonitorDarling\pg-runtime\pgsql (owned by NT SERVICE\PerformanceMonitor Darling)
C:\PerformanceMonitorDarling\pg-runtime\pg-runtime.stamp (owned by NT SERVICE\PerformanceMonitor Darling)
C:\PerformanceMonitorDarling\pg-runtime\pgsql\bin (owned by NT SERVICE\PerformanceMonitor Darling)
C:\PerformanceMonitorDarling\pg-runtime\pgsql\lib (owned by NT SERVICE\PerformanceMonitor Darling)
C:\PerformanceMonitorDarling\pg-runtime\pgsql\share (owned by NT SERVICE\PerformanceMonitor Darling)
C:\PerformanceMonitorDarling\pg-runtime\pgsql\bin\clusterdb.exe (owned by NT SERVICE\PerformanceMonitor Darling)
C:\PerformanceMonitorDarling\pg-runtime\pgsql\bin\createdb.exe (owned by NT SERVICE\PerformanceMonitor Darling)
C:\PerformanceMonitorDarling\pg-runtime\pgsql\bin\createuser.exe (owned by NT SERVICE\PerformanceMonitor Darling)
C:\PerformanceMonitorDarling\pg-runtime\pgsql\bin\dropdb.exe (owned by NT SERVICE\PerformanceMonitor Darling)
C:\PerformanceMonitorDarling\pg-runtime\pgsql\bin\dropuser.exe (owned by NT SERVICE\PerformanceMonitor Darling)
C:\PerformanceMonitorDarling\pg-runtime\pgsql\bin\ecpg.exe (owned by NT SERVICE\PerformanceMonitor Darling)
C:\PerformanceMonitorDarling\pg-runtime\pgsql\bin\icudt77.dll (owned by NT SERVICE\PerformanceMonitor Darling)
C:\PerformanceMonitorDarling\pg-runtime\pgsql\bin\icuin77.dll (owned by NT SERVICE\PerformanceMonitor Darling)
C:\PerformanceMonitorDarling\pg-runtime\pgsql\bin\icuio77.dll (owned by NT SERVICE\PerformanceMonitor Darling)
C:\PerformanceMonitorDarling\pg-runtime\pgsql\bin\icutu77.dll (owned by NT SERVICE\PerformanceMonitor Darling)
C:\PerformanceMonitorDarling\pg-runtime\pgsql\bin\icuuc77.dll (owned by NT SERVICE\PerformanceMonitor Darling)
C:\PerformanceMonitorDarling\pg-runtime\pgsql\bin\initdb.exe (owned by NT SERVICE\PerformanceMonitor Darling)
C:\PerformanceMonitorDarling\pg-runtime\pgsql\bin\libcrypto-3-x64.dll (owned by NT SERVICE\PerformanceMonitor Darling)
...and 1723 more.
Files here may already have been replaced with something other than what the zip shipped - the lock this
script applies next (1b2) only stops FURTHER writes, it does not check what is already on disk. This is
the usual shape of a folder made directly under C:, which inherits Authenticated Users: Modify from the
volume root.
Do NOT try to repair this folder's permissions in place: fixing the ACL cannot undo a file that was already
replaced, and cannot prove none was. Extract the zip fresh under C:\Program Files<something>, or another
folder only an administrator can write to, and run this script from there instead. If this folder is
deliberately writable (a dev loop) and you accept the risk, re-run with -AcceptWritableExtraction.
Nothing was installed or changed.
Additional Context
No response
Activity
Repro: Darling upgrade ACL check (#5627), service-created base and tw…
Repro: Darling upgrade ACL check (#5627), retry the changed-logon shape
Repro: Darling upgrade ACL check (#5627), restore the full matrix [sk…
erikdarlingdata commentedon Oct 9, 2026
Claude posting for Erik Darling.
Thanks for the report. This is our bug, and it came in with 3.9.0.
Of the 1,743 entries the script listed, 1,742 are wrong. They are the PostgreSQL runtime files the Darling service unpacked itself, so they belong to the service's own account,
NT SERVICE\PerformanceMonitor Darling. The check is meant to trust that account, but it only does so while the service is registered and still logs on as that account. If the service was removed, or now logs on as a different account, the check counts our own service as an ordinary user. A domain account set up for Windows authentication is one example.The other entry,
BUILTIN\UsersonC:\PerformanceMonitorDarling, is correct. A folder made directly underC:\inherits write access for ordinary users from the drive root, and versions before 3.9.0 did not remove it. The check that 3.9.0 added refuses to upgrade in place over a folder like that.The fix for the 1,742 wrong entries is in 3.10.0, planned for today. The folder entry will still stop an in-place upgrade in 3.10.0. The way forward is to move the install to a new folder under
C:\Program Files. Your collected data is kept outside the install folder, so the move does not touch it. We are testing the exact steps now and will post them here as a second comment today. Please do not use-AcceptWritableExtractionto get past the check.To tell which case you hit, please answer one question. Is the service still registered, and does it log on as
NT SERVICE\PerformanceMonitor Darlingor as another account? There is no need to post the account name.Repro: Darling move to Program Files and 3.10 upgrade shapes (#5627)
Repro: run the 3.10 upgrade shapes (#5627)
Repro: read the store with its own credential, compare store listings…
Repro: re-own the store when the service logon changes (#5627)
Repro: rerun the changed-logon upgrade shapes with the store re-owned (…
Repro: print the store owner and service log after a changed-logon mo…
Release checklist: add the Darling service install and upgrade section (
Repro: hand the credential files to the new service account the way t…
10 remaining items
erikdarlingdata commentedon Oct 9, 2026
Claude posting for Erik Darling.
Thanks, that confirms the cause. The check does not trust the service's own account once the service logs on as a different account, such as your AD account. The fix in 3.10.0 covers that case.
Your two questions, answered by the steps in the comment above:
darling.jsonagain? No. Copy it from the old folder (step 3). Your settings, listening addresses included, come across as they are.Release checklist: 8a (a) names the real upgrade-shape workflow, its …
ghauan commentedon Oct 9, 2026
Thank you. Your 6 steps seems to have solved it for meg. You may close this issue if you like.
The install folder check trusts the service account only in the folde…
Tests: keep the doc comment on the member it describes (#5627)
erikdarlingdata commentedon Oct 9, 2026
Claude posting for Erik Darling.
Good to hear, and thanks for testing the steps. We will keep this issue open until 3.10.0 ships with the fix, and it closes then. After that, upgrades of the new folder no longer list the service's own files.
Pre-lock refusal: steps only for the folder the service runs from, ex…
CHANGELOG: draft entry for #5628 (#5627, #5629), upgrade refusals
The pre-lock check trusts the install's own service SID and an existi…
CHANGELOG: a 3.10.0 Important note for installs that ordinary users c…
Merge dev into the 3.10.0 splice branch
Cite the pre-lock check entry by its PR, #5628
erikdarlingdata commentedon Oct 9, 2026
Claude posting for Erik Darling.
3.10.0 is out with the fix: https://github.com/erikdarlingdata/PerformanceMonitor/releases/tag/v3.10.0. Upgrades of the new folder no longer list the service's own files. If an upgrade still refuses, it now prints numbered steps to follow. Thanks again for testing.