Ubuntuの「permission denied」エラーの原因と解決法

Ubuntu を使っていると必ず出くわすのが Permission denied というエラーです。「何もおかしいことはしていないのに…」と戸惑うことも多いですが、原因は9割がたファイルやディレクトリのアクセス権（パーミッション）の設定にあります。正しい確認コマンドと修正コマンドを覚えれば、ほとんどのケースは5分以内に解決できます。

本記事では ubuntu:24.04 の Docker 公式イメージを使い、実際にエラーを再現・修正した結果をもとに解説します。GNU coreutils 9.4（Ubuntu 24.04）・sudo 1.9.15p5 で動作確認済みです。

目次

1. 前提環境
2. permission denied の原因を理解する
3. ls -la でパーミッションを確認する
4. chmod でパーミッションを修正する
5. sudo で root 権限が必要な操作を実行する
6. chown でファイルの所有者を変更する
7. SSH 秘密鍵のパーミッション問題
8. Ubuntu 22.04 と 24.04 の違い
9. よくあるエラーと解決策
10. まとめ

前提環境

本記事の検証は以下の環境で実施しました。

• OS: Ubuntu 24.04 LTS（Docker 公式イメージ ubuntu:24.04）
• 比較対象: Ubuntu 22.04 LTS（Docker 公式イメージ ubuntu:22.04）
• GNU coreutils: 9.4-3ubuntu6.2（24.04）/ 8.32-4.1ubuntu1.3（22.04）
• sudo: 1.9.15p5-3ubuntu5.24.04.2
• OpenSSH: 9.6p1 Ubuntu-3ubuntu13.16
• 検証日: 2026-06-13

permission denied の原因を理解する

Linux では、すべてのファイル・ディレクトリに「誰が何をできるか」を表すパーミッション（アクセス権）が設定されています。Permission denied は、そのファイルに対して「あなたにはその操作を許可していません」とカーネルが拒否したサインです。

パーミッションは3種類の操作（読む・書く・実行する）と3種類の対象（所有者・グループ・その他）の組み合わせで決まります。

パーミッションの表記 -rw-r--r-- は次のように読みます。

• 先頭の -: ファイルの種類（-=通常ファイル、d=ディレクトリ、l=シンボリックリンク）
• rw-: 所有者（root）は読み・書きができる
• r--: グループ（root）は読みだけできる
• r--: その他のユーザーは読みだけできる

主な原因パターン

エラーが出たときは、次のいずれかであることがほとんどです。

• 自分が所有していないファイルに書き込もうとした（/etc/ 配下など root 所有のファイル）
• スクリプトに実行権（x）がついていない
• ディレクトリの実行権（x）がなくて中に入れない
• SSH 秘密鍵のパーミッションが広すぎて OpenSSH に拒否された

ls -la でパーミッションを確認する

エラーが出たら、まず ls -la でそのファイルのパーミッションを確認します。これが全ての起点です。

stat -c '%A %a' を使うと、記号表記（-rw-r--r--）と数字表記（644）を同時に確認できます。Ubuntu 24.04 / GNU coreutils 9.4 で実際に実行して確認しました。

chmod でパーミッションを修正する

パーミッションを変更するコマンドが chmod（change mode）です。自分が所有しているファイルであれば、root 権限なしで変更できます。

上の図は実際に ubuntu:24.04 コンテナで再現した結果です。chmod 444 で書き込み不可にしたファイルに echo で書き込もうとすると Permission denied が出ますが、chmod 644 で修正すれば書き込めるようになります。

手順1：数字表記でパーミッションを指定する

chmod の数字は「読み=4、書き=2、実行=1」を足した値で、「所有者・グループ・その他」の順に並べます。

stat コマンド（stat -c '%A %a'）で全モードを実際に確認しました。よく使う設定を覚えておけば十分です。

• chmod 755 script.sh: スクリプト・実行ファイルの標準設定（所有者は全操作、他人は読み・実行）
• chmod 644 config.txt: 設定ファイルの標準設定（所有者は読み書き、他人は読みのみ）
• chmod 600 ~/.ssh/id_rsa: SSH 秘密鍵（所有者のみ読み書き）

手順2：記号表記でパーミッションを変更する

数字表記が難しければ、+x（実行権を追加）のような記号表記も使えます。スクリプトを実行可能にするのによく使います。

ubuntu:24.04 コンテナで実際に確認しました。chmod +x を実行した後は -rw-r--r--（644）から -rwxr-xr-x（755）に変わり、スクリプトが実行できるようになります。

sudo で root 権限が必要な操作を実行する

/etc/・/usr/・/var/ 配下のファイルは root が所有していることが多く、一般ユーザーには書き込み権限がありません。そういった操作には sudo（superuser do）を使います。

sudo 1.9.15p5 が Ubuntu 24.04 の標準パッケージです。上の図は ubuntu:24.04 コンテナで apt install sudo を実際に実行し、インストールログとバージョンを確認した結果です。VPS の場合は最初から入っていることがほとんどです。

sudo の正しい使い方

ここだけは詰まりやすいポイントです。sudo echo "..." >> file はシェルのリダイレクト（>>）が先に評価されるため、sudo が効きません。ファイルに書き込むには sudo tee -a か sudo sh -c 'echo ... >> file' を使います。

sudo が使えない場合の対処

「is not in the sudoers file」と出た場合は、そのユーザーが sudo グループに入っていません。root 権限で usermod -aG sudo ユーザー名 を実行し、再ログインすれば使えるようになります。

chown でファイルの所有者を変更する

自分のユーザーが所有していないファイルは、たとえパーミッションを変えても自分では変えられません。そういった場合は chown（change owner）でファイルの所有者を変更します。

chown ユーザー名:グループ名 ファイル の書式で指定します。Web サーバー（nginx）のコンテンツディレクトリを自分のユーザーで管理したい場合などによく使います。

SSH 秘密鍵のパーミッション問題

VPS に SSH 接続しようとして Warning: UNPROTECTED PRIVATE KEY FILE! が出た場合、秘密鍵のパーミッションが広すぎることが原因です。

ubuntu:24.04 で実際に ssh-keygen を実行すると、秘密鍵は自動的に 600（-rw-------）で作成されることを確認しました。OpenSSH のバージョンは 9.6p1 です。

秘密鍵が 644（他の人も読める）になっていると、OpenSSH はセキュリティ上の理由でその鍵の使用を拒否します。

SSH 鍵ファイルのパーミッション設定は次の通りです。

• ~/.ssh/ ディレクトリ → 700（所有者のみアクセス可）
• ~/.ssh/id_rsa（秘密鍵） → 600（所有者のみ読み書き可）
• ~/.ssh/id_rsa.pub（公開鍵） → 644（他者も読める）
• ~/.ssh/authorized_keys → 600（所有者のみ読み書き可）

Ubuntu 22.04 と 24.04 の違い

ubuntu:22.04 と ubuntu:24.04 の Docker 公式イメージを使い、パーミッション関連の挙動を比較しました。主な違いは coreutils のバージョンです（22.04: 8.32 → 24.04: 9.4）。

デフォルト umask は両バージョンとも 0022 で変わりません。新しいファイルを作ると 644（umask で全員書き込み権が引かれた結果）、ディレクトリは 755 になります。

よくあるエラーと解決策

① bash: /path/to/file: Permission denied（書き込みエラー）

原因: ファイルへの書き込み権限がない。
確認: ls -la /path/to/file でパーミッションと所有者を確認。
解決:

• 自分のファイルなら: chmod u+w /path/to/file
• root 所有なら: sudo nano /path/to/file または echo "..." | sudo tee -a /path/to/file

② bash: ./script.sh: Permission denied（実行エラー）

原因: スクリプトに実行権（x）がない。
確認: ls -la script.sh で x がついているか確認。
解決: chmod +x script.sh

③ ls: cannot open directory ‘/path’: Permission denied（ディレクトリエラー）

原因: ディレクトリへのアクセス権（x）がない。
確認: ls -la /parent/ で該当ディレクトリのパーミッションを確認。
解決:

• 自分のディレクトリなら: chmod 755 /path/to/dir
• root 所有なら: sudo chmod 755 /path/to/dir

④ username is not in the sudoers file

原因: ユーザーが sudo グループに入っていない。
解決: root で usermod -aG sudo ユーザー名 を実行してから再ログイン。
VPS の初期設定では ubuntu ユーザーが最初から sudo グループに入っていることが多いです。

⑤ WARNING: UNPROTECTED PRIVATE KEY FILE!（SSH エラー）

原因: SSH 秘密鍵のパーミッションが 600 より広い（644 など）。
解決: chmod 600 ~/.ssh/id_rsa（または id_ed25519 など）

⑥ Operation not permitted（操作不可エラー）

「Permission denied」とは別物です。Operation not permitted はカーネルの制限や capabilities（特権機能）の問題で、一般的には Docker コンテナ内でシステムコールを使う操作や、 chown を他人のファイルに使おうとしたときなどに出ます。

まとめ

Ubuntu の Permission denied エラーの解決フローをまとめます。

1. まず ls -la でパーミッション（所有者・権限）を確認する
2. 自分のファイルの権限問題 → chmod で修正（書き込みは 644、実行は +x か 755）
3. root 所有のファイルへの操作 → sudo を使う（リダイレクトには sudo tee）
4. 所有者が違う → sudo chown 自分:グループ ファイル で変更
5. SSH 秘密鍵 → chmod 600 ~/.ssh/id_rsa で必ず修正

基本の操作は ls -la・chmod・sudo・chown の4つです。これを組み合わせれば、日常的な permission denied の大部分は解決できます。

VPS を借りて本番サーバーを運用しはじめると、パーミッション問題はさらに頻繁に出てきます。Nginx・MySQL・アプリの実行ユーザーが絡み合う場面で特に詰まりやすいので、まずはこの記事の内容を手元で試しておくことをおすすめします。

VPS 選びから始めたい方は、実測ベンチマークをもとに比較した記事も参考にしてみてください。