Technical note

Windows service accounts.

A Windows service runs as a user. Which user decides what it can read, what it can write, and how far a compromise reaches.

Why the account matters

A service does not inherit the permissions of whoever installed it, or of whoever happens to be logged in. It runs under an identity of its own, and every file, folder, registry key, and network share it touches is checked against that identity.

The two ways of getting it wrong look nothing alike. Too little access announces itself immediately — the service starts and then cannot open its source directory. Too much access announces itself never, right up until something goes wrong.

The built-in accounts

LocalSystem
Full control of the local machine, and presents the computer account on the network. No password to manage, and no permission problem it cannot solve — which is also the reason to avoid it. Anything that compromises a LocalSystem service has compromised the machine.
NetworkService
Few local privileges, but authenticates to other machines as the computer account. The usual answer when a service reads from a domain share and needs no local privilege of its own.
LocalService
Few local privileges, and anonymous on the network. The least privileged built-in identity, and the right one when everything the service needs is local and already readable.
Virtual account
A per-service identity, written NT SERVICE\ServiceName, created automatically with no password and no blast radius shared with any other service. Grant it access to a folder by name exactly like any other account.
Domain or local user
A real account you create and manage. Necessary when the service has to present specific credentials to another system — and it brings a password that expires, an account that can be locked out, and a credential worth stealing.

Granting access to your data

Whichever identity you choose, the data directories are the part to get right: explicit read access on the source imagery, read and write on any output or cache directory, and nothing wider. Permissions inherited from a parent folder are the usual reason a service can read one directory and not the one beside it.

A named account also needs the "Log on as a service" right. If the service fails to start with a logon failure — error 1069 — that right is what is missing, not the password.

Choosing

Local files only: LocalService, or a virtual account. Reading from a network share: NetworkService, or a domain account that has been granted access to it. Reach for LocalSystem only when something genuinely requires machine-wide privilege — and when you do, know that you chose it.