Ошибка развертывания веб-приложения Azure с помощью msdeploy - ERROR_INSUFFICIENT_A CCESS_TO_SITE_FOLDER

Я развертываю свое веб-приложение Azure уже около 4 месяцев, используя msdeploy, и все прошло гладко, чтобы загрузить веб-сайт. До недавнего времени ошибок с развертыванием не было. Теперь я получаю ошибку «ERROR_INSUFFICIENT_ACCESS_TO_SITE_FOLDER» при публикации приложения веб-сайта.

Для меня единственный способ успешно обновить веб-сайт - это остановить веб-приложение в Azure, а затем выполнить публикацию веб-приложения через Visual Studio. Но это может быть проблемой, если пользователи в настоящее время используют систему. Я действительно не хочу простоев при обновлении сайта.

Полная ошибка выглядит следующим образом:

Ошибка msdeploy ERROR_INSUFFICIENT_ACCESS_TO_SITE_FOLDER: не удалось выполнить задачу веб-развертывания. (Невозможно выполнить операцию («Создать файл») для указанного каталога («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
person Steven van der Merwe    schedule 05.01.2016    source источник

Ответы (5)


arrow_upward
27
arrow_downward

Ошибка немного обманчива. Вероятно, это не имеет ничего общего с разрешением, а вместо этого вызвано использованием файлов.

Всегда ли это происходит с Gehs.DbFactory.dll или иногда с другими файлами? Кроме того, Gehs.DbFactory.dll это обычная управляемая сборка или собственная / смешанная сборка?

Обычно все сборки копируются в тень, поэтому они не блокируются в папке bin. Если он родной, он может оказаться загруженным на место.

Обратите внимание, что в этом случае это не относится к Azure, и у вас, вероятно, возникнет такая же проблема при развертывании где угодно. например попробуйте удалить этот файл из папки bin при локальном запуске.

Так или иначе, вам нужно убедиться, что ни один файл не заблокирован на месте, если вы хотите опубликовать более новую версию.

Если вы не можете найти способ сделать это, вот метод, который позволит вам публиковать без простоев:

  • используя Kudu Console, перейдите в свою d:\home\site\wwwroot\bin папку
  • Переименование вызывающей ошибку DLL, например на Gehs.DbFactory.dll.old (переименование нормально работает, даже если вы не можете его удалить)
  • Ваши публикации
person David Ebbo    schedule 05.01.2016
comment
Привет, это может произойти с любым из файлов, опубликованных в этом веб-приложении. Будет ли это отказано в разрешении на создание или в случае удаления удаленных файлов при публикации будет отказано в разрешении на удаление. Однако ваш совет помог мне управлять веб-приложением с помощью консоли Kudu и снова запустить его, переименовав файлы. Спасибо большое. - person Steven van der Merwe; 06.01.2016
comment
Вы также можете остановить веб-сайт на портале Azure перед его публикацией и перезапустить после. Конечно, веб-сайт будет недоступен, но это может быть вариант во время разработки. - person Costo; 16.03.2016
comment
У меня была эта проблема. Несмотря на жалобы на файл на удаленном сервере Azure, простой перезапуск VS устранил проблему. - person Rory McCrossan; 22.11.2017
comment
@Costo Я закрываю сайт, но проблема та же. Наконец удалил файл из консоли отладки Kudu - person Pawan Kotak; 23.03.2020

arrow_upward
3
arrow_downward

То же самое происходило со мной, когда я добавил новую папку в разделе «Контент» своего проекта, а затем попытался опубликовать. Я только что перезапустил приложение в Azure, и все заработало.

person Dan    schedule 24.06.2017

arrow_upward
1
arrow_downward

Я получил ошибку (Unable to perform the operation ("Delete Directory") for the specified directory ("2_0_50727") при развертывании, которое работало нормально и внезапно сломалось.

Если вы не обращаете внимания, «2_0_50727» выглядит как случайное число.

Оказывается, это была папка aspnet_client\system_web\2_0_50727, в которой даже не было файлов.

Судя по метке времени этой папки - и тому факту, что она была во ВСЕХ моих веб-приложениях с этой меткой времени - она ​​должна была быть создана Add / Remove Features, когда я внес некоторые изменения в мои установленные функции IIS. Таким образом, какие бы разрешения ни использовались, это то, как эта папка была создана.

Как только я удалил его, я снова смог развернуть.

person Simon_Weaver    schedule 19.04.2017
comment
Поэтому обязательно проверьте все свои веб-приложения на это - возможно, все виртуальные каталоги, которые тоже являются приложениями. - person Simon_Weaver; 22.04.2017

arrow_upward
1
arrow_downward

Это происходило и со мной, когда я выполнял развертывание из Octopus в веб-приложение Azure путем остановки экземпляра. Но процесс w3wp scm все еще использовал этот файл. Поэтому мне пришлось убить его, зайдя в Process Explorer.

Перед тем, как убить его, найдите процесс, который использует файл, выполнив поиск из File Handle

person sudipto das    schedule 30.06.2020

arrow_upward
0
arrow_downward

Со мной случается, когда я испортил файлы службы приложений через FTP. Я, наверное, удалил что-то важное. Помогло обновление и перезапуск службы приложений.

person Alamakanambra    schedule 20.11.2020