← На главную

Рассмотрим достаточно распространенную, но сложную в диагностике ситуацию. Имеется распределенная рабочая среда: на первом компьютере пользователь открывает 1С через браузер (веб-клиент), на втором компьютере установлена сама платформа 1С:Предприятие и веб-сервер IIS, а на третьем компьютере в расшаренной сетевой папке лежит файл базы данных MS Access. При попытке считать информацию из этого файла через веб-клиент или тонкий клиент система выдает ошибку:

"Ошибка при вызове метода контекста (Open): Произошла исключительная ситуация (Microsoft Access Database Engine): Ядро СУБД Microsoft Access более не может открыть файл \\192.168.x.x\base\base.mdb или записать в него данные. Файл уже открыт другим пользователем для монопольного доступа, либо требуется разрешение на просмотр и запись данных."

При этом, если мы запустим Толстый клиент локально на втором сервере, данные загружаются без проблем. Откроем файл через обычный проводник — все работает. Выясним причину такого поведения и разберем по шагам, как правильно настроить веб-сервер и сетевой доступ (как вариант, можно изучить установку Apache HTTP Server на Windows). Для автоматической развертки веб-сервера можно использовать скрипт установки Apache HTTP Server на Windows.

Разберем отличия IUSR и пользователя пула приложений

Первое, что обычно проверяют системные администраторы — это права пользователя IUSR в IIS. Однако мы проанализируем архитектуру работы веб-сервера с 1С и поймем, что это неверный путь. Пользователь IUSR используется веб-сервером только для анонимного доступа к статичным страницам.

Серверный код 1С, который вызывает подключение через ADO, выполняется в контексте рабочего процесса сервера. В случае публикации на IIS этот процесс обслуживается Пулом приложений (Application Pool). По умолчанию пулу назначается локальная виртуальная учетная запись ApplicationPoolIdentity, NetworkService или LocalSystem. Именно от имени этой учетной записи идет обращение по сетевому пути.

Посмотрим на доступ к сети от имени учетной записи компьютера

Поскольку наш пул приложений IIS на втором ПК работает от локальной встроенной учетной записи, при попытке зайти в папку \\192.168.x.x\base\ запрос уходит в сеть не от имени вашего пользователя, а от имени учетной записи самого компьютера (в домене это ДОМЕН\Имя_Второго_ПК$).

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

Проанализируем специфику MS Access и файлы блокировок

Почему возникает сообщение, что файл открыт другим пользователем или нет прав? Разберем механизм работы драйвера Microsoft Access Database Engine. При любом подключении к файлу .mdb или .accdb драйвер пытается создать в этой же сетевой папке временный скрытый файл блокировок с расширением .ldb или .laccdb.

Если у учетной записи IIS есть права только на чтение и изменение самого файла базы данных, но нет прав на создание новых файлов в самой директории, драйвер не сможет создать этот файл блокировки. В результате он прерывает операцию и возвращает ошибку о нехватке разрешений или блокировке. Следовательно, права нужно давать на всю папку (изменение, чтение, запись и создание файлов).

Разберем проблему двойного прыжка (Double-Hop Issue)

Рассмотрим еще один важный архитектурный нюанс — "двойной прыжок" (Double-Hop) при использовании Windows-аутентификации. Если пользователь заходит в веб-клиент на ПК 1, и IIS (ПК 2) авторизует его сквозным методом по протоколу NTLM, то сервер IIS не имеет права передать этот NTLM-токен дальше по сети на ПК 3 для доступа к папке. Третий компьютер отклонит такой запрос как анонимный.

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

Проверим разрядность драйверов (32-bit vs 64-bit)

Обратим внимание на то, что Толстый клиент чаще всего является 32-битным приложением, а сервер 1С и веб-сервер IIS на современных ОС работают в 64-битном режиме. Если на сервере с IIS установлен только 32-битный OLE DB провайдер MS Access, он не сможет корректно работать из 64-битного пула.

Пошаговое решение проблемы

Сведем все полученные данные в единый алгоритм действий. Выполним следующие шаги для настройки корректного сетевого доступа:

1. Создадим в сети (в Active Directory или локально на 2-м и 3-м ПК с идентичными паролями) выделенную сервисную учетную запись. Назовем ее, например, 1c_web_user.
2. Перейдем на третий ПК (где лежит база MS Access) и откроем свойства расшаренной папки base.
3. На вкладке "Доступ" (Share Permissions) и на вкладке "Безопасность" (NTFS Permissions) добавим пользователя 1c_web_user и предоставим ему полные права (или как минимум права на чтение, запись, изменение и создание файлов).
4. Перейдем на второй ПК (сервер IIS). Откроем Диспетчер служб IIS (Internet Information Services Manager).
5. В левом меню выберем раздел "Пулы приложений" (Application Pools) и найдем пул, обслуживающий нашу опубликованную базу 1С.
6. Зайдем в "Дополнительные параметры" (Advanced Settings) этого пула.
7. Найдем параметр "Удостоверение" (Identity). По умолчанию там стоит ApplicationPoolIdentity. Изменим это значение: выберем "Особая учетная запись" (Custom account) и введем логин и пароль созданного нами 1c_web_user.
8. Если на сервере IIS установлен только 32-битный драйвер MS Access, там же в дополнительных параметрах пула изменим параметр "Разрешить 32-разрядные приложения" (Enable 32-Bit Applications) на значение True.
9. Перезапустим веб-сервер IIS и проверим работу загрузки из веб-клиента.

Выполнив эту настройку, мы переведем процесс веб-сервера в контекст конкретного пользователя, который обладает полноценными сетевыми правами для работы с файлами .mdb и создания файлов блокировок .ldb, полностью исключив проблему "двойного прыжка" и анонимного доступа.