hugeous
@hugeous

MSSQL Резервное копирование на сетевой ресурс завершается с ошибкой: Operating system error 5(Access is denied.), как победить?

Добрый день хабровчане.

Исходные данные:
Виртуальный сервер на ESXI 5.5
ОС:
Windows Server 2019 Std Core x64
Версия SQL сервера:
MS SQL Server 2017 x64

Время от времени возвращаюсь к вопросу настройки резервного копирования баз на сетевую шару, в своей песочнице, но никак не могу найти способ победить ошибку:
5ec014b76d6a3596005516.jpeg
Ясное дело, доменному пользователю выданы соответствующие права на сетевую папку, и сервис инстанции MSSQL стартует от имени данного доменного пользователя.
Скрин командной строки выполненной на самом сервере с упомянутой инстанцией MSSQL@MSSQL1C01:
5ec087a22b6d9402357565.jpeg
Свойства запуска указанного экземпляра MSSQL:
5ec086cc9707a716988328.jpeg
Прочел статью о похожем кейсе, но к сожалению методы в ней предложенные не помогли решить описанную ошибку.
Пожалуйста помогите разобраться с ситуацией.
Спасибо за время уделенное прочтению.
  • Вопрос задан
  • 76 просмотров
Решения вопроса 1
@mumische
Я дико извиняюсь, но вы не пробовали читать документацию?
https://docs.microsoft.com/ru-ru/sql/relational-da...
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
hugeous
@hugeous Автор вопроса
Добрый час хабровчане.

Вопрос решен, но обо всем по порядку.
Ну во-первых:
Поздравляю Шарик, ты балбес
Описанные исходные кейсы выполнялись не на том сервере что нужно, я просто перепутал открытые соединения в открытой SSMS, чтож, тупашить еще никто не отменял.
Теперь о возможных путях решения.
Для гибкости администрирования создал группу доступа в Active Directory, и на нужную шару выдал группе права.

Вариант 1.
Добавил учетную запись компьютера, на котором крутится инстанция MSSQL в группу доступа.
Имя пользователя запускающего службу MSSQL не менял, стандартно он выполняется от Local System.
5ec1d008359f7883422035.jpeg
Результат выполнения резервного копирования базы командой в SSMS: Success
Владелец созданного файла резервной копии на сетевой шаре: учетная запись компьютера
5ec1c83423a6d650085392.jpeg
Вариант 2.
Добавил учетную запись доменного пользователя в группу доступа, изменил пользователя от которого запускается инстанция MSSQL на этого же пользователя.
5ec1d06c5122a550483864.jpeg
Результат: Success
Владелец созданного файла на сетевой шаре: учетная запись указанного выше доменного пользователя.
5ec1c988a019f146928066.jpeg
З.Ы. При предоставлении доступа с использованием группы, необходимо, чтобы потребитель доступа выполнил релогин в Active Directory. Юзер - логофф, логон; ПК - рестарт. При назначении прав на шару напрямую, релогин не требуется. Как-то игрался с подобным кейсом и не мог понять почему не работает когда все назначено верно.

Для чистоты эксперимента вход на каждую из тестируемых инстанций MSSQL выполнялся с использованием локальной аутентификации SQL, и ясное дело, у такого пользователя не было доступа к используемой сетевой шаре.
Нет. Поскольку SSMS - это клиент, а не сервер, и действия выполняются от имени клиента.
Так что скорее данное предположение ошибочно.

Теперь осталось решить как поступить правильнее в контексте безопасности:
Использовать учетную запись ПК для доступа к шаре, или использовать учетную запись технологического пользователя сервиса MSSQL.

Большое спасибо всем кто не остался в стороне и принял участие в дискуссии.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы