У меня есть два приложения ASP.NET, настроенных на доступ для чтения и записи к общему расположению NAS, которое они используют в качестве простого хранилища файлов с ключом.
Расположение NAS отображается локально для каждого приложения с помощью соединений каталогов NTFS, например:
C:\inetpub\App1\Content\files
C:\inetpub\App2\Content\files
Идея состоит в том, чтобы иметь путь относительно приложения, который не зависит от базового решения для хранения.
Он отлично работал, пока я не настроил каждое приложение для использования выделенных пулов приложений. Теперь файлы, созданные одним приложением, не читаются другим.
Изучив атрибуты безопасности файлов, созданных обоими приложениями, я заметил, что все вновь созданные файлы из любого приложения демонстрируют следующую аномалию:
Поскольку каждое приложение работает под собственной учетной записью IIS AppPool \ App #, это эффективно предотвращает чтение любых файлов, кроме тех, которые они создали сами.
Фактический код, создающий файлы, идентичен в обоих приложениях и не делает ничего особенного, кроме:
System.IO.FileStream объект, используя все параметры по умолчанию.Что меня озадачивает, так это тот факт, что IIS_IUSRS включен в число учетных записей с доступом, но не имеет всех основных разрешений, хотя родительская и корневая папки настроены на включение разрешений на чтение и запись в «этой папке, подпапках и файлах».
Что я упустил и как мне это решить?
Мне удалось решить проблему, просто добавив разрешения для обоих известных IIS AppPool\App# учетные записи в корневой каталог, в который монтируется NAS. Обратной стороной этого подхода является то, что любой дополнительный пул приложений в будущем также придется обрабатывать вручную.