Назад | Перейти на главную страницу

Почему я могу получить доступ к своему файловому ресурсу только под одним ApplicationPoolIdentity?

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

Во-первых, немного предыстории. Клиент моей компании хотел, чтобы их внутреннее приложение переписывало биты за раз. Я вошел в проект, не имея контроля над первоначальной настройкой IIS, и, похоже, есть некоторые забавные вещи, которые работают неправильно, но я вернусь к этому. Первый бит - это приложение с настраиваемой этикеткой, которое записывает файл в общую папку для печати. Чтобы поддерживать необходимые части устаревшего приложения, я создал отдельный сайт в IIS и переместил туда весь код устаревшего приложения для этикеток. Я также создаю новое приложение на их веб-сайте по умолчанию. Итак, структура выглядит примерно так:

IIS

Сайт по умолчанию работает под идентификатором пула приложений ASP.NET v4.0, а не DefaultAppPool, а новое приложение работает под идентификатором пула приложений, названным в честь сайта - Labels.

Проблема

Подприложение для новых этикеток может без проблем записывать в общую папку, но на устаревшем сайте отказано в доступе. Это точно такая же база кода, и единственное различие между ними - это используемый пул приложений. Я хочу поддерживать эти пулы приложений отдельно, но в настоящее время они настроены одинаково. Таким образом, это наводит меня на мысль, что что-то было настроено в IIS до того, как я вмешался, когда удостоверение пула приложений ASP.NET v4.0 каким-то волшебным образом имеет доступ к общей папке, тогда как вновь созданная учетная запись Labels - нет.

Общий доступ к файлам открыт для группы «Все», поэтому проблем на уровне домена быть не должно, но, насколько я понимаю, создаваемые учетные записи IIS в любом случае являются частью виртуального домена IIS AppPool. Итак, как это возможно, что одно удостоверение пула приложений имеет доступ, а другое - нет? Какие шаги я могу предпринять в процессе устранения неполадок?

Это просто еще одно проявление ошибки IIS, о которой я писал в этот ответ. Вы обнаружите, что перезагрузка исправляет это. А исправление доступен.

Различное поведение двух ваших сайтов может быть связано только с двумя разными идентификаторами пула приложений, под которыми они работают. Вы четко не упомянули идентичности рабочих и нерабочих бассейнов. «Этикетки» - это название пул приложений. Проверьте свойства пула, чтобы узнать, под каким идентификатором он работает, и сравните его с идентификатором унаследованного пула.

Из-за этой ошибки наши производственные сайты несколько раз выходили из строя, что сказывалось на клиентах. Поэтому я не считаю этот патч IIS 7.5 необязательным - поскольку Microsoft, похоже, подразумевает последние 4 года, отказываясь решать эту проблему через стандартный канал обновления. Заставить клиентов «обнаружить» эту ошибку из-за простоя производства возмутительно.