AzCopy在CMD中上传正常，但在批处理脚本中执行报403/401认证错误求助

嗨，我碰到过不少用户遇到和你一模一样的问题——手动在CMD里跑AzCopy完全正常，放到批处理或者任务计划里就触发认证错误。咱们一步步来排查解决：

1. 先把批处理里的引号格式改对！ #

你脚本里用的"是HTML转义的引号，在批处理脚本里这是无效的，会被当成字符串的一部分。比如cd "C:\Program Files\AzCopy"会被解析成要进入一个带引号的路径，这显然不对；后面的AzCopy命令参数也会因为引号错误被截断，导致SAS令牌不完整，服务器自然返回403/401。

2. 用绝对路径调用AzCopy，避开工作目录坑 #

手动CMD的时候你是先导航到AzCopy目录再执行，但批处理或者任务计划运行时，默认工作目录可能不是这个路径——就算cd命令失败，脚本也会继续跑，可能调用的不是你预期的AzCopy版本（甚至找不到AzCopy），间接引发错误。直接用绝对路径调用更可靠：

@echo off
"C:\Program Files\AzCopy\azcopy.exe" cp "G:\Backup\UATBackups\*" "https://<storage-account-name>.blob.core.windows.net/test/?sp=rw&st=2024-10-08T15:28:58Z&se=2024-10-08T23:28:58Z&spr=https&sv=2022-11-02&sr=c&sig=<SAS-token>" --recursive=true --block-blob-tier=Cold --overwrite=false

3. 确认SAS令牌的完整性和有效性 #

• 一定要把整个Blob URL（包括SAS令牌）用完整的双引号括起来：批处理里如果没有引号，&会被当成命令分隔符，导致SAS令牌被截断，服务器收到的是不完整的授权信息，直接报403。
• 检查SAS是否过期：你示例里的SAS有效期只到2024-10-08，如果现在已经过了这个时间，肯定会认证失败。任务计划每天跑的话，要生成长期有效的SAS，或者考虑用更安全的Azure AD认证。
• 验证SAS权限：确认sp=rw（读写权限）、sr=c（容器级别）这些参数和你要操作的存储容器完全匹配。

4. 任务计划的运行细节别忽略 #

如果是放到任务计划里，还要注意：

• 运行账户权限：确保任务计划用的账户能访问G:\Backup\UATBackups\，不然连本地文件都读不到，也可能间接引发认证相关的混淆。
• 别隐藏运行窗口：测试时关掉任务计划的“隐藏”选项，这样能看到执行过程中的错误提示，方便快速定位问题。

最后，你可以先把批处理里的@echo off删掉，或者在脚本最后加pause，手动运行批处理看看有没有路径错误、命令截断之类的提示，这些都能帮你更快找到问题根源。

备注：内容来源于stack exchange，提问作者Michael Brown