通过 msdeploy 的 Azure Web 应用部署错误 - ERROR_INSUFFICIENT_A CCESS_TO_SITE_FOLDER答案

【问题标题】：Azure Web App Deployment error via msdeploy - ERROR_INSUFFICIENT_A CCESS_TO_SITE_FOLDER通过 msdeploy 的 Azure Web 应用部署错误 - ERROR_INSUFFICIENT_A CCESS_TO_SITE_FOLDER
【发布时间】：2022-01-05 08:30:12
【问题描述】：

我已经使用 msdeploy 部署到我的 Azure Web 应用程序大约 4 个月了，上传网站的一切顺利。直到最近，部署都没有错误。我现在在发布网站应用程序时收到“ERROR_INSUFFICIENT_ACCESS_TO_SITE_FOLDER”错误。

我成功更新网站的唯一方法是在 Azure 上停止 Web 应用程序，然后通过 Visual Studio 为 Web 应用程序执行发布。但如果用户当前正在使用该系统，这可能是一个问题。在更新网站时，我真的不希望有任何停机时间。

完整的错误如下：

msdeploy 错误 ERROR_INSUFFICIENT_ACCESS_TO_SITE_FOLDER：Web 部署任务失败。（无法对指定目录（“D:\home\site\ wwwroot\bin\Domain.DbFactory.dll”）执行操作（“创建文件”）。如果服务器管理员未授权此操作您正在使用的用户凭据。了解更多信息：http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_INSUFFICIENT_ACCESS_TO_SITE_FOLDER。）

我将如何授权这些权限？

我还在 Azure 上重置了我的发布配置文件，并下载了一个新配置文件以再次尝试。但没有运气。

【问题讨论】：

标签： azure azure-web-app-service azure-deployment

【解决方案1】：

这个错误有点欺骗性。这可能与权限无关，而是由正在使用的文件引起的。

Gehs.DbFactory.dll 是否总是发生这种情况，或者有时是其他文件？另外，Gehs.DbFactory.dll 是常规托管程序集，还是本机/混合程序集？

通常，所有程序集都会被影子复制，因此它们不会锁定在bin 文件夹中。如果它是原生的，它最终可能会被加载到位。

请注意，如果是这种情况，则它不是特定于 Azure 的，并且您可能会在任何地方部署相同的问题。例如尝试在本地运行时从您的 bin 文件夹中删除此文件。

如果您想发布较新的版本，您需要确保没有文件被锁定到位。

如果您找不到执行此操作的方法，这里有一种技术可以让您在不停机的情况下发布：

使用Kudu Console，转到您的d:\home\site\wwwroot\bin 文件夹
重命名有问题的 DLL，例如到Gehs.DbFactory.dll.old（重命名正常工作，即使你不能删除它）
进行发布

【讨论】：

嗨，任何发布到该网络应用程序的文件都会发生这种情况。无论是“创建”权限被拒绝，还是在发布时删除远程文件的情况下，“删除”权限都会被拒绝。但是，您的建议帮助我使用 Kudu 控制台管理 Web 应用程序，并通过重命名文件使其重新运行。非常感谢。
您也可以在发布前先在 Azure 门户中停止网站，然后再重新启动。当然，该网站将不可用，但在开发过程中可以选择。
我刚遇到这个问题。尽管抱怨远程 Azure 服务器上的文件，但只需重新启动 VS 即可解决问题。
@Costo 我停止网站但同样的问题。终于从 Kudu 调试控制台中删除了文件
这里的解决方案都没有帮助我。解决方案是部署到新插槽，然后将其交换到生产插槽。

【解决方案2】：

对我来说，解决方法是将 Remove additional files at destination 设置为 true。

我在 .NET 6 上，最近刚刚从 .NET Core 3.1 迁移到 .NET 6

【讨论】：

是的，这对我也有用。
这里的场景完全相同。这有效！..但为什么呢？后续发布需要吗？我有静态内容需要在发布之前从文件夹中复制出来，因为它在发布时删除了这个文件夹。然后将数据复制回来。

【解决方案3】：

当我在项目的内容下添加一个新文件夹然后尝试发布时，我也发生了同样的事情。我刚刚在 Azure 上重新启动了应用程序，然后它运行良好。

【讨论】：

【解决方案4】：

我收到错误 (Unable to perform the operation ("Delete Directory") for the specified directory ("2_0_50727") 的部署一直运行良好但突然中断。

如果您不注意，“2_0_50727”看起来只是一个随机数。

原来是文件夹aspnet_client\system_web\2_0_50727 甚至没有包含任何文件。

基于此文件夹的时间戳 - 以及它在我所有具有此时间戳的 Web 应用程序中的事实 - 当我对我的 IIS 安装功能进行一些更改时，它一定是由 Add / Remove Features 创建的。因此，无论运行的权限是什么，这个文件夹都是创建的。

我一删除它就可以再次部署。

【讨论】：

所以请务必检查您所有的网络应用程序 - 可能所有虚拟目录也是应用程序

【解决方案5】：

当我通过停止实例从 Octopus 部署到 Azure Web 应用程序时也发生了这种情况。但是 w3wp scm 进程仍在使用该文件。所以我不得不去进程资源管理器杀死它。

在杀死它之前，通过从文件句柄搜索来搜索正在使用该文件的进程

【讨论】：

【解决方案6】：

当我通过 FTP 处理应用服务文件时发生这种情况。我可能删除了一些重要的东西。刷新和重新启动应用服务有所帮助。

【讨论】：

【解决方案7】：

我的抱怨无法删除D:\home\site\wwwroot\newrelic\Extensions\JetBrains.Annotations.dll。

即使停止网络应用程序，我也无法从 Kudu 的 Powershell 中删除它。

我必须使用-enableRule:DoNotDeleteRule 更新部署管道：

【讨论】：