PowerShell build runner - Second hop problem for accessing network drives


Hi there, 

I have a shared network drive set up containing resources that would be accessed between 5 build agents.  Running the build scripts locally produces no problems, but running the build scripts from TeamCity results in the shared drive not being found. 

I did some digging, and found that this is a long standing design choice from Microsoft with all solutions requiring some kind of infrastructure setup, which I do not have, as this is essentially a lab environment.

Are there any recommended solutions from Jetbrains? I had a look at the shared-resources page, but that just seems be a way of implementing a lock for concurrent builds? 

If there are any other solutions as well it would be greatly appreciated


Edit: some additional Info, the build-agent service is set up to use a local account rather than a SYSTEM account as well       


Right after a lot of frustrating testing, I have figured out a work around: 

With the power shell build runner you cannot access premade network shares, but you have the rights to make make new network shares. Running the command : 

New-PSDrive –Name "K" -PSProvider FileSystem -Root "\\[server name]\[root folder]" -ErrorAction Stop

Will make a drive on the letter "K" for whichever network share you are using. This drive letter is only valid for current PowerShell session.  There are more parameters that you can pass in. 

If you need to access DLL's across the network drive you will need to make a symbolic link 

 new-item -itemtype SymbolicLink -path "." -name "example"  -value "K:\" -ErrorAction Stop

This will make a symbolic link called "example" to the newly created drive in your current working directory.

By default the account does not have the permissions to make symbolic links so you will need to assign it permissions beforehand by:

Local security policy > local policy > user rights assignment > create symbolic links > add [build agent user]  

 Once your script has finished you will need to Clean up the symbolic link, otherwise subsequent build runs will fail

(get-item .\example\).Delete()


If any JetBrains people are read this, I think there is a permissions bug here somewhere. I'm 99% sure TeamCity does not use PSremoting otherwise this workaround would not be possible, so it has be something with the way the TeamCity build agent interacts with the user account.    



It is a known limitation that agents running as a Windows service are not able to access mapped drives and network shares. We have it noted in our documentation here: https://www.jetbrains.com/help/teamcity/known-issues.html#Windows+service+limitations. As a work-around, we suggest running the agent from a console.



Please sign in to leave a comment.