Loginの問題

ログインの問題とは、お使いのコンピュータが予期されるようこそ画面またはログインプロンプトまで実際起動するが、ユーザ名およびパスワードを受け付けない、または受け付けるが、その後適切な動きをしない場合です(グラフィックデスクトップの開始の失敗、エラーの発生、コマンドラインに落ちる、など)。

有効なユーザ名とパスワードを使っても失敗する

この問題は、一般的にシステムがネットワーク認証またはディレクトリサービスを使用するように設定されており、何らかの理由で、設定されたサーバから結果を取得できない場合に発生します。このような場合でも、rootユーザは唯一のローカルユーザとしてこれらのコンピュータにログインできます。以下では、コンピュータが一見機能しているように見えるのにログインを正しく処理できない一般的な理由をいくつか挙げます。

ネットワークが機能していません。この場合の更なる対処方法については、51.5項「ネットワークの問題」を参照してください
DNSが機能していないです。(これによりGNOMEまたはKDEは働かず、システムは安全なサーバに有効なリクエストを送れません)。すべてのアクションに対して、コンピュータに極端に長い時間かかる場合は、この問題の可能性があります。このトピックの詳細は、51.5項「ネットワークの問題」を参照してください。
システムがKerberosを使用するように設定されている場合、システムのローカルタイムは、Kerberosサーバのタイムとの間で許容される相違を超えてしまっている可能性があります(通常300秒)。NTP (network time protocol)が適切に動いていない、またはローカルのNTPサーバが動いていない場合、Kerberos の認証は機能しなくなります。その理由は、この認証はネットワーク間の一般的なクロック同期に依存しているからです。
システムの認証設定が間違って設定されています。関連するPAM設定ファイルの中に誤字や命令の順序違いがないか確認します。PAMおよび関連する設定ファイルの構文に関する背景情報の詳細については、第27章 PAMを使用した認証を参照してください。

外部のネットワーク問題を含まない他のすべての問題については、解決方法としてシステムをシングルユーザモードに再起動して、動作モードに再び起動してログインし直す前に、設定を修復します。シングルユーザモードで起動するには

システムを再起動します。ブート画面の表示に続き、プロンプトが表示されます。
ブートプロンプトでは、1を入力し、システムブートがシングルユーザモードになるようにします。
root用のユーザ名とパスワードを入力します。
すべての必要な変更をします。
コマンドラインにtelinit 5を入力して、ネットワークありフルマルチユーザモードに起動します。

有効なユーザ名とパスワードが受け付けられない

これは、今のところユーザが経験する問題のうち、最も一般的なものです。その理由は、この問題が起こる原因がたくさんあるからです。ローカルのユーザ管理および認証を使用するか、ネットワーク認証を使用するかによって、異なる原因によりログイン失敗が発生します。

ローカルユーザ管理は、次の原因により失敗する可能性があります。

間違ったパスワードを入力した可能性があります。
ユーザのホームディレクトリが、破損または書き込み保護されたデスクトップ設定ファイルを含んでいます。
この特定のユーザを認証するのに、X Window Systemに何らかの問題があります。特に、ユーザのホームディレクトリが、現在のLinuxをインストールする以前の他のLinuxディストリビューションによって使用されている場合です。

ローカルログイン失敗の原因を発見するには、次の手順に従います。

