ローカルのDebianJessieインストールでApacheをセットアップしましたが、VirtualHostを動作させることができません。 http://localhost
にアクセスすると問題なく動作し、動作します!ページが表示されます。
しかし、http://test
にアクセスしようとすると、403Forbiddenエラーが表示されます。
このサーバーで/にアクセスする権限がありません。
私の構成は一般的に見えます:
<VirtualHost *:80>
DocumentRoot "/home/johndoe/web/test"
ServerName test
<Directory "/home/johndoe/web/test">
Options Indexes FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
まえがき:
これが発生する理由はいくつかあり、StackExchangeではすでに何度か質問があります。それにもかかわらず、私の場合、どの回答も(直接)それを解決したり、誤った情報や古い情報に基づいていたりしませんでした。
これらの(正しく受け入れられた)回答の多くは、構成されたDocumentRoot
ディレクトリと含まれているファイルおよびディレクトリのアクセス許可または所有権をwww-data
に再帰的に変更するように指示しています。
しかし、最新のDebianまたはUbuntuのローカルインストールについて話すとき(たとえば、基本的なWeb開発の目的で)、これはもう必要ない可能性があります。
ログを見てみましょう!
エラーページ自体には非常に一般的なメッセージが含まれているため、エラーログを確認して詳細情報を取得する必要があります。
Sudo tail -f /var/log/Apache2/error.log
tail
コマンドはファイルの最後の10行を出力し、-f
オプションを使用すると、ログが大きくなる間に出力が更新されます。
ログは何を示していますか?
client denied by server configuration: /home/johndoe/web/test
これは簡単です。 Apache:サーバー構成によってクライアントが拒否されました で説明されているように、Require all granted
設定で構成を更新する必要があります-したがって、次のようになります。
<VirtualHost *:80>
DocumentRoot "/home/johndoe/web/test"
ServerName test
<Directory "/home/johndoe/web/test">
Options Indexes FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all
Require all granted
</Directory>
</VirtualHost>
次のコマンドでApacheを再起動することを忘れないでください。
Sudo service Apache2 restart
エラーは残ります...
しかし、ログメッセージは変更されました:
Symbolic link not allowed or link target not accessible: /home/johndoe/web/test
これにはいくつかの理由があるため、もう少し複雑です。実際の理由を見つけるための良いスタートは、シンボリックリンクを含む宛先を使用せず、代わりに宛先を直接指すように構成を更新することです。ここで、/home/johndoe/web
は/media/johndoe/crypt1/web
へのシンボリックリンクであったため、構成は次のようになります。
<VirtualHost *:80>
DocumentRoot "/media/johndoe/crypt1/web/test"
ServerName test
<Directory "/media/johndoe/crypt1/web/test">
Options Indexes FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all
Require all granted
</Directory>
</VirtualHost>
修正されていますか?
ログメッセージは、より説明的なものに変更された可能性があります。私の場合、それは示しました:
access to / denied (filesystem path '/media/johndoe/crypt1') because search permissions are missing on a component of the path
ここに別のメッセージが表示され、すでに実用的な解決策がある可能性がある場合は、ここでそれぞれのディスカッションにコメントしてリンクすると、他の人も正しい情報を見つけることができます。
そして今?
メッセージは、パスの1つ以上のコンポーネントをトラバースできないため、Apacheがパスに完全にアクセスできないことを示しています。どのコンポーネントが原因であるかを確認するには、次のようにします。
namei -m /media/johndoe/crypt1/web/test/
namei
コマンドはパスコンポーネントを分離して出力し、-m
オプションを使用すると、ls -l
コマンドと同様のスタイルで各コンポーネントのモードビットが表示されます。
私にとって、出力は次のようになりました。
f: /media/johndoe/crypt1/web/test/
drwxr-xr-x /
drwxr-xr-x media
drwxr-x--- johndoe
drwxr-xr-x crypt1
drwxr-xr-x web
drwxr-xr-x test
johndoe
ディレクトリがここで問題を引き起こしているようです。したがって、chmod
を使用して権限を変更する前に、詳しく見てみましょう。
ls -ld /media/johndoe/
-d
オプションを指定したls
コマンドは、ディレクトリの情報(内容ではなく)をリスト-l
スタイルで出力します。
私にとっては次のようになります。
drwxr-x---+ 3 root root 4096 May 28 00:00 /media/johndoe/
ご覧のとおり、そこには+
記号があり、さらに アクセス制御リスト が関係していることを示しています。
自分で[〜#〜] acl [〜#〜]を設定していないと確信していたので、これは最終的に正しい方向を示しました。メディアマウントポイントを自分で設定していないので、さらにNautilusを使用してドライブを暗号化してマウントしました。
これはトリックを行います:
したがって、Nautilusがマウントポイントを台無しにする代わりに、手動でマウントします。
1)すでにマウントされている場合は、マウントを解除します。
Sudo umount /media/johndoe/crypt1
2)/media
の直下にマウントポイントを作成します。
Sudo mkdir /media/crypt1
3)デバイスマッピングを検索してUUIDを見つけます。
ls -l /dev/mapper/
4)それに応じてデバイスを取り付けます。
Sudo mount /dev/mapper/luks-<UUID> /media/crypt1
5)それに応じてApacheの設定やシンボリックリンクを更新します。例:
ln -s /media/crypt1/web/ ~/web
注:
起動するたびにドライブを暗号化してマウントする必要があることに注意してください。ここStackExchangeにはたくさんの情報がありますが、私はお勧めできます: