2026年5月27日

WordPressのファイルパーミッション設定のベストプラクティス：755/644の意味と所有者の決め方

セキュリティ

WordPress のパーミッションは、基本を「ディレクトリ 755・ファイル 644・wp-config.php は 640 か 600」とし、777 は使わない、が出発点です。ただし数字だけ合わせても、ファイルの所有者と PHP の実行ユーザーの関係が噛み合っていないと「更新できない」「書き込めない」が起きます。この記事では、数字の意味、サーバー構成ごとの所有者の決め方、一括で直すコマンド、wp-config.php の定数による補強までを順に説明します。

パーミッションの数字が表すもの

755 や 644 の3桁は、左から「所有者」「グループ」「その他」に対する権限です。各桁は読み取り（4）・書き込み（2）・実行（1）の合計で表します。

644：所有者は読み書き、グループとその他は読み取りのみ
755：所有者は読み書き実行、グループとその他は読み取りと実行
640：所有者は読み書き、グループは読み取り、その他は権限なし
600：所有者だけが読み書きでき、ほかは一切アクセスできない

ディレクトリの「実行」は「中に入ってファイルを参照できる」という意味です。ディレクトリから実行権を外すと、中のファイルが 644 でも読めなくなります。逆に PHP ファイルに実行権は不要で、PHP はファイルを「読んで」解釈します。

推奨値の一覧と理由

WordPress の公式ドキュメント（Advanced Administration Handbook のファイルパーミッションの項）で示されている考え方に沿うと、目安は次のとおりです。

対象	目安	理由
ディレクトリ全般	755	中身の参照は許可し、書き込みは所有者だけ
ファイル全般	644	読み取りは許可し、書き換えは所有者だけ
wp-config.php	640 または 600	DB パスワードや認証用キーを含むため、その他ユーザーから読めないようにする
.htaccess	644	Apache が読めればよい。WordPress が書き換える構成なら所有者を合わせる
wp-content/uploads	755（中のファイルは 644）	PHP の実行ユーザーが書き込めるよう所有者を合わせる

wp-config.php を 600 にできるかどうかは、PHP がどのユーザーで動いているかで決まります。PHP がファイルの所有者と同じユーザーで動く構成なら 600 で問題ありません。所有者が別ユーザーで、PHP の実行ユーザーがグループ経由で読む構成なら 640 にします。設定後にサイトが「データベース接続確立エラー」や真っ白な画面になったら、PHP から読めていないということなので、640 に戻して所有者とグループを確認してください。

777 は「誰でも書き込める」状態です。共有サーバーでは同じサーバーの他ユーザーのプロセスからも書き換えられる可能性があり、不正なファイルを置かれる入口になります。「書き込めないから 777 にした」は、所有者の設定が原因の問題を権限で覆い隠しているだけなので、次の章の方法で所有者側を直します。

本当に大事なのは「所有者」と「PHPの実行ユーザー」

WordPress がプラグインの更新や画像のアップロードでファイルを書き込めるかどうかは、パーミッションの数字よりも「PHP がどのユーザーで動いていて、そのユーザーがファイルの所有者かどうか」で決まります。主な構成は3つです。

共有レンタルサーバー（suEXEC や PHP-FPM のユーザー別プール）：PHP が契約者のユーザー名で動きます。FTP でアップロードしたファイルも同じ所有者になるため、755/644 のままで更新もアップロードもできるのが普通です。サーバー会社が推奨値を公開していることが多いので、まずそれに従います。
VPS で PHP-FPM のプールをサイト専用ユーザーで動かす構成：たとえばサイト用ユーザー wpuser を作り、PHP-FPM のプールの user と group を wpuser にします。ファイルの所有者も wpuser にそろえれば、755/644 のまま WordPress 自身が書き込めます。
VPS で PHP が www-data（Debian/Ubuntu 系）や apache・nginx（RHEL 系）で動く構成：ファイルの所有者を作業用ユーザーにし、グループを Web サーバーのユーザーにする方法がよく使われます。この場合、WordPress から書き込ませたい場所（wp-content/uploads など）だけグループに書き込み権を与えます。

PHP の実行ユーザーは、次のような小さな PHP ファイルで確認できます。確認が済んだらすぐに削除してください。

<?php
// whoami.php（確認後すぐ削除する）
echo function_exists( 'posix_geteuid' )
	? posix_getpwuid( posix_geteuid() )['name']
	: get_current_user(); // 取得できない環境では所有者名が返る点に注意

管理画面の「ツール」→「サイトヘルス」の「情報」タブにも、ファイルシステムの書き込み可否を一覧で表示する項目があります（項目名はバージョンで異なる場合があります）。どのディレクトリが書き込めないかを把握する入口として便利です。

現状を確認するコマンド

SSH で WordPress のルートディレクトリに移動し、現状を確認します。stat の書式指定は GNU coreutils（一般的な Linux）のものです。

# 主要ファイルの権限と所有者を表示
stat -c '%a %U:%G %n' wp-config.php .htaccess wp-content wp-content/uploads

# 777 になっているディレクトリ・ファイルを探す
find . -perm -o+w -not -type l -print

# 所有者が想定と違うファイルを探す（wpuser は自分の環境に置き換える）
find . -not -user wpuser -print | head -50

2つ目のコマンドで何か見つかったら、まずその理由を調べます。キャッシュプラグインやバックアッププラグインが自分で作ったディレクトリのこともあれば、過去に誰かが手作業で 777 にした跡のこともあります。

一括で推奨値に戻す手順

一括変更の前に、ファイルと DB のバックアップを取得してください。ステージングがあれば先にそちらで試し、表示・ログイン・プラグイン更新・画像アップロードの4点を確かめてから本番に適用します。

cd /var/www/example.com/public_html   # WordPress のルート（自分の環境に置き換える）

# 所有者をそろえる（構成2の例。root 権限が必要）
sudo chown -R wpuser:wpuser .

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

# wp-config.php は 640（PHP が所有者と同じユーザーで動くなら 600 でもよい）
chmod 640 wp-config.php

構成3（所有者は作業用ユーザー、グループは Web サーバー）の場合、書き込みが必要な場所だけグループに書き込み権を与えます。

sudo chown -R deploy:www-data .
find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +

# アップロード先だけ PHP（www-data グループ）から書き込めるようにする
find wp-content/uploads -type d -exec chmod 775 {} +
find wp-content/uploads -type f -exec chmod 664 {} +
chmod 640 wp-config.php

この構成では、WordPress の管理画面からプラグインやコアを更新すると書き込めないため、更新は WP-CLI を deploy ユーザーで実行する運用になります。手間は増えますが、PHP が乗っ取られてもコアやプラグインのファイルを書き換えにくいという利点があります。

レンタルサーバーで SSH が使えない場合は、FTP クライアントの属性変更機能で同じ値を設定できます。ただし所有者は変更できないので、所有者が原因の問題はサーバー会社のサポートに相談します。

wp-config.phpの定数で補強する

wp-config.php には、ファイル操作に関係する定数があります。定数は /* That's all, stop editing! */ の行より上に書きます。

<?php
// 管理画面のテーマ・プラグインファイルエディターを無効にする
define( 'DISALLOW_FILE_EDIT', true );

// プラグイン・テーマのインストールと更新、コア更新も管理画面から行わない
// （WP-CLI やデプロイで更新する運用の場合のみ）
// define( 'DISALLOW_FILE_MODS', true );

// WordPress が新しく作るファイル・ディレクトリの権限
define( 'FS_CHMOD_DIR', ( 0755 & ~ umask() ) );
define( 'FS_CHMOD_FILE', ( 0644 & ~ umask() ) );

DISALLOW_FILE_EDIT は、管理者アカウントが乗っ取られたときに管理画面から PHP コードを書き換えられる経路を塞ぐもので、多くのサイトで有効にして困ることはありません。DISALLOW_FILE_MODS はより強い制限で、管理画面からの更新もできなくなります。自動更新も止まるため、更新を別の手段で回す体制がある場合に限って使います。

FS_METHOD を 'direct' にすると、更新時に FTP 情報を尋ねる画面を出さずに直接書き込もうとします。ただし所有者の問題を解決せずにこれだけ設定すると、書き込みに失敗するか、ファイルを 777 にしないと動かない状態に陥りやすいので、先に所有者をそろえてから判断します。

よくあるつまずきと対処

「更新のために FTP 接続情報が必要です」と表示される：WordPress が直接書き込めないと判断したサインです。PHP の実行ユーザーとファイルの所有者が一致しているかを確認します。
画像をアップロードすると「ディレクトリを作成できませんでした」と出る：wp-content/uploads とその年月ディレクトリの所有者・権限を確認します。「設定」→「メディア」のアップロード先の設定が古いパスのままになっていないかも見ます。
403 エラーになる：ディレクトリの実行権が外れている、または .htaccess が Web サーバーから読めないことがあります。
500 エラーになる：suEXEC 系の共有サーバーでは、PHP ファイルやディレクトリにグループやその他の書き込み権があると、安全のため実行を拒否する設定のサーバーがあります。775 や 777 を 755 に戻すと解消することがあります。
変更後にキャッシュやバックアップのプラグインがエラーを出す：プラグインが専用ディレクトリに書き込めなくなった可能性があります。そのディレクトリだけ所有者を PHP の実行ユーザーに合わせます。

パーミッションは安全対策の一部にすぎず、これだけで改ざんを防げるわけではありません。コア・テーマ・プラグインの更新、管理者アカウントの強いパスワードと2段階認証、定期的なバックアップと組み合わせて考えてください。サーバー会社の推奨値や管理画面の表記は変わることがあるため（2026年10月現在）、作業前に利用中のサーバーの案内も確認してください。

まとめ

基本はディレクトリ 755、ファイル 644、wp-config.php は 640 か 600。777 は使わない。
書き込めない問題の多くは数字ではなく所有者の問題。PHP の実行ユーザーを確認し、所有者をそろえる。
一括変更は find と chmod で行い、作業前にバックアップ、可能ならステージングで先に試す。
書き込みが必要な場所だけ権限を広げ、それ以外は読み取り専用に近づける。
DISALLOW_FILE_EDIT で管理画面のファイルエディターを無効にし、FS_METHOD は所有者をそろえてから検討する。