Open DataTraveler1 opened 1 year ago
This issue of the service account not having permissions to required folders on the application drive has been mentioned a few times in the past, but I don't believe there is an open issue for it.
I have gone through the above, stopped the service and reset permissions. Started the service and still getting the errors. Using procmon shows an access denied to a file but NTFS permissions shows the service account as having full control.
Saving a script from the editor looks to be throwing a lot of issues with git.
Steps to Reproduce
PSU does not confirm on startup if access is granted to create and append to log files in %PROGRAMDATA%\Universal
Steps to recreate
On a clean machine, ensure that %PROGRAMDATA%\Universal directory does not exist
Successfully setup and configure PSU in native (Kestrel) mode (meaning not IIS) under a service account "A". Include the service account credentials at the time of installation on the MSI install. This ensures that the %PROGRAMDATA%\Universal directory will be created by service account "A".
Sanity check the installation and ensure functionality is working and logs are written to disk
Stop the PSU services
Change the service account that the PowerShell Universal service is using to a service account "B". This service account is identical to "A" with respect to Group Policy rights (e.g. "Logon as a batch") but it does not have write/append access to the %PROGRAMDATA%\Universal directory*.
Configure ProcMon to monitor Universal.Server.exe for ACCESS DENIED events to %PROGRAMDATA%\Universal
Restart the PSU service
Observe that changes made to resources are not retained after restarting PSU again
Observe that log data is not created
* This is because the PSU was installed under a different account
Expected behavior
Actual behavior
Environment data
PSU 3.7.10
Visuals
(figure shows two different tabs from a single ACCESS DENIED entry observed with ProcMon)
Edit 1 fixed typo