suPHP環境のWordPressで500エラーになる原因と直し方｜所有者とパーミッション

suPHPは、Apacheで動くPHPを、ファイルの所有者のユーザー権限で実行する仕組みです。共用サーバーで利用者ごとに権限を分けるために使われてきました。suPHPは実行前にファイルの所有者と書き込み権限を調べ、条件に合わないとPHPを実行せず、ブラウザには「500 Internal Server Error」が返ります。

この記事では、suPHP環境のWordPressでこのエラーが出たときに、原因をログから特定し、所有者とパーミッションを直す手順を説明します。

suPHPについて先に知っておくこと

suPHPの公式サイトでは、suPHPはすでにメンテナンスされておらず、セキュリティ修正も提供されないと案内され、代わりにPHP-FPMが挙げられています（2026年11月時点）。いまsuPHPで動いているサイトは、この記事の手順で当面の不具合を直したうえで、PHP-FPMへの移行を計画してください（移行の考え方は記事の後半で説明します）。

よくある症状

• サイト全体、または管理画面（/wp-admin/）だけが「500 Internal Server Error」になる
• プラグインやテーマをアップロードした直後から、そのプラグインの画面だけ500エラーになる
• 書き込めるようにしようとして chmod 777 や chmod 775 を実行したら、かえって表示されなくなった
• .htaccess に php_value の行を追加したら500エラーになった

手順1：エラーログで原因を確かめる

suPHPが実行を拒否した理由は、ApacheのエラーログとsuPHP自身のログに書かれます。まずApacheのエラーログを確認します。

# Debian / Ubuntu
sudo tail -n 50 /var/log/apache2/error.log

# RHEL / AlmaLinux / Rocky Linux
sudo tail -n 50 /var/log/httpd/error_log

suPHPのログの場所は、設定ファイル suphp.conf の logfile に書かれています。設定ファイルの場所はパッケージによって違うので、探してから確認します。

sudo find /etc -name suphp.conf
sudo grep -E '^(logfile|docroot|check_vhost_docroot|allow_|min_uid|min_gid|umask)' /etc/suphp/suphp.conf

（2行目のパスは、1行目で見つかった場所に置き換えます。）

共用サーバーでログを直接見られない場合は、コントロールパネルのエラーログ表示を使うか、サーバー会社に500エラーの時刻を伝えてログの内容を確認してもらいます。

手順2：ログのメッセージから原因を読み取る

suPHPのソースコードにある主なメッセージと、意味は次のとおりです（"…" の部分には実際のファイルパスが入ります）。

suPHPの設定項目 allow_file_group_writeable などは、初期値がいずれも無効です。つまり、標準の設定では「グループや他人が書き込めるファイル・ディレクトリにあるPHPは実行しない」という動きになります。

手順3：所有者をサイトのユーザーにそろえる

suPHPでは、WordPressのファイルは「サイトを持つユーザー」が所有している必要があります。Apacheの実行ユーザー（www-data や apache）や root の所有にすると、上の表のUIDのエラーになります。

以下は、サイトのユーザーが example、WordPressの場所が /home/example/public_html の場合の例です。サーバーの管理者権限（root）で実行します。

# 所有者がサイトのユーザー以外になっているファイルを探す
sudo find /home/example/public_html ! -user example -ls

# 所有者とグループをサイトのユーザーにそろえる
sudo chown -R example:example /home/example/public_html

root で unzip や wp コマンドを実行すると、作られたファイルが root の所有になります。作業はサイトのユーザーで行うか、終わったあとに上の chown で所有者を戻します。

共用サーバーでは chown は使えませんが、FTPやファイルマネージャーでアップロードしたファイルは自分のユーザーの所有になります。所有者の問題が疑われるときは、サーバー会社に問い合わせます。

手順4：パーミッションを 755 / 644 に直す

WordPressの公式ドキュメント（Changing File Permissions）では、suPHPのようにPHPがファイルの所有者として動く環境について、ディレクトリは 755 か 750、ファイルは 644 か 640、wp-config.php は 440 か 400 にするよう案内しています。

cd /home/example/public_html

# グループや他人が書き込めるファイル・ディレクトリを一覧する（直す前の確認）
find . \( -perm -g=w -o -perm -o=w \) -ls