認証方式全体をデバッグする前に、ユーザがパスワードを正しく覚えているか確認します。ユーザが正しいパスワードを覚えていない場合は、YaSTユーザ管理モジュールを使用してそのユーザのパスワードを変更します。
rootユーザでログインし、ログインプロセスおよびPAMのエラーメッセージがないかどうか/var/log/messagesを確認します。
コンソールからログインしてみます(Ctrl+Alt+F1キーを使用)。これが成功する場合、PAMには問題はありません。その理由は、そのユーザをそのコンピュータ上で認証可能だからです。X Window Systemまたはデスクトップ(GNOMEまたはKDE)で問題がないか探してみてください。詳細については、「51.4.3項「ログインは成功したがGNOMEデスクトップが失敗する」」および「51.4.4項「ログインは成功したがKDEデスクトップが失敗する」」を参照してください。
ユーザのホームディレクトリが他のLinuxディストリビューションによって使用されている場合、ユーザのホームにあるXauthorityファイルを削除します。Ctrl+Alt+F1キーを押してコンソールログインを使用し、rm .Xauthorityをこのユーザとして実行します。これにより、X認証の問題はこのユーザに関してはなくなるはずです。グラフィカルログインを再試行します。
グラフィカルログインがまだ失敗する場合、Ctrl+Alt+F1キーでコンソールログインを行ってください。他のディスプレイ上でXセッションを開始します。最初のもの(:0)はすでに使用中です。
```
startx -- :1
```
これによってグラフィカル画面とデストップが表示されます。表示されない場合は、X Window Systemのログファイル(/var/log/Xorg.displaynumber.log)を確認するか、デスクトップアプリケーションのログ(.xsession-errors)を確認して、異常な点がないか調べます。
設定ファイルが壊れていて、デスクトップが開始できなかった場合、51.4.3項「ログインは成功したがGNOMEデスクトップが失敗する」または51.4.4項「ログインは成功したがKDEデスクトップが失敗する」を続行します。

以下では、特定のユーザのネットワーク認証が、特定のコンピュータ上で失敗するのかの一般的な理由のいくつかを挙げます。

間違ったパスワードを入力した可能性があります。
コンピュータのローカル認証ファイルの中に存在し、ネットワーク認証システムからも提供されるユーザ名が競合しています。
ホームディレクトリは存在しますが、それが壊れている、または利用不可能です。書き込み保護がされているか、その時点でアクセスできないサーバ上にディレクトリが存在するかのどちらかの可能性があります。
認証システム内で、ユーザがその特定のサーバにログインする権限がありません。
コンピュータのホスト名が何らかの理由で変更されていて、そのホストにユーザがログインする権限がありません。
コンピュータが、認証サーバまたはそのユーザの情報を含んでいるディレクトリサーバに接続できません。
この特定のユーザを認証するのに、X Window Systemに何らかの問題があります。特に、ユーザのホームが、現在のLinuxをインストールする以前の他のLinuxディストリビューションによって使用されてる場合です。

ネットワーク認証におけるログイン失敗の原因を突き止めるには、次の手順に従います。

認証方式全体をデバッグする前に、ユーザがパスワードを正しく覚えているか確認します。
認証用にマシンが利用するディレクトリサーバを判別し、それがきちんと動作しており、他のマシンと適切に通信していることを確認します。
ユーザのユーザ名およびパスワードが他のマシン上でも使用できるかを判別し、そのユーザの認証データが存在し、適切に配布されていることを確認します。
他のユーザが、問題のある動きをしているコンピュータにログインできるか観察します。その他のユーザが問題なくログインできたか、rootでログインできた場合、ログイン後、/var/log/messagesファイルの内容を調べます。ログインの試行に対応するタイムスタンプを見つけ出し、PAMによって、エラーメッセージが生成されていないか判別します。
コンソールからログインしてみます(Ctrl+Alt+F1キーを使用)。これが成功する場合、PAMやユーザのホームがあるディレクトリサーバには問題はありません。その理由は、そのユーザをそのコンピュータ上で認証可能だからです。X Window Systemまたはデスクトップ(GNOMEまたはKDE)で問題がないか探してみてください。詳細については、51.4.3項「ログインは成功したがGNOMEデスクトップが失敗する」および51.4.4項「ログインは成功したがKDEデスクトップが失敗する」を参照してください。
ユーザのホームディレクトリが他のLinuxディストリビューションによって使用されている場合、ユーザのホームにあるXauthorityファイルを削除します。Ctrl+Alt+F1キーを押してコンソールログインを使用し、rm .Xauthorityをこのユーザとして実行します。これにより、X認証の問題はこのユーザに関してはなくなるはずです。グラフィカルログインを再試行します。
グラフィカルログインがまだ失敗する場合、Ctrl+Alt+F1キーでコンソールログインを行ってください。他のディスプレイ上でXセッションを開始します。最初のもの(:0)はすでに使用中です。
```
startx -- :1
```
これによってグラフィカル画面とデストップが表示されます。表示されない場合は、X Window Systemのログファイル(/var/log/Xorg.displaynumber.log)を確認するか、デスクトップアプリケーションのログ(.xsession-errors)を確認して、異常な点がないか調べます。
設定ファイルが壊れていて、デスクトップが開始できなかった場合、51.4.3項「ログインは成功したがGNOMEデスクトップが失敗する」または51.4.4項「ログインは成功したがKDEデスクトップが失敗する」を続行します。

ログインは成功したがGNOMEデスクトップが失敗する

特定のユーザにこのことが当てはまる場合、そのユーザのGNOME設定ファイルが壊れている可能性があります。兆候としては、キーボードがうまく動かない、画面のジオメトリが歪んでいる、または画面が空の灰色領域として表示されるなどがあります。この問題の重要な特徴は、他のユーザがログインする場合は、コンピュータは普通に機能するという点です。このような場合、問題のユーザのGNOME設定ディレクトリを単に新しい場所に移すことで、が新しいデスクトップを初期化するので、比較的簡単にこの問題を解決できます。ユーザはGNOMEの再設定を強いられますが、データが失われません。

Ctrl+Alt+F1キーを押して、テキストコンソールを切り替えます。
ユーザ名でログインします。
ユーザのGNOME設定ディレクトリを、一時的な場所に移動します。
```
mv .gconf  .gconf-ORIG-RECOVER
mv .gnome2 .gnome2-ORIG-RECOVER
```
ログアウトします。
もう一度ログインします。ただし、アプリケーションは何も実行しないでください。
次のようにして、~/.gconf-ORIG-RECOVER/apps/ディレクトリを、新しい~/.gconfディレクトリにコピーすることで個々のアプリケーション設定データ(Evolutionの電子メールクライアントデータを含む)を回復します。
```
cp -a .gconf-ORIG-RECOVER/apps .gconf/
```
これによってログインの問題が生じる場合は、重要なアプリケーションデータのみの回復を試み、アプリケーションの残りを再設定します。

ログインは成功したがKDEデスクトップが失敗する

KDEデスクトップがユーザのログインを許可しない理由にはいくつかあります。壊れたKDEデスクトップ設定ファイルと同様に壊れたキャッシュデータもログインの問題を引き起こします。

キャッシュデータは、デスクトップの起動時にパフォーマンスを向上させるため使用されます。このデータが壊れていると、起動が遅くなったり、完全に失敗したりします。キャッシュデータを削除すると、デスクトップ起動のルーチンが最初から開始します。これには一般の起動よりも時間がかかりますが、その後はデータは無事でユーザはログインできます。

KDEデスクトップのキャッシュファイルを削除するには、rootユーザで以下のコマンドを実行します。

rm -rf /tmp/kde-user /tmp/socket-user

userは、実際の値で置き換えられます。これらのディレクトリを削除しても、単に壊れたキャッシュファイルが削除されるだけです。この手順で実際のデータが削除されることはありません。

壊れたデスクトップ設定ファイルは、いつでも初期の設定ファイルに置き換えることができます。ユーザの調整を回復する場合は、デフォルトの設定値を使用して設定が復元されたあとに、一時的な場所からこれらのユーザの調整内容を慎重にコピーします。

壊れたデスクトップ設定ファイルを初期の設定ファイルに置き換えるには、以下の手順に従います。

Ctrl+Alt+F1キーを押して、テキストコンソールを切り替えます。
ユーザ名でログインします。
KDE設定ディレクトリおよび.skelファイルを一時的な場所に移動します。
```
mv .kde  .kde-ORIG-RECOVER 
mv .skel .skel-ORIG-RECOVER
```
ログアウトします。
もう一度ログインします。
デスクトップが正常に開始したら、ユーザ自身の設定を元の場所にコピーします。
```
cp -a .kde-ORIG-RECOVER/share .kde/share
```
ユーザ自身による調整によりログインが失敗し、その状態が続く場合は、.kde/shareディレクトリはコピーせずに上記の手順を繰り返します。


ユーザ自身による調整によりログインが失敗し、その状態が続く場合は、`.kde/share`ディレクトリはコピーせずに上記の手順を繰り返します。