MySQL :: MySQL 5.6 リファレンスマニュアル :: 6.2.7 アクセス拒否エラーの原因

version 5.6

MySQL 5.6 リファレンスマニュアル / ... / アクセス拒否エラーの原因

6.2.7 アクセス拒否エラーの原因

MySQL サーバーへの接続を試行したときに問題が発生した場合に問題を修正するために実行できる一連のアクションについて、次の項目で説明します。

サーバーが実行中であることを確認します。そうでない場合、クライアントは接続できません。たとえば、サーバーに接続しようとして次のいずれかのようなメッセージで失敗した場合、サーバーが実行中でないことが 1 つの原因であることがあります。
```
shell> mysql
ERROR 2003: Can't connect to MySQL server on 'host_name' (111)
shell> mysql
ERROR 2002: Can't connect to local MySQL server through socket
'/tmp/mysql.sock' (111)
```
サーバーは実行しているが、サーバーが待機しているのと異なる TCP/IP ポート、名前付きパイプ、または Unix ソケットファイルを使用して接続しようとしている場合もあります。これを修正するには、クライアントプログラムを呼び出すときに、適切なポート番号を指すように --port オプションを指定するか、--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 の RPM 配布など) では、インストールプロセスで、付与テーブルがある mysql データベースが初期化されます。これを行わない配布の場合、mysql_install_db プログラムを実行して付与テーブルを手動で初期化する必要があります。詳細については、セクション2.10.1「Unix 類似システムでのインストール後の手順」を参照してください。

付与テーブルの初期化が必要かどうかを判別するには、データディレクトリの下にある mysql ディレクトリを参照します。(通常、データディレクトリは data または var という名前で、MySQL のインストールディレクトリの下にあります。)mysql データベースディレクトリに user.MYD という名前のファイルがあることを確認してください。ない場合、mysql_install_db プログラムを実行します。このプログラムを実行してサーバーを起動したあと、次のコマンドを実行して初期の権限をテストします。
```
shell> mysql -u root test
```
サーバーはエラーを出さずにユーザーを接続するはずです。
新規インストールのあと、サーバーに接続してユーザーおよびユーザーのアクセス権限をセットアップするようにします。
```
shell> mysql -u root mysql
```
MySQL root ユーザーには最初からパスワードがないため、サーバーはユーザーを接続するはずです。これにはセキュリティー面でのリスクが伴うため、別の MySQL アカウントをセットアップする際は、root アカウントのパスワードを設定することをお勧めします。初期パスワードの設定手順に関しては、セクション2.10.2「最初の MySQL アカウントのセキュリティー設定」を参照してください。
既存の MySQL インストールを新しいバージョンに更新した場合、mysql_upgrade スクリプトを実行したかどうかを確認します。行なっていない場合は実行します。付与テーブルの構造は、新機能が追加されるときにしばしば変更されるため、アップグレードしたあとは常に、テーブルの構造が最新であることを確認することをお勧めします。その手順は、セクション4.4.7「mysql_upgrade — MySQL テーブルのチェックとアップグレード」を参照してください。
クライアントプログラムが接続しようとしたときに次のエラーメッセージを受け取る場合、サーバーはクライアントが生成可能なものよりも新しい形式のパスワードを予期していることを意味します。
```
shell> mysql
Client does not support authentication protocol requested
by server; consider upgrading MySQL client
```
これに対処する方法については、セクション6.1.2.4「MySQL でのパスワードハッシュ」およびセクションB.5.2.4「クライアントは認証プロトコルに対応できません」を参照してください。
クライアントプログラムはオプションファイルまたは環境変数に指定された接続パラメータを使用することに留意してください。コマンド行に接続パラメータを指定しないときにクライアントプログラムが間違ったデフォルトの接続パラメータを送信していると思われる場合、該当するオプションファイルおよび環境を確認してください。たとえば、オプションなしでクライアントを実行するときに Access denied を受け取る場合、いずれかのオプションファイルで古いパスワードを指定していないか確認してください。

--no-defaults を指定してクライアントプログラムを呼び出すことによって、オプションファイルの使用をクライアントプログラムによって抑制することができます。例:
```
shell> mysqladmin --no-defaults -u root version
```
クライアントが使用するオプションファイルの一覧は、セクション4.2.6「オプションファイルの使用」にあります。環境変数の一覧は、セクション2.12「環境変数」にあります。
次のエラーが出る場合、誤った root パスワードを使用していることを示しています。
```
shell> mysqladmin -u root -pxxxx ver
Access denied for user 'root'@'localhost' (using password: YES)
```
パスワードを指定していないのに前述のエラーが発生する場合、いずれかのオプションファイルに間違ったパスワードがリストされていることを意味します。前述の項目で説明したように、--no-defaults オプションを試してみてください。

パスワードの変更に関する情報は、セクション6.3.5「アカウントパスワードの割り当て」を参照してください。

root パスワードを紛失したか忘れた場合、セクションB.5.4.1「root のパスワードをリセットする方法」を参照してください。
SET PASSWORD、INSERT、または UPDATE を使用してパスワードを変更する場合、PASSWORD() 関数を使用して、そのパスワードを暗号化する必要があります。これらのステートメントに対して PASSWORD() 関数を使用しないと、パスワードは機能しません。たとえば、次のステートメントはパスワードを割り当てますが、パスワードが暗号化されないため、ユーザーはあとで接続できません。
```
SET PASSWORD FOR 'abe'@'host_name' = 'eagle';
```
代わりに、パスワードを次のように設定します。
```
SET PASSWORD FOR 'abe'@'host_name' = PASSWORD('eagle');
```
CREATE USER または GRANT ステートメントまたは mysqladmin password コマンドを使用してパスワードを指定するときは、PASSWORD() 関数は不要です。これらはいずれも PASSWORD() を自動的に使用してパスワードを暗号化します。セクション6.3.5「アカウントパスワードの割り当て」およびセクション13.7.1.2「CREATE USER 構文」を参照してください。
localhost はローカルホスト名のシノニムで、ホストを明示的に指定しない場合にクライアントが接続を試行するデフォルトホストでもあります。

そのようなシステムで前述の問題を回避するために、--host=127.0.0.1 オプションを使用して、サーバーホストを明示的に指定することができます。これにより、ローカルの mysqld サーバーへの TCP/IP 接続が作成されます。また、ローカルホストの実際のホスト名を使用する --host オプションを指定することによって TCP/IP を使用することもできます。この場合、サーバーと同じホスト上でクライアントプログラムを実行していても、ホスト名がサーバーホスト上の user テーブル行に指定されていなければなりません。
Access denied というエラーメッセージは、ログインしようとしているユーザー名、接続を試行しているクライアントホスト、およびパスワードを使用したかどうかを通知します。通常では、エラーメッセージ内で指定されたホスト名およびユーザー名に正確に一致する 1 つの行を user テーブル内に持つようにします。たとえば、using password: NO というメッセージを含むエラーメッセージを受け取る場合、パスワードなしでログインしようとしたことを意味します。
mysql -u user_name を使用してデータベースに接続しようとしたときに Access denied エラーを受け取った場合、user テーブルにおそらく問題があります。これをチェックするには、mysql -u root mysql を実行し、次の SQL ステートメントを発行します。
```
SELECT * FROM user;
```
この結果には、クライアントのホスト名および使用中の MySQL ユーザー名に一致する Host および User カラムを持つ行が含まれているはずです。
MySQL サーバーを実行しているホストではないホストから接続しようとして次のエラーが発生する場合、クライアントホストと一致する Host 値を持つ行が user テーブルにないということを意味しています。
```
Host ... is not allowed to connect to this MySQL server
```
これは、接続しようとするときに使用するクライアントホスト名およびユーザー名の組み合わせに対するアカウントをセットアップすることによって修正できます。

接続元のマシンの IP アドレスまたはホスト名がわからない場合、Host カラム値が '%' の行を user テーブル内に作成するようにします。そして、そのクライアントマシンから接続しようとしたあとで、SELECT USER() クエリーを使用して、実際にどのように接続したかを確認します。そのあと、user テーブル行の '%' を、ログに表示されている実際のホスト名に変更します。そうしない場合、特定のユーザー名について任意のホストからの接続が可能になるため、システムはセキュアでない状態のままになります。

Linux では、このエラーが発生する可能性がある別の理由として、使用中のバージョンとは異なるバージョンの glibc ライブラリでコンパイルされたバイナリ MySQL バージョンを使用しているということがあります。この場合、オペレーティングシステムまたは glibc をアップグレードするか、MySQL のソース配布バージョンをダウンロードして自分でコンパイルします。ソース RPM のコンパイルおよびインストールは通常簡単であるため、これは大きな問題ではありません。
接続しようとしたときにホスト名を指定したが、ホスト名が非表示または IP アドレスとなっているエラーメッセージを受け取った場合、MySQL サーバーはクライアントホストの IP アドレスを名前に解決しようとしたときにエラーを受け取ったことを意味します。
```
shell> mysqladmin -u root -pxxxx -h some_hostname ver
Access denied for user 'root'@'' (using password: YES)
```
root として接続しようとして次のエラーを受け取った場合、User カラム値が 'root' の行が user テーブルになく、mysqld がクライアントに対してホスト名を解決できないことを意味します。
```
Access denied for user ''@'unknown'
```
これらのエラーは DNS の問題を示しています。これを修正するには、mysqladmin flush-hosts を実行して内部 DNS ホストキャッシュをリセットします。セクション8.11.5.2「DNS ルックアップの最適化とホストキャッシュ」を参照してください。

いくつかの永続的な解決策を次に示します。
- DNS サーバーの問題を判別して修正します。
- MySQL 付与テーブルにホスト名の代わりに IP アドレスを指定します。
- クライアントマシン名に対するエントリを、Unix の場合は /etc/hosts に、Windows の場合は \windows\hosts に配置します。
- mysqld を --skip-name-resolve オプションで起動します。
- mysqld を --skip-host-cache オプションで起動します。
- Unix で、サーバーとクライアントを同じマシンで実行している場合、localhost に接続します。localhost への Unix 接続は、TCP/IP ではなく Unix ソケットファイルを使用します。
- Windows で、サーバーとクライアントを同じマシンで実行していて、サーバーが名前付きパイプ接続をサポートしている場合、ホスト名 . (ピリオド) に接続します。. への接続には、TCP/IP ではなく名前付きパイプが使用されます。
mysql -u root test は動作するが、mysql -h your_hostname -u root test が Access denied になる場合 (ここで、your_hostname はローカルホストの実際のホスト名)、ホスト名に対する正しい名前が user テーブル内にない可能性があります。このときよくある問題として、user テーブル行の Host 値は、修飾されていないホスト名を指定しているが、システムの名前解決ルーチンは完全修飾ドメイン名を返すということ (またはその逆) があります。たとえば、user テーブルにホスト 'pluto' のエントリがあるが、DNS が MySQL に対してホスト名が 'pluto.example.com' であると指示する場合、エントリは無効になります。ホストの IP アドレスを Host カラム値として格納するエントリを user テーブルに追加してみてください。(または、'pluto.%' などのワイルドカードを含む Host 値を持つエントリを user テーブルに追加することもできます。ただし、「%」で終わる 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 を受け取る理由がわからない場合、ワイルドカードを含む Host 値を持つすべてのエントリ ('%' または '_' 文字を含むエントリ) を user テーブルから削除します。非常によくある間違いは、Host='%' および User='some_user' という新しいエントリを挿入して、これにより、ユーザーは同じマシンから接続するよう localhost に指定できると思い込むことです。これが機能しない理由は、デフォルト権限に、Host = 'localhost' および User = '' というエントリを含むためです。このエントリには、'%' よりもさらに具体的な 'localhost' という Host 値があるため、localhost から接続するときは新しいエントリよりもこちらが優先して使用されます。正しい手順としては、Host = 'localhost' および User = 'some_user' という第 2 のエントリを挿入するか、Host = 'localhost' および User = '' のエントリを削除します。このエントリを削除したら、FLUSH PRIVILEGES ステートメントを発行して、付与テーブルのリロードを必ず行なってください。セクション6.2.4「アクセス制御、ステージ 1: 接続の検証」も参照してください。
MySQL サーバーに接続できるが、SELECT ... INTO OUTFILE または LOAD DATA INFILE ステートメントを発行するたびに Access denied メッセージを受け取る場合、user テーブル内のエントリで FILE 権限が有効になっていません。
付与テーブルを直接 (たとえば、INSERT、UPDATE、または DELETE ステートメントを使用して) 変更し、変更が無視されたように思われる場合、サーバーに権限テーブルをリロードさせるために FLUSH PRIVILEGES ステートメントまたは mysqladmin flush-privileges コマンドを実行する必要があることを覚えておいてください。そうしない場合、サーバーが次回再起動するまで変更の影響はありません。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 はパスワードを要求します。)
テスト目的で、--skip-grant-tables オプションを指定して mysqld サーバーを起動します。これにより、MySQL 付与テーブルを変更でき、SHOW GRANTS ステートメントを使用して、変更による望ましい影響があるかどうかを確認することができます。変更に満足したら、mysqladmin flush-privileges を実行して、権限をリロードするよう mysqld サーバーに指示します。これにより、サーバーを停止して再起動することなく新しい付与テーブルの内容の使用を開始することができます。
すべてが失敗する場合、mysqld サーバーをデバッグオプション (--debug=d,general,query など) で起動します。これによって、発行された各コマンドに関する情報のほかに、試行された接続についてのホストおよびユーザー情報が出力されます。セクション24.4.3「DBUG パッケージ」を参照してください。
MySQL 付与テーブルに関して何かほかの問題があって、メーリングリストに問題を投稿する必要があると思われる場合、MySQL 付与テーブルのダンプを常に提供してください。mysqldump mysql コマンドでテーブルをダンプできます。バグレポートを提出するには、セクション1.6「質問またはバグをレポートする方法」の説明を参照してください。mysqldump を実行するには --skip-grant-tables を指定して mysqld を再起動することが必要な場合もあります。

PREV HOME UP NEXT