6.2.7. Причины Ошибок Доступа запрещен

Удостоверьтесь, что сервер работает. Если это не, клиенты не могут соединиться с этим. Например, если попытка соединиться со сбоями сервера с сообщением, такими как один из тех после, одна причина могла бы состоять в том, что сервер не работает:

shell> mysqlERROR 2003: Can't connect to MySQL server on 'host_name' (111)shell> mysqlERROR 2002: Can't connect to local MySQL server through socket'/tmp/mysql.sock' (111)

Могло бы случиться так, что сервер работает, но Вы пытаетесь соединить использование порта TCP/IP, именованного канала, или файла сокета Unix, отличающегося от того, на котором слушает сервер. Чтобы исправить это, когда Вы вызываете клиентскую программу, определите a --port опция, чтобы указать на надлежащий номер порта, или a --socket опция, чтобы указать на надлежащий именованный канал или Unix снабжает файл сокетом. Чтобы узнать, где файл сокета, можно использовать эту команду:

shell> netstat -ln | grep
                    mysql

Удостоверьтесь, что сервер не был сконфигурирован, чтобы проигнорировать сетевые соединения или (если Вы пытаетесь соединиться удаленно), что он не был сконфигурирован, чтобы слушать только локально на его сетевых интерфейсах. Если сервер был запущен с --skip-networking, это не будет принимать соединения TCP/IP вообще. Если сервер был запущен с --bind-address=127.0.0.1, это прислушается к соединениям TCP/IP только локально в петлевом интерфейсе и не будет принимать удаленные соединения.

Проверьте, чтобы удостовериться, что нет никакого доступа блокирующего брандмауэра к MySQL. Ваш брандмауэр может быть сконфигурирован на основе приложения, выполняемого, или номер порта, используемый MySQL для передачи (3306 по умолчанию). Под Linux или Unix, проверьте свои таблицы IP (или подобный) конфигурация, чтобы гарантировать, что порт не был блокирован. Под Windows приложения, такие как ZoneAlarm или Windows XP персональный брандмауэр, возможно, должен быть сконфигурирован, чтобы не блокировать порт MySQL.

Таблицы предоставления должны быть должным образом установлены так, чтобы сервер мог использовать их для управления доступом. Для некоторых типов распределения (таких как двоичные дистрибутивы на Windows, или дистрибутивы ОБ/МИН на Linux), процесс установки инициализирует mysql база данных, содержащая таблицы предоставления. Для дистрибутивов, которые не делают этого, следует инициализировать таблицы предоставления вручную, выполняя mysql_install_db сценарий. Для получения дополнительной информации см. Раздел 2.10.1, "Постпроцессы установки Unix".

Чтобы определить, должны ли Вы инициализировать таблицы предоставления, ищите a mysql каталог в соответствии с каталогом данных. (Каталог данных обычно называют data или var и располагается в соответствии с Вашим каталогом установки MySQL.) Удостоверяются, что Вам назвали файл user.MYD в mysql каталог базы данных. В противном случае выполните mysql_install_db сценарий. После выполнения этого сценария и запуска сервера, протестируйте начальные полномочия, выполняя эту команду:

shell> mysql -u root test

Сервер должен позволить Вам соединяться без ошибки.

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

shell> mysql -u root
                    mysql

Сервер должен позволить Вам соединяться потому что MySQL root у пользователя нет никакого пароля первоначально. Это - также угроза безопасности, таким образом устанавливая пароль для root учетные записи - что-то, что следует сделать, в то время как Вы устанавливаете свои другие учетные записи MySQL. Для получения инструкций по установке начальных паролей см. Раздел 2.10.2, "Защищая Учетные записи MySQL Initial".

Если Вы обновили существующую установку MySQL к более новой версии, Вы выполняли mysql_upgrade сценарий? В противном случае сделайте так. Структура таблиц предоставления иногда изменяется, когда новые возможности добавляются, таким образом, после обновления следует всегда удостоверяться, что у Ваших таблиц есть текущая структура. Для инструкций см. Раздел 4.4.7, "mysql_upgrade — Таблицы MySQL Check и Upgrade" .

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

shell> mysqlClient does not support authentication protocol requestedby server; consider upgrading MySQL client

Для получения информации о том, как иметь дело с этим, см. Раздел 6.1.2.4, "Пароль, Хеширующий в MySQL", и Разделе C.5.2.4,"Client does not support authentication protocol".

Помните, что клиентские программы используют параметры соединения, определенные в файлах опции или переменных окружения. Если клиентская программа, кажется, отправляет неправильные параметры соединения значения по умолчанию, когда Вы не определили их на командной строке, проверьте любые применимые файлы опции и Вашу среду. Например, если Вы добираетесь Access denied когда Вы выполняете клиент без любых опций, удостоверьтесь, что Вы не определили старый пароль в любом из Ваших файлов опции!

Можно подавить использование файлов опции клиентской программой, вызывая это с --no-defaults опция. Например:

shell> mysqladmin --no-defaults -u root
                    version

Файлы опции, которые используют клиенты, перечисляются в Разделе 4.2.3.3, "Используя Файлы Опции". Переменные окружения перечисляются в Разделе 2.12, "Переменных окружения".

Если Вы получаете следующую ошибку, это означает, что Вы используете неправильное root пароль:

shell> mysqladmin -u root -pxxxx verAccess denied for user 'root'@'localhost' (using password: YES)

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

Для получения информации об изменяющихся паролях см. Раздел 6.3.5, "Присваивая Пароли Учетной записи".

Если Вы потеряли или забыли root пароль, см. Раздел C.5.4.1, "Как Сбросить Корневой Пароль".

Если Вы изменяете пароль при использовании SET PASSWORD, INSERT, или UPDATE, следует зашифровать пароль, используя PASSWORD() функция. Если Вы не используете PASSWORD() для этих операторов не будет работать пароль. Например, следующий оператор присваивает пароль, но не в состоянии зашифровать его, таким образом, пользователь не в состоянии соединиться позже:

SET PASSWORD FOR 'abe'@'host_name' = 'eagle';

Вместо этого установите пароль как это:

SET PASSWORD FOR 'abe'@'host_name' = PASSWORD('eagle');

PASSWORD() функция является ненужной, когда Вы определяете пароль, используя CREATE USER или GRANT операторы или mysqladmin команда пароля. Каждый из тех автоматически использует PASSWORD() зашифровать пароль. См. Раздел 6.3.5, "Присваивая Пароли Учетной записи", и Раздел 13.7.1.2,"CREATE USER Синтаксис".

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

Чтобы избежать этой проблемы на таких системах, можно использовать a --host=127.0.0.1 опция, чтобы назвать узел сервера явно. Это сделает соединение TCP/IP с локальным mysqld сервером. Можно также использовать TCP/IP, определяя a --host опция, которая использует фактическое имя хоста локального узла. В этом случае имя хоста должно быть определено в a user строка таблицы на узле сервера, даже при том, что Вы выполняете клиентскую программу на том же самом узле как сервер.

Access denied сообщение об ошибке говорит Вам, которые Вы пытаетесь войти в систему как, хост клиента, от которого Вы пытаетесь соединиться, и использовали ли Вы пароль. Обычно, следует поссориться в user таблица, которая точно соответствует имя хоста и имя пользователя, которые были даны в сообщении об ошибке. Например, если Вы получаете сообщение об ошибке, которое содержит using password: NO, это означает, что Вы попытались войти в систему без пароля.

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

SELECT * FROM user;

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

Если следующая ошибка происходит, когда Вы пытаетесь соединиться от узла кроме того, на котором работает сервер MySQL, это означает, что нет никакой строки в user таблица с a Host значение, которое соответствует хост клиента:

Host ... is not allowed to connect to this MySQL server

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

Если Вы не знаете IP-адрес или имя хоста машины, от которой Вы соединяетесь, следует поместить строку с '%' как Host значение столбца в user таблица. После попытки соединиться от клиентской машины, используйте a SELECT USER() запрос, чтобы видеть, как Вы действительно соединялись. Затем изменитесь '%' в user строка таблицы к фактическому имени хоста, которое обнаруживается в журнале. Иначе, Вашу систему оставляют небезопасной, потому что она разрешает соединения от любого узла к данному имени пользователя.

На Linux другая причина, что эта ошибка могла бы произойти, состоит в том, что Вы используете двоичную версию MySQL, которая компилируется с различной версией glibc библиотека чем тот Вы используете. В этом случае следует или обновить свою операционную систему или glibc, или загрузите исходное распределение версии MySQL и скомпилируйте ее непосредственно. Исходный ОБ/МИН обычно тривиален, чтобы скомпилировать и установить, таким образом, это не большая проблема.

Если Вы определяете имя хоста, пытаясь соединить, но получить сообщение об ошибке, где имя хоста не показывают или является IP-адресом, это означает, что сервер MySQL получил ошибку, пытаясь разрешить IP-адрес хоста клиента к имени:

shell> mysqladmin -u root -pxxxx -h some_hostname
                    verAccess denied for user 'root'@'' (using password: YES)

Если Вы пытаетесь соединиться как root и получите следующую ошибку, это означает, что Вы не ссоритесь в user таблица с a User значение столбца 'root' и это mysqld не может разрешить имя хоста для Вашего клиента:

Access denied for user ''@'unknown'

Эти ошибки указывают на проблему DNS. Чтобы фиксировать это, выполните mysqladmin узлы сброса, чтобы сбросить внутренний кэш узла DNS. См. Раздел 8.11.5.2, "Оптимизация Поиска DNS и Кэш Узла".

Некоторые постоянные решения:

Если mysql -u root test работы, но mysql -h your_hostname -u root test результаты в Access denied (где your_hostname фактическое имя хоста локального узла), у Вас не может быть корректного имени для Вашего узла в user таблица. Типичная проблема здесь состоит в том что Host значение в user строка таблицы определяет неполное имя хоста, но подпрограммы разрешения имени Вашей системы возвращают полностью определенное доменное имя (или наоборот). Например, если у Вас есть запись с узлом 'pluto' в user таблица, но Ваш DNS говорит MySQL, что Ваше имя хоста 'pluto.example.com', запись не работает. Попытайтесь добавить запись в user таблица, которая содержит IP-адрес Вашего узла как Host значение столбца. (Альтернативно, Вы могли добавить запись в user таблица с a Host значение, которое содержит подстановочный знак; например, 'pluto.%'. Однако, использование Host значения, заканчивающиеся"%"небезопасно и не рекомендуется!)

Если mysql -u user_name test работы, но mysql -u user_name other_db не делает, Вы не предоставили доступ данному пользователю для названной базы данных other_db.

Если mysql -u user_name работы когда выполняющийся на узле сервера, но mysql -h host_name -u user_name не работает когда выполняющийся над удаленным хостом клиента, Вы не включили доступу к серверу для данного имени пользователя от удаленного узла.

Если невозможно выяснить, почему Вы добираетесь Access denied, удалите из user таблица все записи, которые имеют Host значения, содержащие подстановочные знаки (записи, которые содержат '%' или '_' символы). Очень распространенная ошибка состоит в том, чтобы вставить новую запись с Host='%' и User='some_user', думая, что это позволяет Вам определить localhost соединяться от той же самой машины. Причина, что это не работает, состоит в том, что полномочия значения по умолчанию включают запись с Host='localhost' и User=''. Поскольку у той записи есть a Host значение 'localhost' это является более определенным чем '%', это используется в предпочтении к новой записи, соединяясь от localhost! корректная процедура должна вставить вторую запись с Host='localhost' и User='some_user', или удалить запись с Host='localhost' и User=''. После удаления записи помните к проблеме a FLUSH PRIVILEGES оператор, чтобы перезагрузить таблицы предоставления. См. также Раздел 6.2.4, "Управление доступом, Этап 1: Проверка Соединения".

Если Вы в состоянии соединиться с сервером MySQL, но добраться Access denied обменивайтесь сообщениями всякий раз, когда Вы проблема a SELECT ... INTO OUTFILE или LOAD DATA INFILE оператор, Ваша запись в user таблица не имеет FILE полномочие включается.

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

Если Ваши полномочия, кажется, изменились в середине сеанса, может случиться так, что администратор MySQL изменил их. Перезагрузка таблиц предоставления влияет на новые клиентские соединения, но она также влияет на существующие соединения как обозначено в Разделе 6.2.6, "Когда Изменения Полномочия Вступают в силу".

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

Для тестирования запустите mysqld сервер с --skip-grant-tables опция. Затем можно изменить таблицы предоставления MySQL и использовать mysqlaccess сценарий, чтобы проверить, имеют ли Ваши модификации требуемый эффект. Когда Вы удовлетворены своими изменениями, выполните mysqladmin полномочия сброса сказать mysqld серверу перезагружать полномочия. Это позволяет Вам начать использовать новое табличное содержание предоставления, не останавливаясь и перезапуская сервер.

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

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