azure-storage-blob-go | Microsoft Azure Blob Storage Library for Go | Azure library

After looking at this issue, I figured out what could be the reason. As you might have already known that a new service principal will be created whenever you create a service connection in the Azure DevOps, I have explained this in detail here. To make the AzureFileCopy@4 task work, we will have to add a role assignment under the Role Assignment in the resource group. You can see this when you click on the Access control (IAM). You can also click on the Manage service connection roles in the service connection you had created for this purpose, which will redirect you to the IAM screen.

1. Click on the +Add and select Add role assignment
2. Select the role as either Storage Blob Data Contributor or Storage Blob Data Owner
3. Click Next; on the next screen add the service principal as a member by searching for the name of the service principal. (You can get the name of the service principal from Azure DevOps, on the page for the Service Connection, by clicking on the Manage Service Principal link. My service principal looked like "AzureDevOps.userna.[guid]".)

1. Click on Review + assign once everything is configured.
2. Wait for a few minutes and run your pipeline again. Your pipeline should run successfully now.

You can follow the same fix when you get the error "Upload to container: '' in storage account: '' with blob prefix: ''"

Based on the comments, my suggestion is to add $HOME/go/bin to the path and use the default GOPATH.

Go mod depends on the bin directory inside the GOPATH. It installs new packages there. The go binary itself can actually reside somewhere else. If you follow these install instruction https://go.dev/doc/install, go itself will actually be in /usr/local/go but the GOPATH is still $HOME/go.

I would also recommend, not involving apt in this at all. This looks like trouble in the form of conflicts with different installations.

I can also reproduce your issue on my side, as different Azure file copy task versions use different versions of AzCopy in behind, then they use different auth ways to call the API to do the operations.

There are two ways to fix the issue.

1. If you use the automatically created service connection, it should have Contributor role in your storage account, you could use Azure file copy task version 3.* instead of 4.*, then it will work.

2. If you want to use Azure file copy task version 4.*, navigate to your storage account -> Access Control (IAM) -> add your service principal used in the service connection as a Storage Blob Data Contributor role, see detailed steps here. It will also work.

I stumbled upon a good solution myself:
Since I was uploading a VHD of a disk already on Azure, instead of using the downloaded VHD I used the original VHD export URL as the source of the disk.

When you request the SAS token, you need to make sure you grant list permission as well, the correct syntax for this is rwdl. I have included the reference for the command as well should you need it here.

So in the 1st case the problem was that SAS token is passed nowhere in this package. It should be added to URL later on during url creation like: