При доступі до бази даних заборонено доступ

Я використовую версію для розробників SQL Server 2008. Я намагався долучити до бази даних AdventureWorks2008.

Коли я намагався вкласти, я отримав помилку "доступ заборонено". Відповідно до журналу подій, він надходить з O / S:

Не вдалося відкрити: не вдалося відкрити файл D: \ ProjectData \ AdventureWorks \ AdventureWorksLT2008_Data.mdf для номера файлу 0. Помилка ОС: 5 (доступ заборонено.)

Я подумав, що "проблема NTFS", але System (і я) змінили доступ до обох файлів.

Я виявив, що можу успішно приєднати базу даних, якщо я ввійду як sa, але мій обліковий запис користувача не працюватиме.

Я є членом групи місцевих адміністраторів на своїй машині, і я перебуваю в ролі sysadmins в екземплярі SQL Server.

Будь-яка ідея, чому мені довелося ввійти як sa?

Запустіть SQL Server Management Studio в якості адміністратора. (клацніть правою кнопкою миші> запустити як адміністратор), яка подбала про всі дивацтва в моєму випадку.

SQL SRV EXPRESS 2008 R2. Windows 7

Дякую за всі коментарі. Деякі з вас допомогли привести мене до відповіді. Ось що я знайшов:

Це була проблема дозволу NTFS, а не проблема SQL. Крім того, це виглядає на зразок помилок (і це повторюється).

Проблема: Обліковий запис, який я використовував, мав дозволи NTFS повного контролю на файли mdf та ldf. Однак вони мали ці дозволи через членство в групі (група місцевих адміністраторів мала дозволи, а мій обліковий запис є членом місцевих адміністраторів). (Я перевірив дозволи)

Якщо я спробую зробити вкладення, підключитися до SQL Server як я (де я в групі адміністраторів), це не вдається з проблемою NTFS.

Однак, якщо я надаю ті ж дозволи для файлів, які має локальна група адміністратора, безпосередньо до мого облікового запису домену, я можу приєднатися без проблем.

(о, і так, я перевірив локальні групи на цій машині та переконався, що мій обліковий запис домену дійсно є членом локальної групи адміністраторів).

Таким чином, схоже, що помилка трапляється, оскільки деякий код (або в SQL Server, або в студії управління) перевіряє дозволи, які має обліковий запис користувача, але це не так далеко, щоб перевірити групові дозволи, які успадковує обліковий запис користувача.

Це звучить для мене дивно, але я можу відтворювати це знову і знову, тому я зробив висновок, що це відповідь.

Оновлення: я повідомив про це як про помилку: https://connect.microsoft.com/SQLServer/feedback/details/539703/access-denied-attaching-a-database-when-permissions-are-inherited

Я хотів би додати додаткову інформацію до опублікованих відповідей.

Будьте уважні під час від'єднання бази даних, оскільки користувач Windows, на якому ви ввійшли в систему, стає єдиним користувачем, який має права на .mdf-файл! Оригінал дозволу .mdf-файл, який включав користувача SQLServerMSSQLUser$<computer_name>$<instance_name>та акаунт адміністраторів, буде перезаписаний тим, хто користувач Windows, на який ви ввійшли (не користувач серверу sql). Бум, усі дозволи пішли просто так. Так само, як сказали інші, і клацніть правою кнопкою миші ваш .mdf-файл та двічі перевірте дозволи.

Я зіткнувся з цією проблемою, тому що використовував SSMS для підключення до бази даних (неважливо, який обліковий запис сервера sql) і від'єднав базу даних. Після цього мій користувач Windows був єдиним, хто мав будь-які дозволи на .mdf-файл. Тож пізніше, коли я намагався приєднати db за допомогою облікового запису sa, він викинув помилку "в доступі заборонено".

Щоб зберегти оригінальні дозволи в такті, вам слід відімкнути базу даних в режимі офлайн, потім від'єднати, а потім приєднати в такому порядку так:

USE [master]
GO
-- kick all users out of the db
ALTER DATABASE mydb
SET SINGLE_USER WITH ROLLBACK IMMEDIATE 
GO

-- Take the Database Offline
ALTER DATABASE mydb SET OFFLINE WITH
ROLLBACK IMMEDIATE
GO

-- detach the db
EXEC master.dbo.sp_detach_db @dbname = N'mydb'
GO

Додайте дозвіл у папку, де знаходиться ваш .mdfфайл.

Перевірте це ім'я: NT Service\MSSQLSERVER

І змініть ім'я Locationвашого сервера.

Ця проблема викликана UAC (Контроль облікових записів користувачів), чи не так? Незважаючи на те, що ваш обліковий запис користувача є членом групи адміністраторів, UAC в Windows 7 не дозволяє робити справи адміністратора, якщо ви не запустите програми "як адміністратор". Це не справжня помилка в SQL Server або Management Studio чи будь-якому іншому. (Хоча він, можливо, може знати проблему і попросити вас отримати підвищені дозволи, а не просто скаржитися на "помилку 5".)

Запустіть SQL Server Management Studio в якості адміністратора. (клацніть правою кнопкою миші> запустити як адміністратор) працював для мене з Windows 7 - SQL сервер 2008 R2

База даних SQL2005 може бути приєднана таким чином у Windows 7:

start menu >
 all program >
  Microsoft sql server 2005 >
   sql server management studio >
    right click >
     run as administrator >
      click ok

А потім додана база даних успішно завершена.

Коли ви saвходите в систему як (або будь-який обліковий запис сервера Sql), ви функціонуєте як обліковий запис служби SQL Server, коли ви входите в систему, як і ви, у вас є дозволи на ваш обліковий запис. Чомусь у вас немає відповідного доступу до файлів, але обліковий запис служби є.

Я знайшов таке рішення: Клацніть правою кнопкою миші папку, в якій ви зберігаєте .mdf-файл -> натисніть Властивості -> виберіть вкладку Безпека, натисніть Редагувати ... і надайте їй повний контроль. Сподіваюся, це допомагає!

saКористувач використовує NTFS рахунку SQLServerMSSQLUser$<computer_name>$<instance_name>і SQLServerSQLAgentUser$<computer_name>$<instance_name>доступ до файлів бази даних. Ви можете спробувати додати дозволи для одного або обох цих користувачів.

Я не знаю, чи вирішує вашу проблему, оскільки ви говорите, що у вас немає проблем з saкористувачем, але, сподіваюся, це допоможе.

Зі мною - Запуск у вікні 8 - RIght натисніть SQL Server Manager Studio -> Запуск з адміністратором. -> приєднати жодних проблем

це можна виправити легко, але радикально, просто перейдіть до папки, де ви зберегли mdf-файл . виберіть файл-> Клацніть правою кнопкою миші -> клацніть на властивості та надайте повні дозволи на файл для входу в систему Безпека користувача .

Кожен раз, коли я стикався з цією проблемою, був при спробі приєднати базу даних, яка знаходиться в іншому каталозі, ніж каталог за базами даних за замовчуванням, який налаштовано на SQL-сервер.

Я настійно рекомендую замість того, щоб вибирати дозволи на різні каталоги та облікові записи, ви просто перемістіть файл даних у каталог, який сервер sql очікує, що його знайдуть.

Я просто хотів також додати цю інформацію.

http://www.mssqltips.com/sqlservertip/2528/database-attach-failure-in-sql-server-2008-r2/

Рішення

Ви отримуєте цю помилку, оскільки два різні входи виконували операції по від'єднанню та приєднанню. Отже, коли файли від'єдналися, належав перший логін, але вкладення не вдалося, оскільки використовуваний логін не був власником файлів mdf та ldf.

Коли ми від'єднуємо файли баз даних, власник стає особою, яка виконала команду detach, тому для вирішення проблеми нам потрібно змінити або додати інший логін як власник файлів mdf та ldf.

Клацніть правою кнопкою миші на файл "filename.mdf" та виберіть властивості, щоб перевірити дозволи файлу mdf. Тут ми можемо побачити, що лише один обліковий запис має дозвіл на файл "filename.mdf", оскільки це був обліковий запис, який використовувався для від'єднання бази даних.

Щоб вирішити цю проблему, натисніть кнопку Додати ..., щоб додати інший логін або будь-який інший необхідний логін та дати повний контроль над входом. Ви повинні зробити це і для файлу "ldf". Після виконання цього завдання натисніть кнопку ОК. (Зауважте, що для інших версій ОС у вас може бути опція Редагування, натисніть її спочатку, і тоді ви побачите опцію Додати ...).

Для чого варто тому, хто має певну варіацію цієї проблеми, яку я мав:

• SQL Express 2008
• Visual Studio 2010 Premium

Через контекстне меню папки App_data я створив базу даних SQL Express для налагодження. Рядок з'єднання (використовується NHibernate) був таким:

Server=.\SQLExpress;
AttachDbFilename=|DataDirectory|DebugDatabase.mdf;
Database=DebugDatabase;
Trusted_Connection=Yes;

Це дало мені ту саму помилку "Доступ відмовлено" у файлі бази даних. Я спробував надати різним користувачам повний контроль папці та файлам, в один момент навіть "Усі". Ніщо не допомогло, тому я знову видалив додані дозволи.

Нарешті вирішили це відкрити Провідник сервера у Visual Studio, потім підключитися до MDF і знову від'єднати його. Після того, як я зробив це, щоб мій веб-додаток міг добре отримати доступ до бази даних.

PS. Кредити переходять до цієї публікації в блозі, яку я знайшов, переглядаючи цю проблему, викликаючи ідею приєднати / відключити базу даних, щоб вирішити проблему.

Я перемістив mdf бази даних із папки даних за замовчуванням у свою папку asp.net app_data і зіткнувся з цією проблемою, намагаючись повернути базу даних в Інтернет.

Я порівняв налаштування безпеки інших файлових баз даних у вихідному місці із переміщеними файлами та зауважив, що MSSQL $ SQLEXPRESS не присвоює дозволу файлам у новому місці. Я додав повний контроль для "NT SERVICE \ MSSQL $ SQLEXPRESS" (повинен включати цю службу NT SERVICE), і він додається просто чудово.

Здається, що в оригінальній папці "Дані" є ці дозволи, і файли успадковують їх. Переміщення файлів і перерви про спадкування звичайно.

Я перевірив mdf-файл іншого проекту, який я створив безпосередньо в його папці app_data. він не має дозволів MSSQL $ SQLEXPRESS. Хммм. Цікаво, чому SQL Express любить одне, а не інше?

Це звучить як дозвіл NTFS. Зазвичай це означає, що ваш обліковий запис служби SQL Server має доступ лише до читання до файлу (зауважте, що SQL Server використовує той самий обліковий запис служби для доступу до файлів бази даних незалежно від способу входу). Ви впевнені, що не змінили дозволи для папок між тим, як входити в систему як власний і входити як sa? Якщо ви від'єднаєтесь і спробуйте ще раз, чи все-таки виникає така ж проблема?

У мене була така ж проблема при приєднанні до бази даних. Це не проблема SQL, це проблема облікового запису. Перейдіть до пункту керування панелі / Налаштування керування обліковим записом користувача / встановіть "ніколи не повідомляти". Нарешті перезавантажте комп'ютер, і він працював на мене.

Я вклав файл mdf, клацнувши правою кнопкою миші базу даних та видаливши файл журналу AdventureWorks2012_Data_log.ldf у майстра. Файл mdf розміщувався в наступному місці

    C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\DATA

Вищеописаний метод допоміг мені вирішити проблему.

Я читав цю сторінку, і в них є цікаве речення:

Увага: Будьте дуже вибіркові, додаючи користувачів до цих ролей. Наприклад, sysadmin виводить на dbo у кожній базі даних і є еквівалентом входу в систему за допомогою облікового запису sa.

Звичайно, вони також мають таке:

Дозволи, які надаються користувачам і ролі, і залежать від бази даних. Усі дозволи є сукупними, за винятком DENY. Відмовлений дозвіл на рівні користувача або на рівні ролей перекриває той же дозвіл, наданий через інші членські ролі, за винятком фіксованої ролі сервера sysadmin. (Sysadmin зберігає всі дозволи, навіть якщо на роль, до якої вони входять, є дозвіл DENY.)

Отже, якщо ви адміністратор домену та в групі sysadmin 'SQL, світ повинен бути вашим ракоподібним.

Звичайно, на думку Microsoft, вам слід швидко ознайомитися з цими двома сторінками:
Посилання на передумови бази даних

Посилання на встановлення баз даних

Ви неслухняні і намагаєтеся приєднати їх вручну :) Хоча ви серйозно, чи є у вас всі передумови для бази даних AdventureWorks2008?
Я підозрюю, що це лише черговий випадок відхилення / крайності Microsoft, але я можу помилитися.

USE [master]
GO
CREATE DATABASE [DataBasename] ON 
( FILENAME = N'C:\data\DataBasename.mdf' )
 FOR ATTACH
GO

змінити на FOR ATTACH -> FOR ATTACH_FORCE_REBUILD_LOG

USE [master]
GO
CREATE DATABASE [DataBasename] ON 
( FILENAME = N'C:\data\DataBasename.mdf' )
 FOR ATTACH_FORCE_REBUILD_LOG
GO

Я отримав цю помилку як sa. У моєму випадку безпека бази даних не мала значення. Я додав всім повний контроль до файлів mdf та ldf, і додаток пройшло чудово.

Я зіткнувся з тією ж проблемою у VS 2019. Якщо хтось все ще стикається з тим самим питанням, то будь ласка, переконайтеся, що у вас є / виконайте такі дії:

1. У вас повинен бути встановлений SQL Express на вашому м / с
2. Якщо SSDT встановлений у VS (у VS 2019 - переконайтесь, що цей компонент перевіряється під час встановлення) на попередні версії - вам слід додати цей компонент зовнішньо
3. Додайте до рядка з'єднання "Користувальний екземпляр = Істинно"
4. Я думаю, що його необов'язково - відкрити VS та SQL Express в адміністративному режимі та увійти як адміністратор до SQL Express

Це насправді дозволи NTFS та дивна помилка в SQL Server. Я не впевнений, що наведений вище звіт про помилку є точним або може стосуватися додаткової помилки.

Щоб вирішити це в Windows 7, я звичайно запустив SQL Server Management Studio (не як адміністратор). Потім я спробував приєднати файл MDF. У процесі я скоріше використовував інтерфейс, а не вставляв його в шлях. Я помітив, що шлях відрізаний від мене. Це пояснюється тим, що користувач MS SQL Server (SQLServerMSSQLUser $ machinename $ SQLEXPRESS), який додає програмне забезпечення, не має дозволу на доступ до папки (у цьому випадку папка знаходиться в моїх власних папках користувача).

Вставлення контуру та подальший процес призводить до вищевказаної помилки. Отже - я дав користувачеві MS SQL Server дозволити читати, починаючи з першого каталогу, в якому йому було відмовлено (моя папка користувача). Потім я негайно скасував операцію розповсюдження, оскільки це може зайняти вічність, і знову застосував дозволи на читання до наступної підпапки, і дозволити цьому поширюватися повністю.

Нарешті, я дав користувачеві MS SQL Server Modify дозволи на файли .mdf та .ldf для db.

Тепер я можу приєднати до файлів бази даних.

Якщо ви запускаєте sql-сервер 2012, ви можете отримати цю помилку, намагаючись приєднати старішу версію mdf-файлу. ex mdf-файл із сервера sql 2008.

Я вирішив проблему, просто перемістивши .mdf-файл, який ви хочете приєднати до загальнодоступної папки, у моєму випадку я перемістив його до папки користувачів / public. Тоді я кріплю його звідти без жодних проблем. Сподіваюся, це допомагає.

Для тих, хто не зміг вирішити проблему з іншими рішеннями тут, для мене спрацювало таке виправлення:

Перейдіть у папку "DATA" у вашій установці SQL Server, клацніть правою кнопкою миші, вкладки "Властивості", "Захист" та додайте дозволу на повний контроль для користувача "NETWORK SERVICE".

http://decoding.wordpress.com/2008/08/25/sql-server-2005-expess-how-to-fix-error-3417/

(Наведене вище посилання призначене для SQL 2005, але для цього виправлена ​​установка SQL 2008 R2).

Деякі додаткові відомості: Ця проблема з’явилася для мене після заміни вторинного жорсткого диска (на якому було встановлено SQL). Я скопіював усі файли та відновив оригінальний лист диска на новий жорсткий диск. Однак дозволи безпеки не скопійовано. Думаю, наступного разу я скористаюся кращим методом копіювання даних.

У моєму випадку проблему вирішили наступні:

USE [master]
GO
CREATE DATABASE [AdventureWorks2008R2] ON
( FILENAME = 'C:\Program Files\Microsfot SQL Server\MSSQL10_50.SQLEXPRESS\MSSQL\DATA\AdventureWors2008R2_Data.mdf')
FOR ATTACH_REBUILD_LOG

Скопіюйте базу даних в іншу папку та вкладіть або увійдіть у систему SQLServer за допомогою "Автентифікації Windows"

У мене була така ж проблема при повторному приєднанні бази даних після її від'єднання та переміщення файлів ldf та mdf з диска C на F.

Для того, щоб виправити це, мені довелося додати до обох файлів головного права власника права і надав йому повний контроль над ними на вкладці Безпека діалогового вікна Властивості.