Разрешения Хостинг .NET Core вне процесса с файлами на сетевом диске

У меня есть новый .NET Core API, который нацелен на полную инфраструктуру .Net, поэтому размещается вне процесса в IIS. Это отлично работает локально в Visual Studio, а также хорошо работает в тестовой среде с использованием IIS, однако при развертывании в рабочей среде это не работает. Разница, которую я вижу, заключается в том, что в тестовой среде есть локальный диск с файлами API, а для рабочих файлов API задан путь UNC в IIS, пул приложений работает как пользователь домена, имеющий полный доступ к сетевой папке. API не запускается с ошибками, сообщения о которых показаны ниже из журнала событий, включая сбой записи в журналы stdout. Однако, если я настрою пул приложений для работы в качестве учетной записи администратора домена, все будет хорошо, и API запустится. Конечно, я не могу работать от имени этого пользователя, поэтому мой вопрос в том, какие разрешения или уровни доверия мне здесь не хватает. Я новичок в .NET Core, поэтому не уверен, какие дополнительные разрешения могут потребоваться. Другие полные веб-сайты и службы .NET Framework нормально работают на этом сервере со своими файлами на этом сетевом диске.

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

Application EventLog для источника: «IIS AspNetCore Module V2» Предупреждение: «Не удалось создать stdoutLogFile \?\UNC\fileclstr\Websites\WebsiteName\API\logs\stdout_20191205204322_15236.log, ErrorCode = '0x800700a1'».

Журнал событий приложения для источника: Ошибка выполнения .NET: «Приложение: DistributedServices.WebsiteName.exe Версия платформы: v4.0.30319 Описание: Процесс был прерван из-за необработанного исключения. Информация об исключении: System.Net.Sockets.SocketException в System.Net .Sockets.Socket..ctor(System.Net.Sockets.AddressFamily, System.Net.Sockets.SocketType, System.Net.Sockets.ProtocolType) в Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketTransport.BindAsync() в Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServer+‹>c__DisplayClass21_01+<<StartAsync>g__OnBind|0>d[[Microsoft.AspNetCore.Hosting.Internal.HostingApplication+Context, Microsoft.AspNetCore.Hosting, Version=2.2.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60]].MoveNext() at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(System.Threading.Tasks.Task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task) at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder+<BindEndpointAsync>d__3.MoveNext() at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(System.Threading.Tasks.Task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task) at Microsoft.AspNetCore.Server.Kestrel.Core.ListenOptions+<BindAsync>d__43.MoveNext() at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(System.Threading.Tasks.Task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task) at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder+AddressesStrategy+<BindAsync>d__2.MoveNext() at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(System.Threading.Tasks.Task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task) at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder+<BindAsync>d__0.MoveNext() at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(System.Threading.Tasks.Task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task) at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServer+<StartAsync>d__211[[Microsoft.AspNetCore.Hosting.Internal.HostingApplication+Context, Microsoft.AspNetCore.Hosting, Version=2.2.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60]] .MoveNext() в System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(System.Threading.Tasks.Task) в System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task) в Microsoft.AspNetCore.Hosting.Intern al.WebHost+d__26.MoveNext() в System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(System.Threading.Tasks.Task) в System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task) в Microsoft. AspNetCore.Hosting.WebHostExtensions+d__5.MoveNext() в System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(System.Threading.Tasks.Task) в System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task) в Microsoft.AspNetCore.Hosting.WebHostExtensions+d__4.MoveNext() в System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(System.Threading.Tasks.Task) в System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task ) в Microsoft.AspNetCore.Hosting.WebHostExtensions.Run(Microsoft.AspNetCore.Hosting.IWebHost) в DistributedServices.WebsiteName.Program.Main(System.String[])"

Журнал событий приложения для источника: «Ошибка приложения» Ошибка: «Имя сбойного приложения: DistributedServices.WebsiteName.exe, версия: 1.0.0.0, отметка времени: 0xf4041a68 Имя сбойного модуля: KERNELBASE.dll, версия: 10.0.14393.3321, отметка времени: 0x5da7e8d8 Код исключения: 0xe0434352 Смещение ошибки: 0x000dc232 Идентификатор сбойного процесса: 0x2bf8 Время запуска сбойного приложения: 0x01d5abaca2aaaf51 Путь сбойного приложения: \fileclstr\Websites\WebsiteName\API\DistributedServices.WebsiteName.exe Путь сбойного модуля: C:\Windows\System32\KERNELBASE. dll Идентификатор отчета: c68c4bdd-e46d-4628-8be3-63b1f6cc78dc Полное имя сбойного пакета: Идентификатор сбойного связанного с пакетом приложения: "

Источник журнала событий приложения: «IIS AspNetCore Module V2» Предупреждение: «Приложению '/LM/W3SVC/1/ROOT/api' с физическим корнем '\fileclstr\Websites\WebsiteName\API\' не удалось запустить процесс с командной строкой '\fileclstr\ Websites\WebsiteName\API\DistributedServices.WebsiteName.exe ' на этапе 'PostStartCheck', ErrorCode = '0x8027025b', назначенный порт 38520, retryCounter '1'."

Вот web.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <remove name="aspNetCore" />
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
    </handlers>
    <httpErrors errorMode="DetailedLocalOnly" existingResponse="PassThrough">
      <clear />
    </httpErrors>
    <aspNetCore processPath=".\DistributedServices.WebSiteName.exe" arguments="" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout"  />
  </system.webServer>
</configuration>

Заранее благодарим вас за любые предложения.

Asp.net Core 2.2, пустельга вне процесса, IIS10, Windows Server 2016.


person John Corker    schedule 05.12.2019    source источник
comment
Я предлагаю вам следовать лучшим практикам и не пытаться исправить проблемы из-за странного подхода. Создавайте, выпускайте, развертывайте. Не обслуживайте приложение из сетевого ресурса.   -  person Vladimir Serykh    schedule 05.12.2019
comment
«API не запускается с выброшенными исключениями сокета», отредактируйте свой вопрос, чтобы включить фактическое исключение, пожалуйста. не пишет в логи stdout, что говорит Process Monitor о доступе к файлу?   -  person Lex Li    schedule 05.12.2019
comment
Здравствуйте, Владимир, возможно, мое описание было непонятным. Но мы используем конвейеры Azure DevOps для сборки и развертывания. У нас просто есть прикладные причины, по которым мы используем общее хранилище. Здесь я хотел бы сосредоточиться на том, как Core вне процесса работает с разрешениями и почему API работает нормально с моей учетной записью администратора, а не с учетной записью без прав администратора, запускающей пул приложений. Спасибо.   -  person John Corker    schedule 05.12.2019
comment
Лекс Ли, спасибо за ваш отзыв. Я обновил, чтобы включить ошибки и предупреждения журнала событий.   -  person John Corker    schedule 05.12.2019
comment
Я обновил файл web.config для вывода в папку на диске C, и это создало журналы, показывающие, что при запуске происходит сбой с исключением сокета, но он пытается подключиться к SQL Server и терпит неудачу. SQL Server использует встроенную безопасность, подключаясь как пользователь, запускающий приложение, поэтому я думаю, что это проблема, наряду с тем, что журналы не создаются в общем ресурсе. Я думаю, что внепроцессное приложение не работает как моя личность в пуле приложений, есть идеи, как я могу контролировать пользователя, под которым оно работает? Является ли идентификатор пула приложений выходом из процесса? Спасибо.   -  person John Corker    schedule 06.12.2019
comment
Если вам нужно устранить проблему с разрешениями NTFS, рекомендуется начать с монитора процессов Microsoft docs.microsoft.com/en-us/sysinternals/downloads/procmon. Он сообщит вам, где отказано в доступе или нарушен доступ, и какие идентификаторы приложений используются для этой операции.   -  person Jokies Ding    schedule 06.12.2019


Ответы (1)


Это заняло много дней, но я, наконец, добрался туда.

У пользователя были разрешения на \\fileclstr\Websites\WebsiteName\, но этого, по-видимому, было недостаточно, и предоставление разрешений на \\fileclstr\Websites\ позволило ему работать во внепроцессном режиме IIS .NET Core, ориентированном на полную структуру.

Спасибо за ваши Коментарии.

person John Corker    schedule 10.12.2019