使用Logic App通过SFTP-SSH上传大文件至Azure文件共享遇报错

问题分析 #

从你的描述来看，小文件（35MB以内）上传一切正常，但文件超过40MB时「创建文件」操作就会失败，还提示The specified resource may be in use by an SMB client，同时生成了filename.partial.lock文件。核心原因其实是大文件写入时的SMB锁定机制冲突：

• Azure文件共享靠.partial.lock文件来防止并发写入冲突，当Logic App一次性读写大文件时，写入操作耗时太长，锁的持有时间过久，很容易触发SMB客户端的超时或冲突检测；
• 你用的「获取文件内容」+「创建文件」是一次性读写全量内容的模式，这种方式在大文件场景下会放大锁竞争和超时风险，单纯调整访问策略没法解决底层的锁定逻辑问题。

可行解决方案 #

1. 改用分块读写+追加文件的方式

放弃一次性读写全量文件，换成分块处理的思路：

• 把「获取文件内容」替换成**「获取文件内容使用分块」**操作（Logic App的SFTP-SSH连接器支持分块读取），可以设置10MB左右的分块大小；
• 先执行「创建文件」操作生成一个空文件，再循环调用「追加文件内容」操作，把每个分块依次写入目标文件；
• 这种方式能大幅缩短单次锁的持有时间，避免长时间占锁引发的冲突。

2. 调整Azure文件共享的SMB锁定超时配置

在Azure存储账户的文件服务设置里，调整SMB相关的超时参数：

• 进入存储账户 → 数据存储 → 文件共享 → 设置 → SMB；
• 把「文件共享超时」和「锁定超时」的数值调大（比如从默认60秒改成300秒），给大文件写入留出足够的完成时间，避免中途因超时释放锁导致冲突。

3. 优化Logic App的重试策略

默认的重试机制会在失败后立即重试，反而会加剧锁冲突：

• 进入「创建文件」操作的设置，把重试策略改成指数退避，设置初始间隔（比如10秒）和合适的最大重试次数；
• 可以在重试前加一个「删除文件」操作，检查并删除残留的filename.partial.lock文件（记得加条件判断，只有文件存在时才执行删除，避免误操作）。

4. 引入Blob存储作为中转层

如果上面的方法都没效果，可以考虑用Blob存储做中间过渡：

• 先把SFTP的文件上传到Azure Blob存储（Blob支持高效分块上传，没有SMB锁定的问题）；
• 再通过Logic App的「复制Blob到文件共享」操作，或者在Logic App里调用Azure CLI执行azcopy命令，把Blob里的文件同步到Azure文件共享；
• 这种方式能彻底绕开SMB锁定的限制，更适合GB级大文件的传输场景。

内容的提问来源于stack exchange，提问作者Ria C