サーバ作業で「Permission denied」が出たとき、検索すると「chmod 777にすれば直る」と見かけることがあります。しかし、777は“全員に広く許可する”設定であり、確かに一時的に動くことはあっても、事故や改ざんの入口になりやすい値です。とくにWeb公開領域や共有環境では、意図しない第三者（同居ユーザー、侵害された別アプリ、誤操作した担当者など）に「書ける状態」を与えることになり、被害の範囲が広がりやすくなります。
一方で、権限エラーは「chmodだけで解決できる」ものばかりではありません。所有者（owner）やグループ（group）の不整合、WebサーバやPHPの実行ユーザー、ACL、umaskなど、根本原因が別にあると、777で“力技”をしてしまいがちです。本記事では、chmod 777の意味を正しく理解したうえで、777に頼らずに原因を解消する手順と、用途別の推奨パーミッション（権限）を体系的に整理いたします。WordPressなどWeb運用で迷いやすいポイントも、判断基準とセットでご説明いたします。
※本コンテンツは「記事制作ポリシー」に基づき、正確かつ信頼性の高い情報提供を心がけております。万が一、内容に誤りや誤解を招く表現がございましたら、お手数ですが「お問い合わせ」よりご一報ください。速やかに確認・修正いたします。
chmod 777が意味する権限
777の内訳とrwxの対応
chmodの数値モードは、権限を「読み取り（read）=4」「書き込み（write）=2」「実行（execute）=1」の合計で表す方式です。各桁は0〜7（8進数）で、3桁の場合は次の順に並びます。
1桁目：所有者（user / owner）
2桁目：グループ（group）
3桁目：その他（others）
7は 4+2+1 ですので rwx を意味します。したがって 777は「所有者・グループ・その他の全員に、読み取り・書き込み・実行を許可する」 という状態です。
具体例で見ると、次のようになります。
| 数値 | 記号 | 意味 |
|---|---|---|
| 0 | — | 権限なし |
| 1 | –x | 実行のみ |
| 2 | -w- | 書き込みのみ（実務上は扱いに注意） |
| 3 | -wx | 書き込み+実行 |
| 4 | r– | 読み取りのみ |
| 5 | r-x | 読み取り+実行 |
| 6 | rw- | 読み取り+書き込み |
| 7 | rwx | 読み取り+書き込み+実行 |
この「7」を3回並べた777は、権限としては最大級です。つまり「そのファイル（またはディレクトリ）に対して、ほぼ何でもできる人が“全員”になる」設定です。エラーを一時的に消しやすい反面、不要な人にも扉を開けるため、セキュリティ上は原則避けるべきです。
ファイルとディレクトリで影響が変わるポイント
同じrwxでも、対象が「ファイル」か「ディレクトリ」かで実際の影響が変わります。ここが理解できると、777が危険な理由がより腹落ちしやすくなります。
ファイルに対するrwx
r（読み取り）
ファイルの内容を読み取れます（例：設定ファイル、ソースコード、ログなど）。w（書き込み）
ファイルの内容を書き換えられます。Web公開領域でwが広いと、改ざんや不正コード混入の温床になり得ます。x（実行）
バイナリやスクリプトとして実行できます。xが付くと「置かれたものが動く」状態になり、攻撃者にとって好都合になりやすいです。
ディレクトリに対するrwx
r（読み取り）
そのディレクトリの「一覧（ファイル名の列挙）」を見られます。w（書き込み）
そのディレクトリ内で、ファイルの作成・削除・名前変更ができます（※ファイルそのものの書き換え権限とは別問題になる場合があります）。x（実行）
「そのディレクトリに入れる」「パスとして到達できる」「中のファイルにアクセスできる」権限です。ディレクトリのxは、アクセス可否の要といえます。
重要なのは、ディレクトリのwが付くと“中身を増やせる・消せる” 方向に効きやすい点です。たとえば uploads のように「Webアプリがファイルを生成・保存する」場所に必要な書き込み権限はありますが、サイト全体を置くディレクトリまで誰でもwにしてしまうと、改ざんの余地が大きくなります。さらにxが付いていれば、そこに置かれたファイルへ到達もできてしまいます。
数値モードとシンボリックモードの使い分け
chmodは、数値（例：chmod 755）だけでなく、シンボリック（例：chmod g+w）でも指定できます。安全性・意図の明確さという観点では、次の使い分けが有効です。
数値モードが向く場面
あるべき状態が明確で、まとめて整えるとき（例：ディレクトリは755、ファイルは644で統一）
変更後の期待値が固定されているとき
シンボリックモードが向く場面
「差分だけ」変えたいとき（例：グループに書き込みだけ追加する）
誤って他の権限を落としたくないとき（例：
chmod g+wは “g の w だけ追加”）
例として、以下は意味が異なります。
chmod 775 dir：dirの権限を 丸ごと775にするchmod g+w dir：dirの グループ書き込み（w）だけ追加する
とくに本番環境では「意図せず権限を落として障害を起こす」ことも避けたいので、差分変更を使い分けると安全性が上がります。
chmod 777が危険と言われる理由
事故が起きる典型パターン
chmod 777が危険と言われるのは、「誰でも書ける」「誰でも実行できる」状態を作りやすいからです。典型的には、次のような事故パターンにつながります。
Web公開領域に不正ファイルを置かれる
例：画像アップロードに見せかけたスクリプト、バックドア、Webシェルなど。
777が存在すると「置ける・動かせる」条件が整いやすくなります。既存ファイルが改ざんされる
index.phpやテンプレート、設定ファイルが書き換えられ、リダイレクトやマルウェア配布に利用されることがあります。削除・リネーム事故が起きる
ディレクトリに777を付けると、誤操作やスクリプトの暴走で大量削除が起きた場合に“止める壁”がなくなります。原因切り分けが困難になる
777で動いてしまうと「何が原因だったのか」が見えにくくなり、後から適切な権限に戻す際に再発しやすくなります。
つまり、777は「復旧の手段」というより「問題の押し込め」であり、後でより大きなトラブルを招きやすいのが本質です。
共有環境でリスクが増える条件
共有環境（同一サーバ上に複数ユーザーや複数サイトが同居する環境）では、リスクがさらに高まります。理由は単純で、「その他（others）」に権限を与える＝同居する別ユーザーの影響も受けやすい ためです。
同居ユーザーのプロセスがアクセスできてしまう
別サイトが侵害された場合、横展開（別サイトへの影響）が起きやすくなる
サーバ運用ポリシーとしても、監査やセキュリティ指摘の対象になりやすい
「自分しか触らないから大丈夫」と思っていても、同居環境では“自分以外の誰か”が存在し得るため、777は避けるべきです。
どうしても避けられないと感じる場面の正体
「777にしないと動かない」状況は、ほとんどの場合、根本原因が別にあります。代表的な原因と、見落としポイントを整理します。
所有者が違う
例：rootで配置したファイルを、Webアプリ実行ユーザーが書けない。
→ 777にすると書けるが、本来は所有者・グループを整えるべきです。実行ユーザーが想定と違う
例：Apache/PHP-FPMの実行ユーザーが www-data や nginx で、所有者が別ユーザー。
→ “誰が書くか”が揃っていません。書き込み先が設計として誤っている
例：アプリがアプリ領域（コード領域）にログやキャッシュを書こうとしている。
→ 書き込み先を /var や専用の writable ディレクトリに逃がすべきです。ACLが効いている
chmodで見えるrwxだけでは判断できず、実際にはACLで拒否されている、または逆に許可されている場合があります。umaskの影響
作成時のデフォルト権限が絞られていると、生成されたファイルが意図より厳しくなり、後続処理で失敗することがあります。
777はこれらの原因を無視して“全員許可”で回避するため、問題が見えなくなります。適切な対処は「誰が書く必要があるのか」「どこに書くべきなのか」を定義し、所有者・グループ・権限を最小限で満たすことです。
chmod 777の代替となる推奨権限の決め方
よく使う権限一覧と用途
まずはよく使うパターンを「目的」とセットで覚えると、判断が速くなります。以下は一般的な目安です（環境によって調整が必要です）。
| 用途 | ディレクトリ例 | ファイル例 | 想定する運用 |
|---|---|---|---|
| 一般的なWeb公開 | 755 | 644 | 公開は読み取り中心、更新は所有者が行う |
| 共同作業（同一グループで更新） | 775 | 664 | グループに書き込みを許可 |
| 機密（秘密鍵・設定など） | 700 | 600 | 所有者のみアクセス |
| 実行ファイル・スクリプト | 755 | 755 | 読めて実行できる（書き込みは所有者のみ） |
| 一時ファイル置き場（限定的） | 770 | 660/664 | 特定グループ内だけで生成・削除 |
ここで重要なのは、「必要な主体にだけ書き込みを渡す」 ことです。777は「主体の定義を放棄」してしまうため、代替としては 755/775/644/664 を中心に、“誰が更新するか”に沿って選ぶのが基本方針になります。
Webサーバ運用での推奨例
Webサイト運用で典型なのは、次の二つです。
コード（アプリ本体、テンプレート、プラグイン本体）：原則として書き込み不要
生成物（アップロード、キャッシュ、ログ）：書き込みが必要な場所がある
この分離ができると、権限設計が非常に簡単になります。
例：基本方針（目安）
コード領域
ディレクトリ：755
ファイル：644
“更新作業をするユーザー”が所有者であることが望ましい
生成物領域（uploads、cache等）
ディレクトリ：755または775（誰が書くかで選ぶ）
ファイル：644または664
Webサーバが書く場合は、所有者・グループの整合を取る
「全部777」にすると、この分離が崩れ、コード領域まで書き込み可能になります。したがって、まずは“書き込みが必要な場所”を限定することが第一歩です。
共同作業での権限設計の考え方
複数人・複数プロセスが関わる場合、777ではなく「グループ」を使った設計が王道です。考え方は次の通りです。
更新に関わる人（またはプロセス）を同一グループに入れる
グループに書き込みを許可する（775/664など）
作成物のグループが揃い続ける仕組みを用意する
例：ディレクトリにsetgidを付ける、umaskを調整する、デプロイ手順を統一する
とくに「作成した人が違うと、次の人が書けなくなる」問題は頻出です。これを777で逃げるのではなく、グループ運用と作成時ルール（umask等）で揃えると、長期的に安定します。
chmod 777を使わずにPermission deniedを解消する手順
現状確認のコマンド
権限問題は「いま何が起きているか」を正確に把握するのが最短ルートです。以下の順で確認すると、原因の当たりが付けやすくなります。
1. 権限・所有者・グループを確認する
対象ファイル（またはディレクトリ）の表示
ls -l /path/to/file
対象ディレクトリ自体の表示（
-dが重要です）ls -ld /path/to/dir
出力例のイメージ：
-rw-r--r-- 1 alice staff ... file.txt
→ 所有者 alice、グループ staff、権限は 644相当drwxr-xr-x 2 alice staff ... dir
→ ディレクトリ、権限は 755相当
2. “どのユーザーが”実行して失敗しているかを確認する
同じ操作でも、実行ユーザーが違うと結果が変わります。
SSHで作業しているユーザーは誰か
Webアプリ（PHP、Node、Python等）はどのユーザーで動いているか
バッチやcronは誰の権限で動いているか
ここが曖昧だと、正しい権限を決められません。
3. 失敗している操作は「読み取り」か「書き込み」か「到達」かを切り分ける
読めない：rが足りない可能性
書けない：wが足りない、または所有者・グループ不整合
ディレクトリに入れない：ディレクトリのxが足りない可能性
ディレクトリのxは特に見落とされがちです。rがあってもxがないと到達できず、結果として操作が失敗します。
所有者と実行ユーザーの見直し
chmodだけを調整しても直らない原因として、最も多いのが所有者問題です。典型例を挙げます。
デプロイ時にrootでファイルを配置した
→ 所有者がrootになり、Webアプリ実行ユーザーが書けないFTPで別ユーザーとしてアップロードした
→ 所有者・グループが揃わず、更新系処理が失敗する
この場合、正攻法は「所有者（owner）とグループ（group）を運用方針に合わせる」ことです。考え方の整理として、次の問いに答えてください。
そのファイル（ディレクトリ）に 書き込むべき主体は誰か
人が更新するのか
Webアプリが生成するのか
バッチが生成するのか
その主体は どのユーザー／グループ として実行されるのか
この答えが定まれば、権限は最小限にできます。逆に、主体が曖昧だと、777のように“全員”へ逃げるしかなくなります。
なお、レンタルサーバ等でchownが許可されない場合もあります。その場合は、サーバ事業者の推奨手順（FTPユーザー統一、管理画面での権限調整、実行ユーザーの仕様確認など）に従って「主体を揃える」方向で検討してください。
再帰変更が必要な場合の安全なやり方
権限をまとめて直したい場面はありますが、ここで chmod -R 777 を実行してしまうのは避けるべきです。理由は「対象が広がりすぎる」ことと、「ファイルとディレクトリを同一扱いにしてしまう」ことです。
安全に進める基本戦略は、次の3点です。
対象範囲を限定する（アプリ全体ではなく、問題のディレクトリだけ）
ディレクトリとファイルを分ける
変更前後を記録し、差分確認できるようにする
手順1 変更対象を限定して把握する
まず、いきなり変更せず、対象がどれだけあるかを把握します。
ディレクトリ一覧（先頭だけ見る）
find /path -type d | head
ファイル一覧（先頭だけ見る）
find /path -type f | head
「思っていたより広い範囲を対象にしていた」という事故を防ぐため、必ず範囲を目視できる形にしてください。
手順2 ディレクトリとファイルで分けて設定する
一般的なWeb公開の目安として、ディレクトリは755、ファイルは644を当てる場合、次のように分けます。
ディレクトリだけを755へ
find /path -type d -exec chmod 755 {} \;
ファイルだけを644へ
find /path -type f -exec chmod 644 {} \;
この分離には大きな意味があります。ファイルにx（実行）を無条件に付ける必要は基本的にありませんし、ディレクトリはxがないと到達できません。分けて設定するだけで、「余計に開ける」リスクが減り、「必要なところが足りない」事故も減ります。
手順3 変更後の動作確認と不足分の追加
権限は 最小限から始めて、必要な分だけ足す のが安全です。例として、アップロードが失敗する場合でも、サイト全体を緩める必要はなく、書き込みが必要なディレクトリ（uploadsなど）に限定すべきです。
まずは限定範囲へ適用
動作確認
まだ失敗するなら、次に見るべきは「所有者」「実行ユーザー」「書き込み先の妥当性」です
それでも必要であれば、グループにwを足す（775/664等）という段階的な調整をします
「777にする前に、どこに書きたいのか」を見ていけば、多くの場合は最小限の変更で解決できます。
変更後の検証と戻し方
変更作業は「戻せる」状態にしておくのが安全です。検証と戻し方の枠組みを先に用意してください。
変更後の検証観点
目的の操作が成功するか
例：アップロード、更新、キャッシュ生成、ログ出力、プラグイン更新など
重要ファイルが緩んでいないか
例：設定ファイル、鍵、バックアップ、.env等
777が残っていないか（特に公開領域）
意図せず混入しているケースがあります
変更前後の記録（例）
権限の記録は、トラブル時の復旧速度に直結します。例として、権限を簡易に記録して差分を取る方法を示します。
変更前
find /path -printf "%m %p\n" > perms_before.txt
変更後
find /path -printf "%m %p\n" > perms_after.txt
差分確認
diff perms_before.txt perms_after.txt
この記録があれば、「どこを変えたか」「意図しない変更がないか」を追跡できます。特に複数人で運用している場合、変更履歴がない状態で権限だけ変えると、後から原因究明が難しくなります。
chmod 777で起きたトラブルの対処と予防
すでに777にした場合のリカバリー
すでに777にしてしまった場合でも、落ち着いて段階的に戻せば大丈夫です。優先順位を付けて進めてください。
優先順位1：公開領域の777を解消する
まずは外部から到達し得る公開領域（ドキュメントルート配下など）を確認し、777があれば速やかに解消します。基本は次の戻し方が目安になります。
ディレクトリ：755
ファイル：644
ただし、アプリが書き込む必要があるディレクトリ（uploads等）は、所有者・グループ設計に応じて 775/664 といった形に調整します。「書く必要がある場所だけ」を例外として扱うのがポイントです。
優先順位2：機密ファイルを絞る
777の影響が最も深刻になりやすいのは、機密ファイルが緩んでいる場合です。次のようなファイルがあるなら優先的に絞ってください。
設定ファイル（DB接続、APIキー）
秘密鍵、証明書
バックアップファイル（zip、sql、tar等）
.env など環境変数ファイル
目安は 600〜640 相当（運用要件で調整）です。
優先順位3：なぜ777が必要に見えたかを再調査する
最後に、根本原因を潰します。ここを省略すると再発します。
所有者・グループは適切か
実行ユーザーは想定通りか
書き込み先は適切か（コード領域に書いていないか）
ACLやumaskで想定外の制約・許可がないか
777は「一時的に動かす」には強力ですが、長期的には“原因が見えない状態”を作ります。必ず原因を言語化し、再発しない形に落とし込むことが重要です。
監査と再発防止チェックリスト
再発防止は「ルール化」と「点検」で強くなります。以下のチェックリストを、変更作業のたびに確認する運用が有効です。
変更前の確認チェックリスト
失敗している操作（読み取り／書き込み／到達）を特定している
実行主体（ユーザー／グループ）を特定している
対象範囲を限定している（サイト全体ではなく必要箇所）
変更前の権限を記録している（差分確認できる）
変更後の検証チェックリスト
目的の操作が成功する（アップロード等）
777が残っていない（特に公開領域）
機密ファイルが緩んでいない（600〜640等）
ディレクトリとファイルが適切に分離されている（755/644等）
運用の再発防止チェックリスト
デプロイ手順（誰が配置するか）が統一されている
共同作業のグループ設計があり、必要な箇所だけグループ書き込みを付与している
書き込みが必要なディレクトリが限定されている（コード領域は原則読み取り）
変更履歴（誰がいつ変更したか）を残している
よくある質問
777にしないと動かないのはなぜですか
多くの場合、原因は「所有者と実行ユーザーの不整合」または「書き込み先の設計」にあります。777は“誰でも書ける”ため、問題を強制的に回避できますが、原因が解消されたわけではありません。次の順で見直してください。
誰が書く必要があるか（人／Webアプリ／バッチ）
実行ユーザーは誰か
所有者・グループは揃っているか
書き込み先は限定されているか
これを整理すると、777を使わずに解決できるケースが多いです。
chmod -R 777はどこまで危険ですか
危険度は「範囲」と「環境」で決まります。公開領域に広く適用すると、改ざんや不正ファイル設置の余地を増やします。共有環境では、同居ユーザーの影響も考慮が必要になり、さらに危険度が上がります。再帰変更が必要でも、対象限定とディレクトリ／ファイル分離を徹底してください。
755と775はどう選べば良いですか
判断基準は「グループにも書き込みが必要か」です。
755：所有者だけが書ければよい（一般的なWeb公開の基本）
775：同一グループのメンバーも書く必要がある（共同作業、特定プロセスと共有）
775を使う場合は、グループ設計（誰をそのグループに入れるか）と、作成物のグループを揃える仕組み（setgidやumask等）もセットで整えると安定します。
644にしたら実行できなくなりました
644は「読み取り・書き込み（所有者のみ）・実行なし」です。実行が必要なファイルにはxが必要です。スクリプトや実行ファイルは755など、用途に応じて実行権を付与してください。逆に、実行が不要なファイルにxを付けないことは、攻撃面を減らす観点でも有効です。
ACLがあると何が違いますか
ACLが有効な環境では、通常のrwx（所有者・グループ・その他）に加えて、個別ユーザーやグループへ追加の許可・拒否が設定される場合があります。そのため、chmodで見える権限だけでは挙動が説明できないことがあります。chmodで直らない場合は、ACLの有無とルールを確認することが次の一手になります。
まとめ
chmod 777は「所有者・グループ・その他の全員に、読み書き実行を許可する」設定であり、エラーを一時的に消しやすい反面、改ざん・不正ファイル設置・誤削除などの事故リスクを増やします。安全に解決するためには、次の流れが有効です。
どの操作が失敗しているか（読み取り／書き込み／到達）を切り分ける
誰が実行して失敗しているか（実行ユーザー）を特定する
所有者・グループの整合を取り、「誰に書かせるか」を明確にする
書き込みが必要な場所を限定し、ディレクトリとファイルで権限を分けて最小限から調整する
変更前後を記録し、差分確認と戻し方を用意する
また、ミドルウェアや運用方式の変更により「誰がどこに書くか」は変わり得ます。権限設定は一度決めて終わりではなく、定期的な点検と変更履歴の管理で安全性を維持してください。