← На главную

При администрировании серверов 1С:Предприятие системные администраторы часто сталкиваются с ситуацией, когда при создании новой информационной базы через консоль администрирования 1С файлы базы данных (MDF) и логов (LDF) создаются не в том каталоге, который был указан в параметрах, а в стандартном пути установки MS SQL Server. Проанализируем ситуацию: это происходит не из-за ошибки в самой 1С, а из-за особенностей взаимодействия сервера приложений с СУБД и прав доступа в операционной системе Windows.

Разберем основную причину: Глобальные настройки SQL Server

Первым делом рассмотрим настройки самого SQL-сервера. Если в параметрах экземпляра жестко заданы пути по умолчанию, SQL Server может игнорировать команды от внешних приложений (включая 1С), если в запросе на создание базы есть неопределенность или если прав текущего пользователя недостаточно для записи в альтернативный каталог.

Чтобы проверить и изменить эти настройки, выполним следующие шаги:

1. Запустим SQL Server Management Studio (SSMS) и подключимся к нужному экземпляру.
2. Нажмем правой кнопкой мыши на корень сервера и выберем пункт Свойства (Properties).
3. Перейдем в раздел Настройки базы данных (Database Settings).
4. В нижней части окна проанализируем поля «Места хранения данных по умолчанию» (Data) и «Лог» (Log). Если вы хотите, чтобы базы создавались в определенном месте, укажите эти пути здесь.

Выясним причину конфликта прав доступа (Service SID)

Часто проблема кроется в том, что у службы SQL Server нет физических прав на запись в ту папку, которую вы указываете в консоли 1С. Посмотрим, как правильно назначать права. В современных версиях Windows Server использование конкретных доменных имен или локальных пользователей для назначения прав на папки считается менее надежным методом, чем использование Service SID (виртуальных учетных записей служб).

Вместо того чтобы добавлять в права папки пользователя sql_user, попробуем добавить виртуальный объект:

• Для стандартного экземпляра SQL: NT SERVICE\MSSQLSERVER
• Для именованного экземпляра: NT SERVICE\MSSQL$ИМЯ_ЭКЗЕМПЛЯРА

Преимущество этого подхода в том, что даже если вы измените учетную запись, под которой запускается служба в services.msc, права доступа к папкам сохранятся за самой «сущностью» службы.

Проанализируем проблему «битых SIDs» после клонирования сервера

Если ваш сервер был получен путем клонирования виртуальной машины или копирования диска, вы почти наверняка столкнетесь с проблемой недействительных идентификаторов безопасности. Обратим внимание на симптом: в свойствах безопасности папки вы видите пользователя с длинным именем из цифр и тире (например, S-1-5-21-...), а рядом иконку с вопросительным знаком. Это «мертвый» SID со старого сервера.

Разберем по шагам, как это исправить:

1. Удалим все неизвестные учетные записи из разрешений целевой папки, где должны лежать базы 1С.
2. Выясним, от чьего имени работает процесс sqlservr.exe через Диспетчер задач (вкладка «Подробности»).
3. Добавим этого пользователя (или Service SID, как описано выше) в список разрешений с правами «Полный контроль».

Как правильно сменить пользователя службы SQL Server

В обсуждении упоминалось, что при попытке сменить пользователя через стандартную оснастку Windows services.msc, служба перестает запускаться. Выясним причину: при смене пользователя через обычные «Службы», Windows не обновляет права доступа к веткам реестра и системным базам данных SQL (master, model, msdb).

Для корректной смены пользователя рассмотрим использование специальной утилиты:

1. Откроем SQL Server Configuration Manager.
2. Выберем раздел SQL Server Services.
3. Нажмем правой кнопкой на службу SQL Server и выберем Properties.
4. На вкладке Log On укажем нового пользователя.

Именно этот способ автоматически пропишет все необходимые разрешения в реестре и файловой системе для новой учетной записи, и служба запустится без ошибок.

Роль агента сервера 1С:Предприятие

Не забудем, что инициатором создания базы является сервер 1С. Проанализируем ситуацию, когда SQL не может выполнить команду из-за ограничений безопасности. Важно, чтобы учетная запись, под которой запущен «Агент сервера 1С:Предприятие 8.3» (процесс ragent.exe), имела право на имитацию клиента.

Для этого выполним настройку в локальных политиках безопасности (secpol.msc):

1. Перейдем в Локальные политики -> Назначение прав пользователя.
2. Найдем пункт Impersonate a client after authentication (Имитация клиента после проверки подлинности).
3. Добавим туда пользователя, под которым работает сервер 1С.

Исключаем технические ограничения файловой системы

Напоследок проверим параметры самого диска. SQL Server накладывает определенные ограничения на файловую систему:

• Убедимся, что папка назначения не является сжатой средствами NTFS. SQL Server не поддерживает работу с базами данных на сжатых томах.
• Проверим наличие дисковых квот. Если для пользователя службы SQL установлена квота на объем данных, создание файла базы может прерваться, и система «откатится» к стандартному пути.

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