GitLab runner Windows specifying user account

runner
windows

#1

I am trying to install gitlab-runner (11.4.2) on a Windows 7 Pro 64-bit machine. If I do a simple default gitlab-runner install, it configures itself to use the built-in system account (“NT AUTHORITY/System”). This works, and I can successfully set up the runner (“shell”) and use it from GitLab CI jobs. Unfortunately, this account does not have access to a necessary network-share drive managed by our Active Directory (call it “OURDOMAIN”), and IT indicates they would prefer not to alter this.

I have two accounts on this Windows machine that I could use which can access the file share. One is a day-to-day account (call it “fred.flintstone”), which does not have administrator privileges on the machine. The other (“fred.admin”), does.

I tried installing runner for the day-to-day account with gitlab-runner install --user “OURDOMAIN\fred.flintstone” --password “bedrock” which runs successfully. But the subsequent gitlab-runner start command throws the error “The service did not start due to a logon failure”. I thought it might be that this non-admin account couldn’t open a firewall port or something else runner needs to do, so I tried gitlab-runner install --user “OURDOMAIN\fred.flintstone” --password “slate”, but that also fails “start” with the same error, and I would have thought my admin account should have been able to provide anything the runner needed as well as the system account could. The account/password syntax seems valid - any typos there causes the “install” step to fail with an “invalid account/password” message, so install must be doing a basic check on them.

Is there anyplace that the “gitlab-runner start” invocation would write out any more detailed information on what “did not start due to a logon failure” might have been? Or are there any suggestions? I tried gitlab-runner --debug start but it provides no additional info onscreen.

[LATER] - just after posting this, I found this FAQ entry, which indicates that the account may need the “SeServiceLogonRight” permission. I’ll try this and see if that is the problem.