Автономное развертывание ASP .Net Core 2 дает ошибку 502,5 в IIS под другой учетной записью удостоверения пула приложений

У меня есть приложение ASP .Net Core 2 Web Api, нацеленное на netcoreapp2.1 и развертывающееся как автономное (создает exe) для IIS.

На этом сервере приложение будет работать с существующим пулом приложений, настроенным для работы под определенной учетной записью AD.

Когда мы меняем его, чтобы использовать другую учетную запись, которая, похоже, имеет те же права доступа к папкам, что и первая учетная запись, приложение не запускается и выдает ошибку 502.5.

введите описание изображения здесь

Вот действительно странная часть. Если мы запустим другой сайт, указывающий на ту же папку приложения, но под первой учетной записью AD, он будет работать и ЗАТЕМ запустим сайт с секундной учетной записью AD, теперь он будет работать отлично.

Еще немного информации: физическое расположение файлов приложения находится в общей сетевой папке. Когда мы перемещаем физические файлы на сервер IIS (для его локального запуска), он будет работать, но из-за нашей корпоративной настройки это не вариант в производстве. Таким образом, кажется, что это может быть связано с каким-то разрешением / политикой для запуска exe из сетевого ресурса с использованием пути к файлу UNC.

ОБНОВЛЕНИЕ. Файлы используются совместно с NAS, а не с общего ресурса Windows Server. Кроме того, я определил, что для пользователя это не работает, поскольку приложение сообщает, что оно работает в зоне Интернета, тогда как другой пользователь работает в зоне интрасети.

Как определяются эти зоны?

Ниже приведены журналы стандартного вывода при сбое.

Unhandled Exception: System.Net.Sockets.SocketException: An invalid argument was supplied
   at System.Net.Sockets.Socket..ctor(AddressFamily addressFamily, SocketType socketType, ProtocolType protocolType)
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketTransport.BindAsync()
   at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServer.<>c__DisplayClass22_0`1.<<StartAsync>g__OnBind|0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.<BindEndpointAsync>d__3.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Server.Kestrel.Core.ListenOptions.<BindAsync>d__43.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.AddressesStrategy.<BindAsync>d__2.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.<BindAsync>d__0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServer.<StartAsync>d__22`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Hosting.Internal.WebHost.<StartAsync>d__26.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Hosting.WebHostExtensions.<RunAsync>d__5.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Hosting.WebHostExtensions.<RunAsync>d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Hosting.WebHostExtensions.Run(IWebHost host)
   at MyApp.Program.Main(String[] args)

person Jim    schedule 09.08.2018    source источник
comment
Возможно, это связано с SMBv1. Изучая это.   -  person Jim    schedule 09.08.2018
comment
Вы когда-нибудь решали эту проблему? Я получаю аналогичную ошибку после автономного развертывания приложения asp.net core 2.1 в IIS.   -  person dybzon    schedule 29.12.2018
comment
@dybzon оказывается, что существует некоторая проблема низкого уровня, когда учетная запись, под которой работает хост, должна иметь разрешения на всех уровнях общего сетевого ресурса. Несмотря на то, что пользователь может читать файлы в общей папке, это не удастся, если у этого пользователя нет разрешений на всех уровнях папки ...   -  person Jim    schedule 09.01.2019


Ответы (2)


Чтобы решить эту проблему, вам необходимо опубликовать сайт / проект как автономное приложение. Чтобы опубликовать его как автономное приложение, добавьте его в папку csproj.

<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp1.1</TargetFramework>
<PreserveCompilationContext>true</PreserveCompilationContext>
<RuntimeIdentifiers>win7-x64;win7-x86;ubuntu.16.04-x64;</RuntimeIdentifiers>
<SuppressDockerTargets>True</SuppressDockerTargets>
</PropertyGroup>

Надеюсь на эту помощь!

person Mark Spencer    schedule 15.08.2018
comment
На самом деле самодостаточность - это часть проблемы. Он работает как зависимая от платформы, потому что исполняемый файл не выполняется через общий сетевой ресурс, как развертывание SC. - person Jim; 15.08.2018
comment
Считайте, что это связано с какой-то политикой, влияющей на безопасность dotnet exe, которая запускается из общего сетевого ресурса. - person Jim; 15.08.2018

Что касается нашей проблемы, оказывается, что учетная запись, под которой работает сайт, должна иметь разрешения на чтение на каждом уровне каталога пути к общему файловому ресурсу NAS. Как только это было сделано, сервер запустился правильно.

person Jim    schedule 09.01.2019