Mysql отказано в доступе windows

Обновлено: 07.07.2024

Я недавно установил MySQL 5 на Windows 2003 и попытался настроить экземпляр. Все работало нормально, пока я не добрался до "применения настроек безопасности", после чего он дал мне вышеуказанную ошибку ( Can't connect to MySQL server on 'localhost' (10061) ).

У меня есть исключение порта 3306 в моем брандмауэре для "MySQL Server".

вам, вероятно, придется предоставить привилегии "localhost" в таблице пользователю. Смотрите 'GRANT' синтаксис документации. Вот пример (из какого источника).

"предоставить все привилегии на %s.* для'%s'@ 'localhost', идентифицированного '%s'";

Это самая распространенная проблема с MySQL.

кроме этого, вы можете проверить, что пользователь, которого вы определили для создания вашего экземпляра, имеет полные права, иначе пользователь не может предоставлять привилегии.

кроме того, убедитесь, что служба mysql запущена.

убедитесь, что у вас не включен сторонний брандмауэр или Служба безопасности Интернета.

попробуйте прочитать это.

получил эту ошибку на Windows, потому что мой mysqld.exe не работал.

побежал "C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld" --install из командной строки, чтобы добавить его в мои службы, запустите службы.msc (start -> run), нашел службу MySQL и запустил ее.

не пришлось беспокоиться об этом оттуда.

  1. идем в Диспетчер задач
  2. выберите вкладку Услуги
  3. найти службу MySql
  4. под управлением

У меня были трудности с доступом к MySQL при подключении через соединение localhost на стандартном порту 3306, который отлично работал, когда я установил и настроил его для предыдущих классов, которые я взял в MySQL и Java. Я получал ошибки, такие как" ошибка 2003 "и"не удается подключиться к серверу MySql на localhost (10061)". Я попытался подключиться как из MySQL Workbench (5.2.35 CE), так и из Netbeans (7.2). Я использую Windows 7 64 bit professional.

Я попытался ввести службы.msc в самом начале окно поиска меню, которое открыло диалоговое окно службы, чтобы показать все службы, установленные в windows. Я прокрутил вниз к MySQL и запустил эту службу. Последующие попытки подключиться к MySQL из MySQL WorkBench и из командной строки завершились успешно.

  1. убедитесь, что ваш хост-файл windows (расположен по адресу c://windows/system32/drivers/etc.host ) имеет следующие линии. Если нет, добавьте его в конце

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

Я попробовал решение Kuzhichamadam Inn и обнаружил, что необходимо внести небольшое изменение.

MYSQL57 был сетевой службой. Я пробовал это неоднократно без успеха. Когда я открыл службы.msc я нашел другой сервис для localhost: MySQL. Я начал это с помощью процесса ниже, и это сработало.

выполнить > Services.МСЦ > правой кнопкой мыши по MySQL > "свойства" >в начало

пресс клавиша Windows + R напишите " услуги.МСЦ" введите ищите "MYSQL56" напишите нажмите на нее и Запустите сервис

для локального подключения к MySql , вам не нужно настраивать брандмауэр с входящими правилами. Но даже если вы уже установка iptables разрешить TCP входящий порт 3306 и предоставить привилегию пользователю для доступа к БД локально, вы, возможно, придется настроить адрес привязки в вашем my.cnf файл, отредактируйте там адрес по умолчанию и поместите IP-адрес сервера, на котором работает MySql сервис.

после перезагрузки компьютера

At cmd

станет

тип mysql -u root -p

ie C:\Program Files\MySQL\MySQL Server 5.7\bin> mysql -u root -p

введите пароль: ****

вот и все

это приведет к

Я получил эту ошибку, когда у меня закончилось место на моем диске.

на выполнить тип services.msc. проверьте, работают ли Службы MySQL. Если нет, запустите его вручную. После его запуска введите MySQL Show для тестирования сервиса.

другая возможность:

существует два способа подключения клиента MySQL к серверу: через TCP/IP или с помощью сокетов. Возможно, у вас есть сервер MySQL, настроенный для поддержки сокетных соединений, но не сетевых соединений.

ничего не делать просто "сбросить по умолчанию" настройки брандмауэра он начнет работать.

Я прочитал много решений, но ничего не работало должным образом, поэтому, наконец, я сбросил настройки брандмауэра, которые работали.

наконец-то решил эту проблему.. попробуйте запустить mysql в xammp. Флажок mysql в xammp должен быть снят. тогда начинай. после этого вы можете открыть mysql, и теперь он будет подключаться к localhost

Так как я боролся и нашел немного другой ответ вот он:

недавно я переключил локальный сервер (интрасеть) на своем новом рабочем месте. Установлена лампа; Debian, Apache, MySql, PHP. Пользователи на работе подключают сервер с помощью имени хоста, позволяет называть его "intaserv". Я настроил все, получил его работу, но не смог подключить Мой MySql удаленно, что бы я ни делал.

Я нашел свой ответ после бесконечных попыток, хотя. вы можете иметь только один привязать-адрес и он не может быть имя хоста, в моем случае "интранет".

Это должен быть IP-адрес, например. "bind-address=192.168.0.50".

В феврале этого года Света Смирнова (ведущий инженер компании Percona) провела вебинар, посвященный решению проблем с правами доступа в MySQL. Запись и слайды с вебинара доступны здесь. Предлагаем вашему вниманию небольшой обзор самых популярных вопросов на эту тему.

Какие права нужно давать пользователю root@localhost: ALL или Super? Включают ли права All и Super права тоже?

У вас обязательно должен быть пользователь с полными правами. Лучше, если у этого пользователя будет доступ только из localhost. Права ALL включают права SUPER.


Да, можно. Но похоже, я недостаточно разъяснила, что такое кэш хоста. Это внутренняя структура, которая всегда доступна и содержит ответы от DNS-сервера. Вы не можете включить его или выключить. До версии 5.6 вы также не могли контролировать его. К примеру, если кэш оказался поврежден, единственное, что вы могли сделать — это перезапустить сервер. В версии 5.6 таблица HOST_CACHE была представлена в Performance Schema. С помощью этой таблицы вы можете проверить содержимое кэша хоста и, при необходимости, очистить его.

Если в таблице пользователей имеется несколько записей, которые соответствуют подключаемому пользователю (например, через шаблоны, имя хоста и IP), по каким правилам MySQL выбирает, какая из них будет использоваться для аутентификации? Будет ли он проверять каждую, пока не получит совпадение пароля?

Нет, mysqld не пытается взломать ваши пароли. Вместо этого он сортирует таблицу пользователей по имени и хосту в порядке убывания, как показано на слайде №37 (стр. 110). Затем он берет первую подходящую строку. То есть, если вы создали пользователей foo@somehost, foo@some% и foo@1.2.3.4, а подключаетесь как foo из somehost, mysqld сначала проверяет имя пользователя, а затем выбирает первую подходящую строку foo@somehost. Если вместо этого вы подключаетесь как foo от someotherhost, mysqld выбирает foo@some%. Хост на базе IP выбирается, либо если mysqld запущен с опцией skip-networking, либо если 1.2.3.4 указывает на хост, чье имя не начинается с «some».

Смешивание хостов на основе IP с хостами на основе имен опасно в ситуациях, когда один и тот же хост может быть принят и как somehost, и как 1.2.3.4. В этом случае, если что-то пойдет не так с кэшем хоста или DNS-сервером, может быть выбрана неправильная запись из таблицы пользователей. Допустим, первоначально у вас было три хоста: uniquehost (который преобразовывается как 1.2.3.4), somehost (который преобразовывается как 4.3.2.1) и someothershost (который преобразовывается как 4.3.2.2). Теперь вы решили переместить uniquehost на машину с IP 1.2.3.5 и использовать IP 1.2.3.4 для хоста с именем someyetanotherhost. В этом случае клиенты с машины с IP 1.2.3.4 будут рассматриваться как foo@some%, а это совсем не то, что вы хотели.

Чтобы продемонстрировать этот случай, я создала двух пользователей и выдала им два разных набора прав:


Затем я изменила файл /etc/hosts и указала адрес 192.168.0.4 для имени Thinkie:


Теперь если я подсоединюсь как sveta, и Thinkie, и 192.168.0.4 будут преобразованы в один и тот же хост:


После этого я изменила файл /etc/hosts и снова привязала Thinkie к 127.0.0.1 (localhost):


Но хост 192.168.0.4 по-прежнему преобразовывается в Thinkie:


Причиной этого является устаревший кеш хоста, что хорошо видно в Performance Schema:


После очистки таблицы host_cache числовой хост преобразовывается так, как я ожидаю:


Какие права требуются не root и не super пользователю, чтобы использовать mysqldump для сброса базы данных и последующего ее восстановления на другом сервере?

Как правило, вы должны иметь права SELECT для всех объектов, которые вы собираетесь сбросить. Если вы сбрасываете представления, у вас также должны быть права SHOW VIEW для запуска SHOW CREATE TABLE. Если вы хотите сбросить хранимые процедуры/события, вам также нужен доступ к ним. Если вы используете опцию --lock-tables или --lock-all-tables, у вас должны быть права LOCK.

Если в MySQL достигнуто значение max_connection, может ли залогиниться root@localhost с правами ALL или пользователь с правами Super?

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

Можно ли удалить привилегию на более низком уровне? Другими словами, разрешить выбирать и удалять на уровне базы данных, но запретить удаление для конкретной таблицы? Или привилегии можно только добавлять?

Нет, MySQL отклонит такой запрос:


Каким образом можно организовать пользовательские роли… в виде группы грантов для конкретной роли?

У вас есть несколько вариантов:

  1. Использовать MariaDB 10.0.5 или новее. Вы можете почитать о поддержке ролей в MariaDB здесь.
  2. Использовать MySQL 8.0. Почитать о ролях в MySQL 8.0 можно здесь.
  3. С помощью MySQL 5.7: имитировать роли так, как я показала на слайде 19 (стр. 53-60).
  4. С помощью MySQL 5.5 и 5.6: использовать тот же метод, что на слайдах, но применить плагин кастомной аутентификации, поддерживающий прокси-пользователей.
  5. Всегда: создать шаблон с правами, назначить права для каждого пользователя вручную.

Я бы удалила прокси-пользователя и создала роль с теми же правами, а затем назначила прокси-пользователю эту новую роль вместо PROXY.

Существует ли плагин для интеграции Active Directory и MySQL, чтобы использовать группы Active Directory?

Существует коммерческий плагин аутентификации Windows Authentication Plugin, доступный в версиях 5.5 и новее. Вы также можете использовать плагин аутентификации с открытым исходным кодом Percona PAM authentication plugin и подключить его к Active Directory так же, как это делается для LDAP. Есть статья, в которой описывается, как это сделать, но я сама никогда не использовала этот метод.

Можно ли использовать централизованную аутентификацию в MySQL?

Да, с помощью плагина PAM. Есть инструкции для LDAP и Active Directory. Вы можете использовать аналогичные методы для установки других видов аутентификации, таких как Kerberos.



Друзья, если работа с MySQL является для вас ежедневной задачей, обязательно приезжайте к нам на PG Day'17 Russia. Света Смирнова, Петр Зайцев и другие специалисты компании Percona готовят для вас увлекательные доклады и мастер-классы об устройстве и функционировании MySQL в рамках секции, посвященной базам данных с открытым исходным кодом.

Если при попытке подсоединения к серверу MySQL вы сталкиваетесь с ошибкой Access denied , то воспользуйтесь приведенным ниже списком. В нем перечислены меры, которые можно принять для решения этой проблемы:

Запускали ли вы после инсталляции MySQL скрипт mysql_install_db для установки начального содержимого таблиц привилегий? Если нет, сделайте это. Обратитесь к разделу Задание изначальных привилегий MySQL. Проверьте первоначальные привилегии с помощью следующей команды:

Подсоединение должно произойти без сбоя. Следует также убедиться, что в каталоге базы данных MySQL имеется файл user.MYD . Обычно он находится в директории PATH/var/mysql/user.MYD , где PATH - путь к корневому каталогу инсталляции MySQL.

После новой инсталляции следует подсоединиться к серверу и создать пользователей, а также установить для них права доступа:

Сервер разрешит подсоединение, т.к. пользователь MySQL с именем пользователя root исходно не имеет пароля. Но в этом заключается также и риск нарушения безопасности системы, поэтому при создании остальных пользователей MySQL, вам, помимо прочего, следует задать пароль для пользователя root . Если при попытке подсоединения от имени пользователя root вы получите следующую ошибку:

это означает, что в таблице user отсутствует запись со значением 'root' в столбце User и mysqld не может определить имя хоста для вашего клиента. В этом случае необходимо перезапустить сервер с опцией --skip-grant-tables и отредактировать файл /etc/hosts или \windows\hosts , добавив в него запись для вашего хоста.

Если вы столкнетесь с такой ошибкой, как:

это означает, что используется неверный пароль. Обратитесь к разделу Задание паролей. Если вы забыли пароль для пользователя root , то перезапустите mysqld с опцией --skip-grant-tables и измените пароль. Обратитесь к разделу Как переустановить забытый пароль пользователя root. Такая ошибка может появляться даже в том случае, если вы не задавали пароля вообще - это значит, что в каком-то файле my.ini имеется неверный пароль. Обратитесь к разделу Файлы параметров my.cnf. Отменить использование файлов опций можно с помощью опции the --no-defaults , как показано ниже:

Запускали ли вы скрипт mysql_fix_privilege_tables при обновлении имеющейся инсталляции MySQL, если установленная версия - более ранняя, чем 3.22.11, а обновляется она до 3.22.11 или более поздней? Если нет, сделайте это. Начиная с MySQL 3.22.11, когда оператор GRANT стал функциональным, структура таблиц привилегий изменилась.

Если во время сеанса ваши привилегии изменились, то, возможно, их изменил суперпользователь. Перезагрузка таблиц привилегий отражается не только на новых подсоединениях клиентов, но также на уже имеющихся, как это показано в разделе Когда изменения в привилегиях вступают в силу.

Если не удается добиться, чтобы пароль работал, помните, что функция PASSWORD() должна использоваться, если вы задаете пароль с помощью операторов INSERT , UPDATE или SET PASSWORD . Если же вы задаете пароль с помощью оператора GRANT . INDENTIFIED BY или команды mysqladmin password , функция PASSWORD() не нужна. Обратитесь к разделу Задание паролей.

localhost - это синоним имени вашего локального хоста, и, если хост явно не задан, также устанавливаемое по умолчанию имя хоста, к которому клиенты пытаются подключиться. Однако подсоединения к localhost не действуют, если в вашей рабочей системе используются MIT-потоки и MySQL старше версии 3.23.27 (подсоединения к localhost осуществляются с использованием сокетов Unix, а они не поддерживались тогда технологией MIT-потоков). Чтобы в таких системах эта проблема не возникала, следует явным образом задать имя серверного хоста с помощью опции --host . Таким образом будет установлено подсоединение к серверу mysqld по протоколу TCP/IP. В этом случае в записях таблицы user , хранящейся на серверном хосте, должно быть указано реальное имя хоста. (Это справедливо даже для тех случаев, когда клиентская программа и сервер запускаются на одном хосте).

Если при попытке подсоединения к базе данных с помощью команды mysql -u user_name db_name возникает ошибка Access denied , причина этого, возможно, кроется в таблице user . Чтобы проверить это, выполните команду mysql -u root mysql и введите следующий SQL-оператор:

В результате будет выведена запись со столбцами Host и User , соответствующими имени вашего компьютера и вашему имени пользователя MySQL.

В Linux причиной такой ошибки может быть то, что бинарная версия MySQL скомпилирована с версией glibc, отличной от используемой вами. В этом случае нужно будет либо обновить ОС/glibc, используемые вами, либо загрузить исходный код MySQL и скомпилировать сервер самостоятельно. Как правило, исходный RPM компилируется и инсталлируется элементарно, так что это не составит серьезной проблемы.

то это означает, что ошибка возникает при попытке MySQL сопоставить IP-адрес с именем хоста. В этом случае вы можете выполнить команду mysqladmin flush-hosts , чтобы сбросить внутреннюю кэш-память DNS. Обратитесь к разделу Как MySQL использует DNS. Вот некоторые способы решения этой проблемы:

Попробуйте выяснить, что не так с вашим сервером DNS, и устраните неисправность.

Задайте IP-адреса вместо имен хостов таблицах привилегий MySQL.

Запустите mysqld с опцией --skip-name-resolve .

Запустите mysqld с опцией --skip-host-cache .

Подключитесь к localhost если ваш сервер и клиент работают на одном и том же компьютере.

Поместите имена клиентских машин в каталог /etc/hosts .

Если команда mysql -u root test работает успешно, а команда mysql -h your_hostname -u root tes t приводит к ошибке Access denied , то, возможно, в таблице user имя вашего хоста указано неверно. Одна из распространенных проблем здесь заключается в том, что в поле Host записи, хранящейся в таблице user , задается только имя хоста, в то время как процедуры разрешения имен, используемые вашей системой, возвращают полностью определенное доменное имя (или наоборот). Например, если в таблице user имеется запись со значением 'tcx' в поле host , а DNS при этом сообщает MySQL, что имя хоста - 'tcx.subnet.se' , эта запись действовать не будет. Попробуйте добавить в таблицу user запись, указав в колонке Host IP-адрес хоста. (В качестве альтернативы можно добавить в таблицу user запись со значением в поле Host , содержащим шаблонный символ, например 'tcx.%' . Но использовать имена хостов, оканчивающиеся на '%' - небезопасно и делать это не рекомендуется!)

Если команда mysql -u user_name test работает успешно, а команда mysql -u user_name other_db_nam e - нет, то в таблице db нет записи, соответствующей other_db_name .

Если не удается выяснить причину ошибки Access denied , удалите из таблицы user все записи, в которых значение в поле Host включает шаблонные символы (записи, содержащие символы ' '%' ' или ' '_' '). Очень распространенной ошибкой является следующая: пользователь вставляет новую запись со значением '%' в поле Host и со значением 'some user' - в поле User , полагая, что после этого для подсоединения с той же самой машины он сможет использовать localhost . Такой расчет неверен, и причина здесь в том, что устанавливаемые по умолчанию привилегии включают запись со значением 'localhost' в поле Host и пустым полем User . И поскольку в этой записи значение 'localhost' более конкретно, чем '%', то именно она при подсоединении с localhost предшествует новой записи и, соответственно, будет выбрана и сработает! Правильным в этом случае будет вставить вторую запись со значением 'localhost' в поле Host и значением 'some_user' - в поле User или удалить запись со значением 'localhost' в поле Host и пустым полем User .

Если вы получите следующую ошибку, то эта проблема, возможно, связана с таблицей db или таблицей host :

Если в записи, выбранной из таблицы db , столбец Host - пустой, удостоверьтесь, что в таблице host имеется по крайней мере одна соответствующая запись, указывающая, к каким хостам относится запись из таблицы db . Если ошибка возникает при выполнении SQL-команды SELECT . INTO OUTFILE или LOAD DATA INFILE , то в вашей записи из таблицы user , вероятно, отсутствует разрешение на предоставление привилегии FILE .

Помните, что клиентские программы будут использовать параметры подсоединения, указанные файлах конфигурации или переменных окружения. Обратитесь к разделу Переменные окружения. Если есть подозрение, что клиент отсылает неверные устанавливаемые по умолчанию параметры подсоединения, в случае, когда вы не задаете их в командной строке, проверьте ваше окружение и файл my.cnf в своей домашней директории. Можете также проверить конфигурационные файлы MySQL относящиеся ко все системе, хотя параметры клиентского подсоединения вряд ли указаны именно здесь. Обратитесь к разделу Файлы параметров my.cnf. Если ошибка Access denied возникает при выполнении вашей клиентской программы без каких-либо опций, убедитесь, что ни в одном из ваших файлов опций не указан старый пароль! Обратитесь к разделу Файлы параметров my.cnf.

Если вы вносите изменения в таблицы привилегий непосредственно (с помощью операторов INSERT или UPDATE ), а ваши изменения, похоже, игнорируются, то следует выдать оператор FLUSH PRIVILEGES или выполнить команду mysqladmin flush-privileges - для того, чтобы заставить сервер перечитать таблицы привилегий. В противном случае ваши изменения вступят в силу лишь при последующем перезапуске сервера. Помните, что после того, как вы зададите пароль от имени пользователя, вам нужно будет указывать его только после сброса привилегий, т.к. серверу еще не будет известно о том, что вы изменили пароль!

При возникновении проблемы с доступом при использовании Perl-, PHP-, Python- или ODBC-программ, попробуйте установить соединение с сервером при помощи команды mysql -u user_name db_name или команды mysql -u user_name -pyour_pass db_name . Если ваш клиент mysql обеспечивает подсоединение, то проблема связана не с привилегиями доступа, а с вашей программой. (Заметим, что между -p и паролем пробела нет; для задания пароля можно также использовать синтаксическую структуру --password=your_pass . Если вы используете только саму опцию -p , MySQL запросит у вас пароль)

При тестировании запускайте демон mysqld с опцией --skip-grant-tables . Тогда вы сможете изменять таблицы привилегий MySQL и с помощью скрипта mysqlaccess проверять, произвели ли сделанные вами изменения желаемый эффект. Если результаты вас устраивают, выполните команду mysqladmin flush-privileges , чтобы приказать серверу mysqld приступить к использованию новых таблиц привилегий. Внимание : перезагрузка таблиц привилегий отменяет опцию --skip-grant-tables . Это позволяет заставить сервер приступить к использованию новых таблиц привилегий без завершения его работы и перезагрузки.

Если ничего не помогает, запустите демон mysqld daemon с опцией отладки (например --debug=d,general,query ). В результате будет выведена информация о неудачных подсоединениях, с указанием хоста и пользователя, а также обо всех обработанных командах. Обратитесь к разделу Создание трассировочных файлов.

Если у вас имеется какая-либо проблема с таблицами привилегий MySQL и вы полагаете, что необходимо сообщить о ней в список рассылки, нужно обязательно приложить к своему отчету распечатку таблиц привилегий MySQL. Это можно сделать с помощью команды mysqldump mysql . Отчет о проблеме, как и в других случаях, отправляется с помощью скрипта mysqlbug . Обратитесь к разделу Как отправлять отчеты об ошибках или проблемах. В некоторых случаях для выполнения скрипта mysqldump возможно, потребуется перезапустить mysqld с опцией --skip-grant-tables .

Я использую SQL Server 2008 developer edition. Я пытался подключить базу данных AdventureWorks2008.

когда я попытался подключиться, я получил ошибку "доступ запрещен". Согласно журналу событий, он пришел из O/ S:

открыть не удалось: не удалось открыть файл D:ProjectDataAdventureWorksAdventureWorksLT2008_Data - . mdf для файла номер 0. Ошибка ОС: 5 (Доступ запрещен.).

Я думал, что "проблема NTFS", но система (и я) имеют изменить доступ к файлам.

Я обнаружил, что могу успешно присоединить базу данных, если я войду в систему как 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, либо в Management Studio) проверяет разрешения, которые содержит учетная запись пользователя, но он не заходит так далеко, чтобы проверить разрешения группы, которые наследует учетная запись пользователя.

Это звучит странно для меня, но я могу воспроизводить его снова и снова, поэтому я пришел к выводу, что это ответ.

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

будьте осторожны при отсоединении базы данных потому что пользователь windows вы вошли в систему как становится единственным пользователем с разрешениями .файл mdf! Исходные разрешения .файл mdf, который включал пользователя SQLServerMSSQLUser$<computer_name>$<instance_name> и учетная запись администратора перезаписывается тем пользователем windows, который вошел в систему как (не пользователь sql server). Бум, все разрешения ушли просто как это. Так что делайте, как сказали другие, и щелкните правой кнопкой мыши .файл MDF и дважды проверьте разрешения.

я столкнулся с этой проблемой, потому что я использовал SSMS для подключения к базе данных (не имеет значения, какая учетная запись sql server) и отсоединил базу данных. После этого мой пользователь windows был единственным, у которого были какие-либо разрешения .файл mdf. Поэтому позже, когда я попытался подключить БД с помощью учетной записи sa, он выбросил ошибку "отказано в доступе".

сохранить оригинальный разрешения в tact вы должны отключить базу данных, затем отсоединить, а затем прикрепить в таком порядке:

добавить разрешение в папку, где ваш Это.

проверьте это имя: NT Service\MSSQLSERVER

, и Location на имя сервера.

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

запустите SQL Server Management Studio от имени администратора. (правая кнопка мыши-> Запуск от имени администратора) работал для меня с Windows 7 к SQL серверу 2008 Р2

база данных SQL2005 может быть присоединена таким образом в Windows 7:

и затем подключенная база данных успешно завершена.

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

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

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

со мной - Работает на window 8 - Щелкните правой кнопкой мыши SQL Server Manager Studio - > выполнить с администратором. - >прикрепить нет проблем

может быть исправлено easly но radicaly, просто перейдите в папку, где у вас хранятся файл mdf. выберите файл - > щелкните правой кнопкой мыши - > нажмите на свойства и дайте полные разрешения на файл для входа в систему безопасности пользователя.

Я нашел это решение: щелкните правой кнопкой мыши на папке, где вы храните свой .mdf файл --> нажмите Свойства --> выберите вкладку Безопасность, нажмите Изменить. и дайте ему полный контроль. Надеюсь, это поможет!

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

Я настоятельно рекомендую вместо взлома с разрешениями на различные каталоги и учетные записи просто переместить файл данных в каталог, который sql server ожидает найти.

Я просто хотел добавить эту информацию.

вы получаете эту ошибку, потому что две разные логины сделали операции отсоединения и присоединения. Таким образом, файлы при отсоединении принадлежали первому логину, но прикрепление не удалось, потому что используемый логин не был владельцем файлов mdf и ldf.

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

щелкните правой кнопкой мыши на " filename.mdf " файл и выберите Свойства, чтобы проверить разрешения файла mdf. Здесь мы видим, что только одна учетная запись имеет разрешение на "именем.mdf", потому что это была учетная запись, которая использовалась для отсоединения базы данных.

чтобы решить эту проблему, нажмите на Добавлять. кнопка, чтобы добавить другой логин или любой другой логин, необходимый и дать логин полный контроль. Вы также должны сделать это для файла" ldf". После выполнения этой задачи нажмите кнопку OK. (Примечание для других операционных систем, вы можете изменить параметр , нажмите на эту сначала, а потом вы увидите добавить. выбор.)

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

  • SQL Express 2008
  • Visual Studio 2010 Premium

в контекстном меню папки App_Data я создал базу данных SQL Express для целей отладки. Строка соединения (используемая NHibernate) была следующей:

Это дало мне ту же ошибку" отказано в доступе " в файле базы данных. Я пробовал давать различные пользователи полностью контролируют папку и файлы, в какой-то момент даже "все". Ничего не помогло, поэтому я снова удалил добавленные разрешения.

что, наконец, решил его было открыть Проводник сервера в Visual Studio, затем подключиться к MDF и отсоединить его снова. После того, как я сделал это, мое веб-приложение могло получить доступ к базе данных.

PS. Кредиты идут в этот блог Я нашел, пока гуглил эту проблему, вызвав идея прикрепите / отсоедините базу данных для решения проблемы.

Это звучит как разрешения NTFS. Обычно это означает, что учетная запись службы SQL Server имеет доступ только для чтения к файлу (обратите внимание, что SQL Server использует ту же учетную запись службы для доступа к файлам базы данных независимо от способа входа). Вы уверены, что не изменили разрешения папки между входом в систему как самостоятельно и входом в систему как sa? Если вы отсоединитесь и повторите попытку, у него все еще будет та же проблема?

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

я прикрепил файл mdf, щелкнув правой кнопкой мыши базу данных и удалив файл журнала AdventureWorks2012_Data_log.ЛДФ в Мастере . Файл mdf был помещен в следующее место

вышеуказанный метод помог мне решить проблему .

Я читал на этой странице и у них там есть интересное предложение:

внимание: будьте очень избирательны при добавлении пользователи этих ролей. Например, sysadmin сопоставляется с dbo в каждом база данных и является эквивалентом вход с помощью учетной записи sa.

конечно, у них тоже есть это:

разрешения для пользователей и роли, и базы данных специфичны. Все разрешения суммируется с исключение из правила DENY. Отказано разрешение на уровне пользователя или на уровне роли переопределяет же разрешение, предоставленное через другую роль членство за исключением предопределенной роли сервера sysadmin. (Ля администратор сохраняет за собой все права, даже если роли у них член есть Отказать в разрешении.)

поэтому, если вы администратор домена и в группе SQL 'sysadmin', мир должен быть вашим ракообразным.

конечно, по Microsoft, вы должны быстро взглянуть на эти две страницы:
ссылка на предпосылки базы данных

вы шалите и пытаетесь прикрепить их вручную :) серьезно, у вас есть все предпосылки для базы данных AdventureWorks2008?
Я подозреваю, что это просто еще один случай Microsoft oddity/edge, но я могу ошибаться.

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

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

