「permission denied」の原因と対処法｜権限エラーの基本理解
permission denied は、その操作を実行する権限が今のユーザーにないときに出る代表的なエラーです。ファイルを開けない、スクリプトを実行できない、保存できない、削除できない。こうした場面の多くは「コマンドの書き方」ではなく、権限の持ち主と許可設定を見れば切り分けられます。
とくに実務では、LinuxやmacOSのターミナル、サーバー上のデプロイ作業、共有フォルダ、Windowsの管理者権限まわりで頻出です。先に結論を言うと、確認すべきポイントは次の4つに絞れます。
ここがポイント:
permission deniedは「対象がない」のではなく、「対象はあるが、触る許可がない」状態をまず疑うエラーです。
- 誰の権限で実行しているか
- 対象ファイルやフォルダの所有者が誰か
- 読み取り・書き込み・実行のどの許可が不足しているか
- OSや環境が別の制限をかけていないか
permission denied で何が分かるのか
まず、このエラーは原因が1つではありません。ただし見方はシンプルです。
- ファイルを読むときに出る: 読み取り権限不足
- ファイルを書き換えるときに出る: 書き込み権限不足
- スクリプトやバイナリを動かすときに出る: 実行権限不足
- システム領域を変更するときに出る: 管理者権限不足
- Webアクセスで出る
403 Forbidden: サーバー側でアクセス拒否
同じ文言でも、何をしようとして失敗したかで対処は変わります。最初に「読む」「書く」「実行する」のどれで止まったかを切り分けると早いです。
よくある発生場面
開発や日常運用で多いのは次のケースです。
1. スクリプトを実行したとき
./deploy.sh
# zsh: permission denied: ./deploy.sh
この場合は、ファイル自体はあるのに実行権限が付いていないことがよくあります。
2. 保存や削除をしたとき
rm /var/www/app.log
# rm: cannot remove 'app.log': Permission denied
自分が所有していないファイル、または書き込み権限のないディレクトリを操作している可能性があります。
3. アプリからファイル出力したとき
with open('/var/log/myapp/output.txt', 'w') as f:
f.write('hello')
# PermissionError: [Errno 13] Permission denied
Pythonなどのプログラムでは、OSの権限制御が例外として返ります。コードが間違っているとは限らず、保存先の権限設計が問題のことがあります。
4. Windowsで管理者権限が必要な操作をしたとき
インストール先が Program Files、設定変更対象がシステム領域、あるいは共有フォルダのアクセス許可が不足していると失敗します。見た目は同じでも、UNIX系の chmod とは確認箇所が違います。
まず確認したい基本手順
闇雲に sudo を付ける前に、次の順で確認すると安全です。
- 今のユーザーを確認する
- 対象ファイルの所有者と権限を確認する
- 実行したい操作に必要な権限を特定する
- 必要最小限だけ権限を修正する
Linux / macOS での確認例
whoami
ls -l script.sh
出力例:
masa
-rw-r--r-- 1 root staff 248 Apr 22 10:00 script.sh
この例では、script.sh は所有者が root で、実行権限 x がありません。masa ユーザーが ./script.sh を実行すると失敗しやすい状態です。
見るべき点はここです。
- 先頭の
-rw-r--r--: 読み書き実行の許可 - 所有者:
root - 所有グループ:
staff
原因別の対処法
ここが実際にいちばん使う部分です。エラーの種類ごとに分けて見ます。
実行権限がない場合
シェルスクリプトや実行ファイルで典型的です。
chmod +x script.sh
./script.sh
入力例:
ls -l script.sh
# -rw-r--r-- 1 masa staff 248 Apr 22 10:00 script.sh
実行後の出力例:
ls -l script.sh
# -rwxr-xr-x 1 masa staff 248 Apr 22 10:00 script.sh
これで所有者に実行権限が付きます。チーム開発や本番環境では、chmod 777 のように全員へ無制限に開く方法は避けるべきです。
NG例
chmod 777 script.sh
この指定は「誰でも読み書き実行できる」状態を作ります。検証用の一時対応でも、共有環境では事故の原因になります。
改善例
chmod 755 script.sh
または、所有者だけ実行できればよいなら次でも十分です。
chmod u+x script.sh
所有者が違う場合
自分で作ったつもりのファイルでも、sudo 実行や別ユーザーの処理で所有者が変わることがあります。
ls -l data.csv
# -rw-r--r-- 1 root staff 1024 Apr 22 10:30 data.csv
このまま一般ユーザーで編集しようとすると失敗します。
対処例:
sudo chown masa:staff data.csv
ディレクトリごと直すなら再帰オプションを使います。
sudo chown -R masa:staff project_dir
自分が使う作業ディレクトリを root 所有のままにしないことが、同じエラーを繰り返さない近道です。
書き込み権限がない場合
ファイル単体ではなく、親ディレクトリの権限が原因のこともあります。
echo "test" > output.txt
# permission denied
このとき確認したいのは次の2点です。
output.txt自体の権限output.txtを置くディレクトリの書き込み権限
確認例:
ls -ld .
ls -l output.txt
ディレクトリに書き込みできないなら、ファイル名が合っていても保存はできません。ログ出力先やアップロード先でよく起きるパターンです。
sudo が必要な場合
システム設定、パッケージ管理、/usr/local や /var などの保護領域では、通常ユーザーのままでは通りません。
sudo mkdir /opt/myapp
ただし、sudo は万能な解決策ではありません。安易に使うと、その後に作られたファイルが root 所有になり、次回は逆に一般ユーザーで扱えなくなります。
使いどころは限定すべきです。
- OS設定の変更
- システムディレクトリへの配置
- パッケージのインストール
逆に、手元のプロジェクト配下のファイル編集やビルドで毎回 sudo が必要なら、権限設計が崩れている可能性が高いです。
Windows での確認ポイント
Windowsでは、UNIX系の rwx 表記ではなく、NTFS のアクセス許可や管理者権限が関係します。
よくある確認ポイントは次の通りです。
- 管理者として実行が必要か
- 対象フォルダのセキュリティ設定で書き込みが許可されているか
- 共有フォルダなら共有権限とNTFS権限の両方が通っているか
- セキュリティソフトや組織ポリシーでブロックされていないか
コマンドで確認したいときは icacls が使えます。
icacls C:\work\report.txt
GUIで確認するなら、ファイルやフォルダのプロパティから「セキュリティ」タブを見るのが早いです。
プログラム実行時の PermissionError 例
開発では、CLIだけでなくコード上でも同じ問題が起きます。Pythonなら次のような例外です。
from pathlib import Path
path = Path('/root/result.txt')
path.write_text('hello', encoding='utf-8')
出力例:
PermissionError: [Errno 13] Permission denied: '/root/result.txt'
このケースでは、コード修正より先に保存先を見直します。
改善例:
from pathlib import Path
path = Path.home() / 'result.txt'
path.write_text('hello', encoding='utf-8')
実務では次の考え方が有効です。
- システム領域ではなく、アプリ専用の書き込み可能ディレクトリを使う
- ログや一時ファイルの出力先を設定値で切り替えられるようにする
- 権限が必要な処理と通常処理を分ける
permission denied と似たエラーとの違い
見分けがつくと調査時間がかなり減ります。
No such file or directory- ファイルやパス自体が存在しない
command not found- コマンドが見つからない
permission denied- 対象は見つかっているが、実行やアクセスの許可がない
- HTTP
403 Forbidden - Webサーバー側がアクセスを拒否している
同じ「できない」でも、存在しないのか、見つからないのか、許可されていないのかで対処はまったく違います。
実務で起きやすい失敗
初心者だけでなく、運用中の現場でもよくあるミスです。
sudo で作ったファイルをそのまま使う
一度 sudo で生成したログやキャッシュが root 所有になり、以後の通常実行で失敗します。
ディレクトリ権限を見ずにファイルだけ直す
ファイルに書き込み権限を付けても、親ディレクトリが書き込み不可なら保存できません。
全開放で一時しのぎする
chmod 777 は切り分けには見えても、本番や共有端末ではリスクが大きすぎます。
実行権限だけ見て shebang を見ない
スクリプトは chmod +x しても、先頭の #!/bin/bash などが不適切なら別の実行エラーになることがあります。権限だけで終わらせないのが重要です。
迷ったときのチェックリスト
短時間で切り分けるなら、この順番で十分です。
whoamiで実行ユーザーを確認したかls -lやls -ldで対象と親ディレクトリの権限を見たか- 所有者が
rootや別ユーザーになっていないか - 必要なのが「読み取り」「書き込み」「実行」のどれか切り分けたか
sudoを使うべき操作か、それとも所有者や保存先を直すべきか判断したか- Windowsなら管理者権限とアクセス許可の両方を確認したか
関連ツールと代替の考え方
権限エラーそのものを避けたいなら、運用側の設計も効きます。
- Linux / macOS:
chmod,chown,sudo,ls -l - Windows:
icacls, エクスプローラーのセキュリティ設定 - 開発時の代替策: 書き込み先をホームディレクトリ配下や作業ディレクトリ配下に寄せる
- チーム運用: 実行ユーザーと所有者が食い違わないデプロイ手順にする
とくにCI/CDやバッチ処理では、誰の権限でファイルが作られるかを最初に固定するだけで、後から出る permission denied をかなり減らせます。
まとめ
permission denied の対処は、権限を広く開けることではなく、誰がどこに何をしようとして拒否されたかを特定することです。読む、書く、実行するのどこで止まったかを見れば、確認箇所はかなり絞れます。
最後に、再発防止として見るべき点を並べます。
- 作業ディレクトリを不用意に
root所有へしない sudoは必要な場面だけに限定する- 書き込み先と実行ユーザーを設計段階で決める
- 一時対応で
777を使わない
次に同じエラーが出たら、まず所有者と権限表示を確認してください。そこを見ずに対処すると、たいてい遠回りになります。