【Linux】Permission deniedの原因と解決法！chmod 777を使わない対処手順

こんにちは！大手SIerでインフラエンジニアおよびサービスマネージャーをしている「もっち」です。

Linuxを触り始めた若手エンジニアのみなさん、ターミナルで作業していて「Permission denied（許可がありません）」という赤字のエラーが表示され、一瞬ピタッと手が止まってしまった経験はありませんか？

「権限がない…？ じゃあとりあえず chmod 777 にしちゃえば動くかな？」

……ちょっと待ってください！ その判断、実は現場ではめちゃくちゃ危険な罠なんです。

この記事では、現場で実際に起きた「chmod 777の恐怖体験談」を交えながら、Permission deniedが発生する本当の原因と、プロが実践する安全な切り分け・復旧手順を分かりやすく解説します！

この記事でわかること

• 「とりあえず chmod 777」が現場で絶対NGな本当の理由
• Permission deniedが発生する4つの根本原因とチェックリスト
• エラーが出たときにプロが実践する段階的な解決ステップ
• SSH鍵・Webサーバー・スクリプトなど、よくある症例別の即効解決レシピ

【体験談】Permission denied対策で「とりあえず chmod 777」が絶対NGな理由

まずは、私が現場で実際に目撃した、今思い出しても背筋が凍る「失敗談」をお話ししますね。

あるプロジェクトで、権限エラーに悩まされていた開発担当者がいました。締め切りも迫っており、焦っていた彼はこう考えたのです。

「一番権限の緩い設定にしておけば、エラーなんて出なくなるだろう！」

そうして、対象の設定ファイルの権限をとりあえず「777（全員何でも読み・書き・実行ができる状態）」に変更してしまいました。

これが地獄の始まりでした。なんと、その変更したファイルは、Linuxセキュリティの要である「PAM（Pluggable Authentication Modules）の設定ファイル」だったのです。

Linuxシステムは非常に優秀で、かつ頑固です。「こんな誰でも書き換えられる状態のセキュリティファイルは、すでに改ざんされている可能性がある。信用できない！」と自動的に判断しました。

その瞬間、何が起きたか分かりますか？ そのサーバーへのすべてのログインが一切拒否される状態（全締め出し）に陥ってしまったのです。

権限を緩くすれば解決するというのは、大きな間違いです。セキュリティが高い重要ファイルほど、「権限が緩すぎるとOSから拒絶される」という仕組みになっています。

権限設定の変更は、当てずっぽうで行うのではなく、正しく原因を特定して慎重に行わなければいけません。

特殊パーミッション（SUID/SGID/Sticky bit）の基本的な仕組みや設定方法については、こちらの記事で詳しく解説しています。

LinuxでPermission deniedが起きる4つの原因とチェックリスト

「Permission denied」が出たときは、闇雲にコマンドを打つのではなく、以下の4つのチェックリストを上から順に確認していくのがプロの切り分け術です。

• Check 1: ファイル自体のパーミッション（rwx）と所有者
• Check 2: 親ディレクトリの実行権限（x）の罠
• Check 3: 特殊属性（i属性 / immutable）によるロック
• Check 4: SELinux / AppArmor によるアクセス拒絶

Check 1: ファイル自体のパーミッション（rwx）と所有者

まずは基本中の基本です。ls -l コマンドで対象ファイルの詳細を確認しましょう。

# ファイルの権限と所有者を確認
$ ls -l /var/www/html/index.html
-rw-r--r-- 1 root root 120 10月 10 10:00 /var/www/html/index.html

自分が操作しようとしているユーザー（あるいはWebサーバーなどの実行ユーザー）に、読み取り（r）・書き込み（w）・実行（x）の必要な権限が割り当てられているか確認します。

Check 2: 親ディレクトリの実行権限（x）の罠

実務で非常に多いのがこのパターンです。「ファイルのパーミッションは 755 で問題ないのに、なぜかアクセスできない…」という場合、親ディレクトリの権限が原因かもしれません。

Linuxでは、ディレクトリの中に「入る（辿る）」ために実行権限（x）が必要です。

例えば、/var/www/html/index.html にアクセスしたい場合、/var /www /html のすべてのディレクトリに自分に対する x 権限がないと、ファイルまで辿り着けずに「Permission denied」になります。

Check 3: 特殊属性（i属性 / immutable）によるロック

ファイル権限が 777 かつ root ユーザーなのに「変更できません」と言われる怪現象があります。この場合、ファイルに immutable（変更不可）属性が付与されている可能性があります。

lsattr コマンドで確認してみましょう。

# 特殊属性の確認
$ lsattr critical.conf
----i---------e---- critical.conf  # 「i」がついているとrootでも変更不可！