Я проверил файл mdf другого проекта, который я создал непосредственно в его папке app_data. он не имеет разрешений MSSQL$SQLEXPRESS. Хммм. Интересно, почему SQL Express нравится один, но не другой?

enter image description here

заменить на ДЛЯ ATTACH -- > ДЛЯ ATTACH_FORCE_REBUILD_LOG

Это на самом деле разрешения NTFS и странная ошибка в SQL Server. Я не уверен, что приведенный выше отчет об ошибке является точным или может ссылаться на дополнительную ошибку.

чтобы решить эту проблему в Windows 7, я обычно запускал SQL Server Management Studio (не как администратор). Затем я попытался прикрепить файл MDF. В этом процессе я использовал пользовательский интерфейс, а не вставлял путь. Я заметил, что тропинка отрезана от меня. Это связано с тем, что MS SQL Server (SQLServerMSSQLUser$machinename$SQLEXPRESS) пользователь, добавляемый для вас программным обеспечением, не имеет разрешений на доступ к папке (в этом случае папка глубоко в моих собственных папках пользователя).

вставка пути и продолжение приводит к вышеуказанной ошибке. Итак, я дал пользователю MS SQL Server разрешения на чтение, начиная с первого каталога, в котором ему было отказано (моя папка пользователя). Затем я немедленно отменил операцию распространения, потому что она может занять вечность, и снова применил необходимые разрешения на чтение к следующей подпапке, и пусть это распространяется полностью.

наконец, я дал пользователю MS SQL Server разрешения на изменение .MDF и. ldf файлы для БД.

теперь я могу прикрепить к файлам базы данных.

Я получил эту ошибку, как SA. В моем случае безопасность не имела значения. Я добавил полный контроль над файлами mdf и ldf, и все прошло хорошо.

при запуске sql server 2012 Вы можете получить эту ошибку, пытаясь прикрепить более старую версию mdf-файла. ex файл mdf из sql server 2008.

Я решил проблему, просто двигаться .файл mdf, который вы хотите прикрепить к общей папке, в моем случае я переместил его в папку users/public. Затем я прикрепляю его оттуда без каких-либо проблем. Надеюсь, это поможет.

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

перейдите в папку " данные "в установке SQL Server, щелкните правой кнопкой мыши, свойства, вкладка" Безопасность "и добавьте разрешения полного управления для пользователя "сетевая служба".

(приведенная выше ссылка для SQL 2005, но это исправлено SQL 2008 R2 установка для меня).

дополнительная информация: эта проблема появилась для меня после замены дополнительного жесткого диска (на котором была установлена SQL). Я скопировал все файлы и восстановил исходную букву диска на новый жесткий диск. Однако разрешения безопасности не были скопированы. Я думаю, что в следующий раз я буду использовать лучший метод копирования данных.

Читайте также: