Linux権限管理【実践編】：Permission denied を"根本から"解決する
「Permission denied」—このエラーを見て、すぐに sudo を打っていませんか？それは根本解決ではなく、問題の先送りです。この記事では、実務で頻出するケースを通じて「正しい切り分け」と「恒久対応」の型を身につけます。
目次
1. 先に結論（実践での判断の型）
Permission denied を見たら、この3ステップで切り分ける。
- 何をしようとしたかを明確にする（読み取り / 書き込み / 実行）
ls -lで対象の権限と所有者を確認- 自分が owner / group / other のどれかを判断し、最小限の修正を選ぶ
「とりあえず sudo」「とりあえず chmod 777」は禁句。原因を特定してから最小限の修正を行うのが鉄則です。
実践での判断フロー
# Step 1: エラーが出た操作を再現 $ echo "log" >> /var/log/app.log Permission denied # Step 2: 対象を確認 $ ls -l /var/log/app.log -rw-r----- 1 app-user app-group 1234 /var/log/app.log # Step 3: 自分が誰かを確認 $ id uid=1000(developer) gid=1000(developer) groups=1000(developer) # 結論: グループに入れば解決 $ sudo usermod -a -G app-group developer
2. ケース1：ログファイルに書き込めない
症状
$ echo "test log" >> /var/log/myapp.log
bash: /var/log/myapp.log: Permission denied
診断手順
# ファイルの権限を確認 $ ls -l /var/log/myapp.log -rw-r----- 1 root adm 2048 /var/log/myapp.log # 自分の所属グループを確認 $ groups developer
判断
- ファイルは
root:adm所有 - グループ
admには書き込み権限がない（r--） - 自分は
admにも入っていない
解決策（状況に応じて選択）
A: アプリケーションの設定を変える（推奨）
ログの出力先を、自分に権限のある場所に変更する。
# アプリの設定ファイルでログ出力先を変更 LOG_PATH=/home/developer/logs/myapp.log
B: グループに追加される
# admグループに追加（要再ログイン） $ sudo usermod -a -G adm developer
C: 所有者を変更する（最終手段）
# 所有者を変更 $ sudo chown developer:developer /var/log/myapp.log
ベストプラクティス: アプリケーションログは /var/log/ 直下より、専用ディレクトリ（例: /var/log/myapp/）を作成し、適切な所有者で管理する方が安全。
3. ケース2：ディレクトリ配下にファイルを作れない
症状
$ touch /var/www/html/newfile.html
touch: cannot touch '/var/www/html/newfile.html': Permission denied
診断手順（ここが重要）
# ファイルは存在しない → ディレクトリの権限が問題 $ ls -ld /var/www/html/ drwxr-xr-x 2 www-data www-data 4096 /var/www/html/
判断
- ディレクトリは
www-data:www-data所有 - other には
r-x（読み取りと実行のみ、書き込み不可） - ファイル作成にはディレクトリへの書き込み権限（w）が必要
解決策（状況に応じて選択）
A: www-dataグループに追加（推奨）
# グループに追加 $ sudo usermod -a -G www-data developer # グループに書き込み権限を付与 $ sudo chmod g+w /var/www/html/
B: 開発用ディレクトリを別に作る
# 開発用ディレクトリを自分の所有で作成 $ sudo mkdir /var/www/html/dev $ sudo chown developer:developer /var/www/html/dev
絶対にやってはいけないこと: chmod 777 /var/www/html/。セキュリティリスクが跳ね上がります。
▶ 事故例：chmod -R の暴発
実際に起きた事故
# 本番サーバーでうっかり実行 $ sudo chmod -R 777 /var/www/
何が起きたか
- 全ファイルが誰でも書き込み可能に
- 悪意あるスクリプトが設置された
- サーバー乗っ取りの踏み台に
教訓
-Rを使う前に、影響範囲を必ず確認- まず単一ファイル/ディレクトリで試す
- 本番サーバーでは特に慎重に
4. ケース3：スクリプトが実行できない
症状
$ ./deploy.sh
bash: ./deploy.sh: Permission denied
診断手順
$ ls -l deploy.sh -rw-r--r-- 1 developer developer 512 deploy.sh
判断
- 所有者は自分
- 実行権限（x）がない（
rw-r--r--）
解決策
# 所有者に実行権限を付与 $ chmod u+x deploy.sh # 確認 $ ls -l deploy.sh -rwxr--r-- 1 developer developer 512 deploy.sh # 実行 $ ./deploy.sh
代替手段：bash で直接実行
実行権限がなくても、インタプリタを明示すれば実行可能です。
$ bash deploy.sh
ただし、これは一時的な回避策。本番運用では適切な権限設定が推奨されます。
5. sudo を使う前に考える
sudo は強力なツールですが、「何でも解決できる魔法」ではありません。
sudo を使うべきとき
- システム設定の変更（
/etc/配下など） - パッケージのインストール
- サービスの起動・停止
sudo を使うべきでないとき
- 自分の作業ファイルの編集
- 開発中のアプリケーションの実行
- 「とりあえず動かしたい」という理由だけ
▶ 事故例：root 所有ファイルの増殖
よくあるパターン
# 開発中にPermission denied $ npm install Permission denied # とりあえずsudo $ sudo npm install # node_modules が root 所有に... $ ls -ld node_modules/ drwxr-xr-x 500 root root 20480 node_modules/ # 次から普通に npm install できない！
なぜ起きるか
sudoで実行すると、作成されるファイルはroot所有になる- 一度 root 所有になると、通常ユーザーでは上書きできない
- また
sudoを使う → root 所有が増える... の悪循環
修復方法
# 所有者を自分に戻す $ sudo chown -R $(whoami) node_modules/ # 以後は sudo なしで実行
予防策
- 開発作業は原則
sudoなしで行う Permission deniedが出たら原因を調べる- npm は
--prefixでローカルインストール先を指定できる
▶ 代替案：そもそも権限トラブルを起こさない設計
1. ホームディレクトリで作業する
/home/user/projects/ 配下なら権限問題は起きにくい。
2. 開発用グループを活用する
# 開発チーム用グループ $ sudo groupadd devteam $ sudo usermod -a -G devteam alice $ sudo usermod -a -G devteam bob # プロジェクトディレクトリをグループで管理 $ sudo chgrp devteam /var/www/project $ sudo chmod g+w /var/www/project $ sudo chmod g+s /var/www/project # 新規ファイルも自動的にdevteam所有
3. 環境変数でパスを変える
ログ、キャッシュ、一時ファイルの出力先を、権限のある場所に設定する。
6. 実践課題（10分）
以下のシナリオを順番に試して、「診断 → 判断 → 解決」の流れを体験しましょう。
課題1: 書き込み権限のないファイルへの追記
$ mkdir perm-practice && cd perm-practice $ touch readonly.txt $ chmod u-w readonly.txt $ echo "test" >> readonly.txt
確認ポイント
Permission deniedが出たか？ls -lで原因を特定できるか？- どのコマンドで解決するか判断できるか？
課題2: ディレクトリへのファイル作成
$ mkdir restricted $ chmod u-w restricted $ touch restricted/newfile.txt
確認ポイント
- エラーの原因は「ファイル」ではなく「ディレクトリ」だと理解できるか？
ls -ldでディレクトリの権限を確認したか？
課題3: スクリプトの実行
$ echo '#!/bin/bash' > test.sh $ echo 'echo "Hello!"' >> test.sh $ ./test.sh
確認ポイント
- 実行権限がないことを特定できるか？
chmod u+xで解決できるか？bash test.shという代替手段を知っているか？
解答の考え方
- 課題1:
chmod u+w readonly.txt - 課題2:
chmod u+w restricted（ディレクトリの権限） - 課題3:
chmod u+x test.shまたはbash test.sh
7. 次に読む
📋 検証環境
本記事のコマンドは Ubuntu 24.04 LTS / bash 5.2 で動作確認済みです。
🔐 権限管理シリーズ全体
🎉 実践力を身につけよう
Permission denied を見たら「sudo」ではなく「なぜ？」と考える習慣が、本当の実践力です。Penguin Gym Linux の仮想環境で、安全に権限トラブルを体験してみましょう。