# ディレクトリは 755、ファイルは 644 にする
find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +

# wp-config.php は所有者だけが読めるようにする
chmod 400 wp-config.php

• サイトのユーザーで実行できれば sudo は不要です。共用サーバーでは、SSHが使えればこのまま、使えなければFTPソフトの属性変更で同じ値にします。
• 640 / 750 にすると、ApacheがCSSや画像などの静的ファイルを読めなくなる構成があります。どちらにするか迷ったら、まず 644 / 755 にします。
• wp-config.php を 400 にすると、所有者でも書き込めなくなります。WordPressの設定を書き換えるプラグインを使うときや、自分で編集するときは、一時的に 600 にして、終わったら 400 に戻します。
• ドキュメントルートの親ディレクトリ（/home/example など）がグループや他人から書き込める状態でも、Directory "…" is writeable by group などのエラーになります。ログに出たディレクトリを 755 にします。

「777にすれば書き込める」は suPHP では逆効果

PHPがApacheのユーザーで動く環境向けの古い説明では、wp-content/uploads などを 777 にするよう書かれていることがあります。suPHPではPHPがファイルの所有者として動くため、755 のままで書き込めます。777 にすると「誰からでも書き込める」状態になり、suPHPがPHPの実行を止めて500エラーになります。

手順5：.htaccess の php_value を外す

suPHPではPHPがApacheのモジュール（mod_php）として動いていないため、.htaccess に php_value や php_flag の行があると、Apacheがその命令を解釈できず500エラーになります。エラーログには Invalid command 'php_value' という形で記録されます。

.htaccess から該当の行を削除し、PHPの設定（アップロードの上限など）は、サーバー会社が案内する方法（コントロールパネルのPHP設定や php.ini）で変更します。

手順6：WordPress側で確認する

1. ブラウザでトップページと管理画面を開き、500エラーが出ないことを確認します。
2. 管理画面の「メディア」→「新規追加」で画像をアップロードし、保存できることを確認します。
3. プラグインの更新やインストールで、FTPの接続情報を求める画面が出ないことを確認します。

WordPressは、自分で作った一時ファイルの所有者とWordPress自身のファイルの所有者が同じときに、FTPを使わずに直接ファイルを書き込みます。suPHPで所有者が正しくそろっていれば、FTP情報は求められません。求められる場合は、所有者が混在していないか手順3をもう一度確認します。

suPHPの設定を緩める前に

suphp.conf の allow_file_group_writeable や allow_directory_group_writeable を有効にすると、グループから書き込めるファイルでも実行されるようになります。ただし、利用者どうしのファイルを守るというsuPHPの目的を弱めることになり、公式ドキュメントでも「他人から書き込める」ことを許す設定は危険だと注意されています。基本は、設定ではなくファイルの所有者とパーミッションを直してください。

PHP-FPMへの移行を考える

suPHPと同じように「サイトごとに別のユーザーでPHPを動かす」ことは、PHP-FPMのプール（pool）でもできます。プールごとに user と group を指定し、Apacheからは mod_proxy_fcgi でそのプールへ渡す構成が一般的です。PHP-FPMは現行のPHPに含まれ、更新も続いています。

移行するときは、検証用の環境でサイトごとにプールを作り、ファイルの所有者をプールのユーザーにそろえたうえで、上の手順6と同じ確認をしてから切り替えます。共用サーバーの場合は、サーバー会社が提供している現行のPHP実行方式を確認し、必要ならPHP-FPMに対応したプランへの移行を検討します。

まとめ

• suPHPは、グループや他人が書き込めるファイル、所有者が合わないファイルのPHPを実行せず、500エラーを返します。
• 原因はApacheとsuPHPのエラーログに、is writeable by group や smaller than min_uid などのメッセージで記録されます。
• 所有者をサイトのユーザーにそろえ、ディレクトリ 755・ファイル 644・wp-config.php 400 にすると、多くの場合は解決します。777 にすると逆に動かなくなります。
• .htaccess の php_value は suPHP では使えません。
• suPHPはメンテナンスが終わっているため、PHP-FPMへの移行を計画します。

• WordPressのファイルパーミッションの正しい設定（755/644と所有者の確認手順）
• WordPressのパーミッションエラーを直す方法