azure-pipelines-tasks: Windows Machine File Copy task fails due to multiple connections
We have multiple Windows Machine File Copy tasks on different Release Agents (+ and different target machines), the target dirs are specified for folders (like D:\TargetFolder), the target machine lists contain fqdn machine names. Lately we randomly started to get the following error:
Failed to Create PSDrive with Destination: '\\TargetMachineFQDN\D$\TargetFolder', ErrorMessage: 'Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again'
Suspicious thing to me: https://github.com/Microsoft/vsts-tasks/blob/ea589633e6eb5c3aec562076a240dd4f2f781b0b/Tasks/WindowsMachineFileCopyV2/RoboCopyJob.ps1#L219-L225
For this there isn’t a matching Remove-PSDrive command - can it be the issue that the release agents started to run out of free network shares?
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 50 (15 by maintainers)
Restarting the windows service agent is running on, solved the issue for us.
This is because you may be using different agents with different service accounts. Try using IP Address, this should resolve this. Another way to resolve is to use same service account for all the agents. However this may not be possible for all scenarios. Using IP address to access the share will surely help resolve the below error: There is an old KB from MS also talks about this: https://support.microsoft.com/en-in/help/938120/error-message-when-you-use-user-credentials-to-connect-to-a-network-sh
“Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again”
Hi,
We are still having this issue intermittently, even after upgrading to use 2.* of the Windows Machine File Copy Task. We had the issue previously with 1.* and did notice that changing it to 2.* allowed us to complete the releases (without rebooting the agents). At the time, it was picking up version 2.1.3 of the task.
However now it’s picking up 2.1.4, and we are having the issue again. Has something regressed in the code? Is there another way we can get around this issue in our release definitions? I’ve seen posts above where people have added a preceding task for ‘net use /y /delete *’, is this a safe thing to do on the release agents as part of a release?
Thanks
Craig
@FlorenceDaniel, no I didn’t figure it out yet.
@rajatagrawal-dev, I tried the net use command. It returns: There are no entries in the list.
I’m able to reproduce quite easy, by creating a build and new release definition. All I do is copy a zip file to a machine.
The first time it works. At the end of the log I see: ##[debug]Attempting to remove PSDrive ‘WFCPSDrive’
If I start a new release, I get: ##[error]Failed to Create PSDrive with Destination: ‘\(Machine).(domain)\D$\VSTS-Deploy\CopyFileError’, ErrorMessage: ‘Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again’
Some extra info: Script stack trace: ##[debug]at (ScriptBlock), D:\vsts-agent-win-x64-2.133.3_work_tasks\WindowsMachineFileCopy_731004d4-1d66-4f70-8c05-638018b22210\2.1.3\RoboCopyJob.ps1: line 222 ##[debug]at (ScriptBlock), D:\vsts-agent-win-x64-2.133.3_work_tasks\WindowsMachineFileCopy_731004d4-1d66-4f70-8c05-638018b22210\2.1.3\WindowsMachineFileCopy.ps1: line 55 ##[debug]at (ScriptBlock), (No file): line 1 ##[debug]at (ScriptBlock), (No file): line 22 ##[debug]at (ScriptBlock), (No file): line 18 ##[debug]at (ScriptBlock), (No file): line 1
When you queue a release, the latest available patch of the version that you have selected (2.) will be taken. So please select 2. in your release definition and in the logs, you will find the exact task version that is available for major version 2.
@FlorenceDaniel I’ll update the thread once the task is deployed to all accounts. Yes, the fix is only in version 2 of the task. Please select version 2 to get the task with latest features and bug fixes.