この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
そんな経験をしたことはないでしょうか。
私がSE時代に最も冷や汗をかいたのが、本番サーバーでのchmod操作ミスでした。20年以上Linuxサーバーを運用してきた経験の中で、権限に関するトラブルは「知識があっても起きる」という厄介な特徴を持っています。
この記事では、私が実際に犯した権限ミスの体験談と、そこから学んだパーミッション設計の考え方を解説します。
コマンドの使い方ではなく、「なぜ権限設計が難しいのか」「どう考えれば事故を防げるのか」を、現場の経験から伝えます。
この記事のポイント
・chmod 777 の「とりあえず解決」が本番障害を生む理由
・SE時代の失敗：-R オプション1つで設定ファイルが読めなくなった経緯
・権限設計は「最小権限の原則」が現場での正解
・変更前のバックアップと確認コマンドがミスを防ぐ唯一の方法
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
「とりあえず777にすれば動く」が最大の落とし穴
エラーが出た時に「chmod 777 で全部解決した」という話をセミナーでよく聞きます。確かに、777 を設定すれば誰でも読み書き実行できるようになるので、権限由来のエラーは消えます。でもそれは、鍵のかかった部屋の扉を外してしまうのと同じです。
私が3,100名以上の受講生を指導してきた中で気づいたのは、「chmod 777 で解決した」経験を持つ人が、同じミスを本番環境でも繰り返しやすいということです。
動くから正しい、ではありません。権限設定は、意図的に設計するものです。
SE時代に実際に起こした権限ミスの話
SE時代（2001年～2006年）、私は受託システムの本番Linuxサーバーを管理していました。あるWebアプリケーションのアップデート作業中に、デプロイスクリプトが途中でエラーを吐きました。
原因を調べると、ディレクトリのグループ権限が足りなかった。焦っていた私は、対象ディレクトリ配下を一括で修正しようと、次のコマンドを実行しました。
# 意図: デプロイ用ディレクトリの権限を修正 chmod -R 775 /var/www/html/app
設定ファイルに実行権限（x）が付いたことで、一部のCGIセキュリティチェックが「設定ファイルに実行権限があるのは不正」と判断し、アプリが起動しなくなったのです。
その後の復旧に3時間かかりました。正確には、バックアップからの復元ではなく、ファイル1つ1つの正しい権限を確認しながら手動で修正したのです。当時はファイルごとの権限をメモしておく習慣がなく、「本来は何の権限だったか」を全部手で追うことになりました。
1. なぜ -R オプションは危険なのか
`chmod -R` は、ディレクトリ配下の全ファイルに同じ権限を再帰的に適用します。便利に見えますが、現場では「ディレクトリには実行権限が必要、ファイルには不要」という区別が必須です。
例えば、ディレクトリのアクセスに `x` 権限が必要な理由は「中のファイルにアクセスするため」です。一方、テキストファイルや設定ファイルに `x` 権限は通常必要ありません。
ディレクトリとファイルを分けて処理するなら、こう書きます：
# ディレクトリのみ 755 に設定 find /var/www/html/app -type d -exec chmod 755 {} \; # ファイルのみ 644 に設定 find /var/www/html/app -type f -exec chmod 644 {} \; # 実行スクリプトのみ 755 に設定 find /var/www/html/app -name "*.sh" -exec chmod 755 {} \;
2. 変更前に現状を必ずメモする習慣
あの失敗以来、私は権限変更の前に必ず現状をファイルに書き出すようにしました。# 変更前の権限状態をバックアップとして保存 ls -lR /var/www/html/app > /tmp/perm_backup_$(date +%Y%m%d_%H%M%S).txt # 確認 cat /tmp/perm_backup_20060315_142300.txt
当時の自分に一番伝えたいのは、「変更前のスクリーンショットやログが命綱になる」ということです。
現場で実践している権限設計の考え方
あの失敗から20年が経ち、今はセミナーの受講生に権限設計を教える立場になりました。私が伝えているのは「最小権限の原則」だけです。
3. 最小権限の原則を守る3つの問い
権限を設定する前に、次の3つを自問するクセをつけると事故が減ります：・このファイルを「誰が」読む必要があるか（所有者 / グループ / その他）
・このファイルを「誰が」書き込む必要があるか
・このファイルを「実行」する必要があるか（あるとしたら誰が）
ほとんどのWebアプリケーションの設定ファイルは、「所有者だけが読み書き、グループが読むだけ、その他はアクセス不要」です。つまり `640` が適切なことが多い。
以下は私が現場でよく使う権限の組み合わせです：
| 対象 | 推奨権限 | 理由 |
|---|---|---|
| Webドキュメントルート（ディレクトリ） | chmod 755 /var/www/html |
Apacheが読めること、書き込みは不要 |
| 一般的なファイル | chmod 644 ファイル名 |
所有者が読み書き、他は読み取りのみ |
| 設定ファイル（パスワード含む） | chmod 600 ファイル名 |
所有者だけが読み書き、他は一切不可 |
| シェルスクリプト | chmod 755 スクリプト名.sh |
所有者が読み書き実行、他は読み実行のみ |
| グループで共同作業するディレクトリ | chmod 770 ディレクトリ名 |
所有者とグループだけアクセス、他は不可 |
4. 権限変更後の必須確認コマンド
変更後は、意図した権限になっているか必ず `ls -la` で確認します。# 変更後の確認 ls -la /var/www/html/app/ # 出力例（実際のサーバー） drwxr-xr-x 4 www-data www-data 4096 Mar 15 14:30 . drwxr-xr-x 3 root root 4096 Mar 10 09:20 .. -rw-r--r-- 1 www-data www-data 512 Mar 15 14:28 config.ini -rwxr-xr-x 1 www-data www-data 2048 Mar 12 11:00 deploy.sh -rw-r--r-- 1 www-data www-data 8192 Mar 15 14:25 index.php
先頭の10文字のうち、2～4文字目が所有者、5～7文字目がグループ、8～10文字目がその他の権限を示しています。
「なんとなく権限を変えてきた人」が現場で詰まる理由
セミナーで受講生から「権限エラーが出たら777にしていました」という話を聞くたびに、私はSE時代の自分を思い出します。問題が「動く」ことで解決してしまうから、根本の理解が進まないのです。
私が現場で見てきたパターンでは、権限設計を「理解している人」と「なんとなく触っている人」の差は、トラブル発生時の対応速度に如実に現れます。
・理解している人：権限エラーのメッセージから「どのファイルの、誰の権限が足りないか」を即座に特定できる
・なんとなくの人：「Permission denied が出た → chmod 777 → とりあえず動いた」で終わる
後者のアプローチは、セキュリティホールを作り続けることになります。
私がSE時代に犯したミスも、「焦りの中で-Rを使った」という意識の問題でした。手順を守る冷静さが、権限管理では特に大切です。
まとめ
| やりたいこと | コマンド・アプローチ |
|---|---|
| 変更前の権限状態を保存 | ls -lR ディレクトリ名 > /tmp/perm_backup_$(date +%Y%m%d_%H%M%S).txt |
| ディレクトリのみ権限変更 | find パス -type d -exec chmod 755 {} \; |
| ファイルのみ権限変更 | find パス -type f -exec chmod 644 {} \; |
| 変更後の確認 | ls -la ディレクトリ名 |
| 設定ファイルの安全な権限 | chmod 600 設定ファイル名 |
「chmod 777 で動いたからOK」という習慣を持ったまま現場に出ると、いつか本番障害の当事者になる可能性があります。
まずは、自分が管理しているサーバーのパーミッション設定を `ls -la` で眺めてみてください。
「なぜこの権限なのか」を説明できるか確認することが、権限設計の第一歩です。
権限ミスを防ぐ「型」を、現場の手順として身につけませんか？
パーミッション設定のミスは、知識不足より「焦り」と「手順の省略」が原因です。まずは体系的にまとめられた教材で、サーバー構築の全体像を掴んでください。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：SELinuxを「とりあえず切れ」と言われた日の話｜SE時代の先輩の言葉と20年後に気づいたことを現役講師が語る
- 前のページへ：Linuxサーバーを複数人で管理するときに決めておくべきルール｜属人化を防ぐ運用設計の考え方
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます