@adreed-msft Can you take a look, and add to backlog as appropriate?

Sure thing, though I have my suspicions this is actually fixed after the text processing errors PR. I'll check both sides of that.

Myself and others have been getting this error also, see MicrosoftDocs/azure-docs#41969 (comment)

I've created an issue on the az-cli side to fix the encoding: Azure/azure-cli#12291

Im having the same issue when generating a sas token with the ip information as well, trying to copy from a blob to fileshare. Anyone has fixed that?

Depending on the result of @adreed-msft 's check, above, it may be fixed in the upcoming release 10.4. (No date announced)

As far as I tested, SAS token with '/' will work fine when I hit the URL in the browser.
So I think it's the issue of the azcopy itself, not az-cli.

The SignedVersion from az-cli is sv=2018-03-28, and same from Powershell is sv=2019-02-02.
PowerShell generated vaule sv=2019-02-02 is same as Azure Portal generated.
Would you please investigate how azcopy handles URL parameters?

Given that there's a workaround (to escape the slashes) we won't look at this right now. But we'll leave this issue open to remind us to look at it later.

Not solved in AzcopyVersion 10.5.0

Trying to fetch a ZIP file from Azure storage on MacOS (tried zsh and pwsh). File URL copied from portal and do get failure: URL is treated as directory

Note, the SAStoken has "/" escaped with %2F, does not help. GET request shows in URL still "restype=directory"

Is there a workaround for this? I saw mention of escaping the slashes, but that doesn't seem to work.

I just confirmed the issue happens in 10.5.1, causing an error on this Microsoft Learn module. When the tokens are retrieved in the portal there, the slashes are already escaped.

@patridge To workaround it, I've been using the powershell module instead of az cli:

$sourceUri = New-AzStorageBlobSASToken ... -FullUri
$targetUri = New-AzStorageBlobSASToken ... -FullUri
azcopy cp $sourceUri $targetUri --overwrite true

Version 10.6.0
Hit this same error message when copying files that contained a plus symbol in their path (not related to the SAS token). My workaround was to encode the file path, converting + to %2B:

folder+one/foldertwo/file.txt
folder%2Bone/foldertwo/file.txt

AzCopy 10.8.0 ... it was working well for us ... Since last week we are seeing this error

echo
+ echo 'Blob '\''dotnet-5.0.102.tar.gz'\'' does not exist in Prod storage container '\''dotnet'\''. Copying it...'
+ /tmp/azcopy-tool/azcopy copy 'https://oryxsdksdev.blob.core.windows.net/dotnet/dotnet-5.0.102.tar.gz?***' 'https://oryxsdksprod.blob.core.windows.net/dotnet/dotnet-5.0.102.tar.gz?***'

Blob 'dotnet-5.0.102.tar.gz' does not exist in Prod storage container 'dotnet'. Copying it...
INFO: Scanning...

failed to perform copy command due to error: cannot use directory as source without --recursive or a trailing wildcard (/*)

We are trying to copy a blob from one storage account to another with SAS token. Is there any workaround?

any update on this?

AzCopy 10.8.0 not working for me either

failed to perform copy command due to error: cannot use directory as source without --recursive or a trailing wildcard (/*)

there are not slashes in my SAS token.

Trying to copy files from one storage account's blobs to another storage account's file share.

@jackfoxy This error usually means azcopy could not list the properties of a certain path on the source account - invalid path or incorrect/insufficient permissions. Can you verify from azcopy log file if it indeed was the case?

@nakulkar-msft thanks for reaching out.
azcopy is being inconsistent about writing logs to user/.azcopy.
The most recent log timestamps appears to be from earlier tests that failed for other reasons.

I ran the test just now, which wrote the following to stout:

INFO: Scanning...

failed to perform copy command due to error: cannot use directory as source without --recursive or a trailing wildcard (/*)

but did not write a log file with today's timestamp. (And none of my last tests from yesterday have a matching timestamp. I know the TS is in UTC.)

Other odd things about the logs: it records delete statements for the dest file, even though there was no file to delete, all the messages are for the dest paths, no messages at all about the source path.

and the log version is AzcopyVersion 10.7.0, even though I am running 10.8.0

The only messages about properties look like this:

2021/02/12 23:17:59 Parallelize getting file properties (file.Stat): false (Based on AZCOPY_PARALLEL_STAT_FILES environment variable)
2021/02/12 23:17:59 INFO: [P#0-T#6] https://bdaasprodsouthcentralus.file.core.windows.net/locsim-data/tachcorp/fits/cfrfb202081998/final?se=2021-03-14t23%3A17%3A58z&sig=-REDACTED-&sp=rwdl&sr=s&sv=2018-03-28 (folder properties) Queuing folder, to be deleted after it's children are deleted Dst: fits/cfrfb202081998/final

Please take this issue into priority

I'm still getting this issue .. any update on this?

any update on this? I'm still seeing this issue .. this is blocking our weekly release. What is the resolution? Seems like this issue is there since a month and moving from one version to another version. We regenerated the token multiple times with keeping the start date in past, but no way we could make it work.

+ devStorage='https://oryxsdksdev.blob.core.windows.net/dotnet/defaultVersion.txt?***'
+ prodStorage='https://oryxsdksprod.blob.core.windows.net/dotnet/defaultVersion.txt?***'
+ /tmp/azcopy-tool/azcopy cp 'https://oryxsdksdev.blob.core.windows.net/dotnet/defaultVersion.txt?***' 'https://oryxsdksprod.blob.core.windows.net/dotnet/defaultVersion.txt?***'

Blob 'dotnet-5.0.102.tar.gz' already exists in Prod storage container 'dotnet'. Skipping copying it...

Blob 'defaultVersion.txt' does not exist in Prod storage container 'dotnet'. Copying it...
INFO: Scanning...

failed to perform copy command due to error: cannot use directory as source without --recursive or a trailing wildcard (/*)

As you can see we are trying to copy a file and not a directory, but somehow it always detect this as directory

@zezha-msft @JohnRusk

Not sure if others are experiencing the same problem I encountered when they got this message, but my error may not have been related to the token containing the slash as much as I was trying to operate on several objects in a container, for which my SAS token was not configured to allow. I was able to resolve this issue by adding Object to the Allowed resource types when I generated a SAS (shared access signature).

@patridge comment helped resolved this for me. The error message was not helpful. Perhaps the error should guide the user to validate their token.

There's still a PR open related to this issue, but in 10.12.1, /s in SAS tokens work as expected.

This fixed my problem. Had to select "object" when generating the SAS token.

The above PR has been merged to improve error reporting when determining if a source is a directory. Closing this issue as a result. If you are still experiencing any issues, please reopen the issue or create a new one.