i（immutable）がついているファイルは、chattr -i コマンドで属性を解除しない限り、削除や編集ができません。

Check 4: SELinux / AppArmor によるアクセス拒絶

OS標準のパーミッション（rwx）が正しく設定されているのに拒絶される場合、裏で SELinux などのアクセス制御機能が働いているケースがあります。

拒絶ログ（auditログ）に記録されていないか確認してみましょう。

# SELinuxの拒絶ログを確認
$ sudo grep "denied" /var/log/audit/audit.log

【段階別】Permission deniedが出たときの安全な解決手順

原因の切り分けポイントが分かったところで、実際に現場で使えるトラブルシューティングの流れをマスターしておきましょう。

1. ls -ld で対象パス全体の権限構造を可視化する
2. 必要最小限の権限付与（chmod / chown の使い分け）
3. sudo が必要な操作の見極めと安全な実行

Step 1: ls -ld で対象パス全体の権限構造を可視化する

パス全体の権限を一発で確認したいときは、ls -ld にパスを渡して確認するのが手っ取り早いです。

# ディレクトリ自体の権限を確認
$ ls -ld /var/www/html
drwxr-xr-x 2 root root 4096 10月 10 10:00 /var/www/html

Step 2: 必要最小限の権限付与（chmod / chown の使い分け）

エラーを解消するとき、権限を全員に開け放つのではなく、「所有者を正しく変更する（chown）」のか「不足している権限だけをピンポイントで足す（chmod）」のかを考えます。

# 所有者が間違っている場合：所有者を自分に変更する
$ sudo chown myuser:myuser /path/to/file

# 実行権限だけが足りない場合：所有者だけに実行権限を追加する
$ chmod u+x script.sh

Step 3: sudo が必要な操作の見極めと安全な実行

システム全体に影響する設定変更や、他のユーザーが所有するファイルの操作には sudo が必要です。ただし、何でもかんでも sudo で実行する癖をつけるのは厳禁です。

「なぜ自分の一般ユーザー権限ではダメで、管理者権限が必要なのか？」を意識して実行するよう心がけましょう。

【よくある症例別】Permission deniedの解決レシピ

ここからは、実務で本当によく遭遇する「Permission denied」の具体的なパターンと、安全な解決レシピをご紹介します！

パターンA: SSH秘密鍵のエラー（Permissions 0755 are too open）

SSHでサーバーに接続しようとした際、以下のようなエラーが出ることがあります。

Permissions 0755 for '/home/user/.ssh/id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
Permission denied (publickey).

これは正に「権限がゆるすぎるからダメ！」とSSHクライアントに拒絶されている状態です。

• 正しい解決法:秘密鍵の権限は、自分以外アクセスできない 600（-rw——-） に変更します。

# 秘密鍵のパーミッションを自分のみアクセス可能に変更
$ chmod 600 ~/.ssh/id_rsa

パターンB: Webサーバー（Nginx/Apache）の403 Forbidden

Webページを表示しようとすると 403 Forbidden になり、ログに「Permission denied」と吐かれているパターンです。

• 原因:Webサーバーの実行ユーザー（nginx や www-data など）が、公開ディレクトリやファイルに対する読み取り権限を持っていない。
• 正しい解決法:ディレクトリに 755、ファイルに 644 を設定し、親ディレクトリまで辿れるようにします。

# ディレクトリの権限を755に一括変更
$ find /var/www/html -type d -exec chmod 755 {} \;

# ファイルの権限を644に一括変更
$ find /var/www/html -type f -exec chmod 644 {} \;

パターンC: シェルスクリプト実行時の「許可がありません」

自分で作った deploy.sh を実行しようとして ./deploy.sh と打ったら拒否されるパターンです。

• 原因:新規作成したファイルには、デフォルトで実行権限（x）が付与されていないため。
• 正しい解決法:chmod u+x で所有者に実行権限を付与します。

# 所有者に実行権限（x）を追加
$ chmod u+x deploy.sh

まとめ：エラーはシステムが正常に守られている証拠

「Permission denied」というエラー画面を見ると、最初は「うわ、間違えたかな…」と焦ってしまうかもしれません。

しかし、このエラーは「Linuxシステムが不正な操作やセキュリティ事故から、あなたとシステムをしっかり守ってくれている証拠」なのです。

トラブルが起きたときは、焦って chmod 777 に頼るのではなく、今回ご紹介したチェックリストを思い出して「どこで誰の権限が止まっているのかな？」と優しく紐解いてみてくださいね。

最小限の正しい権限でスムーズにエラーを解決できるようになれば、あなたも立派なインフラエンジニアの仲間入りです！応援しています！