-
Notifications
You must be signed in to change notification settings - Fork 225
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Copying files from Azure File Share to local directory consistently failing with v10.27.0 #2858
Comments
Just to add - my team is also seeing similar issues from v10.27.0. |
@gapra-msft, I'm just coming back to this today and it looks like you've already created a PR. Do you still need our debug logs? If so, are there any specific arguments we should add to the |
@sgerace --log-level=DEBUG would be the most verbose logs. Yes, sharing them would be helpful. We are still working on the fix. |
@gapra-msft, I finally got around to generating and downloading the logs with |
@sgerace If you could zip it, that would be ideal. |
@gapra-msft, I just tried to email the compressed log file to azcopydev@microsoft.com, but received the following error: |
@sgerace could you try my email? gapra AT microsoft.com |
@gapra-msft Did that work? |
Hi @sgerace Thanks! Yes, I was able to access the logs in your email. I believe this is the same issue we are currently working towards fixing. We will be sure to update you once a proper fix is available. |
Hi @sgerace We just released a patch which should resolve your problem. Please upgrade to 10.27.1 |
Thanks @gapra-msft, I can confirm that upgrading to 10.27.1 has fixed our issue. |
We started noticing intermittent failures in one of our GitHub actions pipelines which uses azcopy to download a number of files (34200 files, 1223 folders, 5,213,971,256 bytes) from an Azure File Share to the local build machine. After looking at the logs, we noticed that the failures are occurring whenever the build agent has v10.27.0 of azcopy installed. Since some agents were still running v10.26.0, the job succeeds "intermittently" whenever we are assigned a GitHub actions runner that still has the older version of azcopy installed (we're using the ubuntu-latest build agent image). We've been seeing the failure rate slowly increase over the last several days, and now it is failing every time (because all runners now have the azcopy v10.27.0 installed).
We are able to consistently reproduce the error on a local development machine (running macOS); the operation succeeds without any issues when running v10.26.0 and fails every time when running v10.27.0.
The command we are running is:
We are leveraging
AZCOPY_AUTO_LOGIN_TYPE=SPN
and settingAZCOPY_SPA_APPLICATION_ID
,AZCOPY_SPA_CLIENT_SECRET
, andAZCOPY_TENANT_ID
to provide the command the SPN credentials.Looking through the logs, it seems like there are a lot of
DOWNLOADFAILED
errors related to "no such file or directory":Note that I've redacted sensitive the storage account and file share names as well as the file paths (hence the
####
s in the logs).This is a major issue for us at the moment as none of our pipelines are able to function properly. Thanks!
The text was updated successfully, but these errors were encountered: