UNIX系OSの基本的な権限管理は、「誰が、何に、どんな操作をできるか」をr・w・xで制御する仕組みです。Linuxでは所有者・グループ・その他の3区分を理解すると、chmod 755やPermission deniedの意味まで一本につながります。
特にLinuxで権限エラーを調べるなら、いきなりchmod 777へ変更するのではなく、実行ユーザー→所有者・グループ→必要なrwx→親ディレクトリの順に確認するのが近道です。
UNIX系OSの権限管理とは？Linuxでは「誰が何をできるか」を決める
UNIX系OSの伝統的なファイル権限は、ファイルやディレクトリに対して、どのユーザーがどこまでアクセスできるのかを制御する仕組みです。
この記事ではPOSIXで定められている基本的な考え方を土台にしながら、コマンド例については主にLinuxのGNU Coreutilsやutil-linuxが利用できる環境を想定して解説します。
基本となるのは、次の3種類の対象です。
- Owner（所有者）：そのファイルを所有するユーザー
- Group（グループ）：ファイルに設定されたグループに対応するユーザー
- Others（その他）：上の2つに該当しないユーザー
さらに、それぞれにr・w・xという権限を組み合わせます。
- r（Read）：読み取り
- w（Write）：書き込み
- x（Execute/Search）：ファイルなら実行、ディレクトリなら検索・通過
僕はこの仕組みを、会社の「入館証」に置き換えると分かりやすいと感じています。
同じ建物でも、管理担当者はサーバールームへ入れる、一般社員は執務室まで、来訪者は受付周辺だけ、といったように立場によって許可される範囲が変わりますよね。
ファイル権限も似ています。
ファイルそのものに「読める・書ける」という絶対的な能力があるのではなく、アクセスするユーザーとの組み合わせで許可される操作が決まると考えるのがポイントです。
なぜこの記事を書こうと思ったのか
現役SEとしてシステムを扱っていると、Permission deniedに遭遇したとき、「chmod 755を試してみる」「sudoなら動くか確認する」とコマンドから入ってしまいたくなる場面があります。
ですが、実務で切り分けるときに僕が特に意識しているのは、数字を覚えることより「実際には誰として処理が動いているのか」を確認することです。
Webアプリなどでは、自分がログインしているユーザーと、Webサーバーやアプリケーションを実行しているユーザーが同じとは限りません。
ここを取り違えると、「自分は書き込めるのにアプリからは書けない」という、一見すると不思議な現象が起きます。
さらに見落としやすいのが親ディレクトリのxです。
対象ファイルの権限だけを眺めて「問題ないはずなのに……」と悩むより、主体・対象・操作・そこまでの経路に分解したほうが、原因をずっと論理的に追えます。
その考え方を、単なるchmodの数字一覧ではなく、一つのトラブルを解決する流れまで含めて整理したいと思ったのが、この記事を書いた理由です。
なお、「UNIX系OS」という言葉はかなり広い範囲を指します。
Linuxや各種BSDなどには共通する考え方が多い一方、コマンドのオプションやACL、追加のセキュリティ機構などには実装差があります。この記事では共通する伝統的なrwxを中心に、実例はLinux寄りとして読み進めてください。
【出典：The Open Group 『chmod』 https://pubs.opengroup.org/】
【出典：GNU Project 『GNU Coreutils Manual – File permissions』 https://www.gnu.org/software/coreutils/manual/coreutils.html】
UNIX系OSのr・w・xとは？ファイルとディレクトリでは意味が違う
r・w・xは権限管理の基本ですが、ここで最初につまずきやすいポイントがあります。
通常ファイルとディレクトリでは、同じr・w・xでも操作上の意味が異なります。
| 権限 | 通常ファイル | ディレクトリ |
|---|---|---|
| r | 内容を読み取る | エントリ名の一覧を読み取る |
| w | 内容を変更する | エントリの作成・削除などに関係する |
| x | ファイルを実行する | 内部のエントリを検索・参照するために通過する |
通常ファイルなら比較的直感的ですよね。
テキストファイルにrがあれば内容を読める、wがあれば内容を書き換えられる、実行可能なプログラムやスクリプトではxが実行に関係する、と考えられます。
一方、ディレクトリは少し違います。
ディレクトリのxは「実行」より「通過」と考える
初心者の方に特に意識してほしいのが、ディレクトリのxです。
ディレクトリ自体をプログラムのように「実行する」というより、そのディレクトリを経路として通り、中の名前を検索して対象へ到達するための権限と捉えると理解しやすくなります。
たとえば、次のファイルへアクセスするとします。
/srv/app/data/example.txt
このときexample.txtだけに注目するのは不十分です。
アクセスするには、状況に応じて/srv、/srv/app、/srv/app/dataという経路をたどる必要があります。
途中のディレクトリを検索・通過できなければ、最終地点であるexample.txtの権限が一見問題なさそうでもアクセスに失敗する可能性があります。
これはPermission deniedを調査するときにかなり重要です。
ファイルにwがなくても削除できることがあるのはなぜ？
もう一つ、最初は直感に反して見えるのがファイルの削除です。
通常ファイルのwは、そのファイルの内容を書き換える権限です。
ところがファイルの削除は、単純にファイル内容を書き換えているわけではありません。親ディレクトリから、そのファイル名に対応するエントリを取り除く操作として考える必要があります。
そのため、条件がそろえばファイル自体にwがなくても、親ディレクトリ側の権限によって削除できる場合があります。
逆に「対象ファイルには必要な権限があるのに開けない」という場合には、親ディレクトリを含めて調べる必要があります。
僕が権限トラブルを見るときも、ファイルだけで判断せず、パスを一本の道として見ることを意識しています。
目的地のドアに鍵が掛かっていなくても、そこへ向かう途中のゲートを通れなければ到達できない、というイメージです。
【出典：GNU Project 『GNU Coreutils Manual – File permissions』 https://www.gnu.org/software/coreutils/manual/coreutils.html】
【出典：Linux man-pages 『chmod(1) – change file mode bits』 https://man7.org/linux/man-pages/man1/chmod.1.html】
ls -lとchmod 755・644はどう読む？4・2・1から理解しよう
Linuxでファイルやディレクトリの基本的な権限を確認するとき、まず覚えておきたいのがls -lです。
たとえば、次のような結果が表示されたとしましょう。
-rw-r–r– 1 user group 1024 Jun 23 10:00 example.txt
注目したいのは先頭の部分です。
-rw-r–r–
初めて見ると暗号のようですが、次のように分けると一気に分かりやすくなります。
- | rw- | r– | r–
意味は基本的に、
ファイル種別｜所有者｜グループ｜その他
です。
先頭の-は通常ファイルを表します。ディレクトリなら、この部分はdになります。
続くrw-は所有者の権限です。
rとwがあるため、この例では所有者に読み取りと書き込みが許可されています。xは付いていません。
その次のr–はグループ、最後のr–はその他です。
つまりこの例では、所有者は読み書き可能、グループとその他は読み取りのみという基本モードになっています。
ただし、ここで「rw-r–r–だから分かった！」と終わらないのが大切です。
同じ行にはuserとgroupも表示されています。
自分が所有者userなのか、groupに対応するユーザーなのか、それともOthersとして評価されるのかによって、利用できる権限が変わります。
chmodの755や644は何を表している？
chmodはファイルのモードビットを変更するための代表的なコマンドです。
GNU版chmodでは数値形式やシンボリック形式を利用できます。
よく見かける755や644は、次の3つの数字を組み合わせたものです。
- 4＝r（読み取り）
- 2＝w（書き込み）
- 1＝x（実行・検索）
たとえば、rとwを与えるなら、
4 + 2 = 6
rとxなら、
4 + 1 = 5
r・w・xのすべてなら、
4 + 2 + 1 = 7
です。
これを所有者・グループ・その他の順番に3桁で表します。
chmod 755 example
なら、
7 = rwx
5 = r-x
5 = r-x
なので、基本モードは、
rwxr-xr-x
となります。
一方、
chmod 644 example.txt
なら、
6 = rw-
4 = r–
4 = r–
なので、
rw-r–r–
です。
つまり、755や644は謎の暗証番号ではなく、r・w・xを数値で表した結果なんですね。
シンボリック形式なら変更の意図が見えやすい
chmodには数字を使わない指定方法もあります。
たとえば、
chmod u+x example
なら、所有者にxを追加します。
chmod go-w example
なら、グループとその他からwを取り除きます。
文字の意味は、
- u＝所有者
- g＝グループ
- o＝その他
- a＝すべて
です。
数値形式はモード全体をまとめて指定するときに分かりやすい一方、シンボリック形式は「現在の状態から何を変えるのか」という意図を表現しやすいのが特徴です。
なお、実際のファイルモードには基本のrwxだけでなく、setuid・setgid・sticky bitといった特殊なビットもあります。
そのため厳密には「UNIX系OSの権限＝3桁の755」ではありません。
まずrwxと3桁の基本モードを理解してから、必要に応じて特殊権限へ進むと整理しやすいですよ！
【出典：GNU Project 『GNU Coreutils Manual – Numeric Modes』 https://www.gnu.org/software/coreutils/manual/coreutils.html】
【出典：Linux man-pages 『chmod(1) – change file mode bits』 https://man7.org/linux/man-pages/man1/chmod.1.html】
Permission deniedはどう調べる？id・stat・nameiを使った実例
ここからは「実際にPermission deniedが発生した」という想定で、原因を一本の流れで追ってみましょう。
Linux環境を想定した架空の例ですが、調査の順番そのものがポイントです。
Webアプリからuploadsへ書き込めないケース
Webアプリケーションが次のディレクトリへファイルを保存しようとしているとします。
/srv/app/uploads
ところが保存時にPermission deniedとなりました。
ここでいきなり、
chmod 777 /srv/app/uploads
とはしません。
僕なら、まず次の5段階で調べます。
1. 実際に処理しているユーザーを確認する
2. 対象の所有者・グループとモードを確認する
3. 必要な操作が何なのかを整理する
4. 親ディレクトリを含む経路を確認する
5. 原因に合った最小限の変更を検討する
ステップ1：idで「誰なのか」を確認する
最初に重要なのは主体です。
対話的なシェルで自分自身を確認するなら、Linuxではidを使うことでユーザーIDやグループ情報を確認できます。
id
ただし、Webアプリのトラブルなら注意が必要です。
シェルへログインしている自分のユーザーと、アプリケーションのプロセスを実際に動かしているユーザーは別かもしれません。
その場合、自分のidだけを確認して「グループに入っているから問題ない」と判断すると、切り分けを誤ります。
確認したいのは、あくまで失敗した処理を実行している主体です。
ここは僕が実務でも最初に疑うポイントの一つです。
「自分ならできる」を確認するより、「失敗しているプロセスは誰なのか」を確認するほうが先なんですね。
ステップ2：ls -ldやstatで対象を確認する
次にuploadsディレクトリそのものを確認します。
ls -ld /srv/app/uploads
たとえば説明用に、次のような状態だったとします。
drwxr-xr-x 2 appowner appgroup … /srv/app/uploads
755なので、
- 所有者＝rwx
- グループ＝r-x
- その他＝r-x
です。
もしアプリの実行ユーザーがappownerではなく、appgroupのメンバーとして評価されるならどうでしょう。
グループ部分はr-xです。
wがありません。
アプリがuploadsの中へ新しいファイルを作成したいのなら、これが重要な手掛かりになります。
さらにLinuxではstatを使うと、ファイルやディレクトリの状態を詳しく確認できます。
stat /srv/app/uploads
lsの表示だけでは判断しにくいときに、対象のモードや所有者などを確認する材料になります。
ここまでで重要なのは、「755だから普通」「755だから安全」と数字だけで評価しないことです。
このuploadsに必要なのはアプリが新しいファイルを作成できることです。
つまり、必要な操作から権限を逆算します。
ステップ3：Whatを決める
ここで一度、問題を日本語に戻してみましょう。
「uploadsへアクセスできない」
では、まだ曖昧です。
- 中のファイルを読みたいのか
- 一覧を取得したいのか
- 新しいファイルを作りたいのか
- 既存ファイルの内容を書き換えたいのか
- ファイルを削除したいのか
によって見るべきポイントが変わります。
今回の目的はuploadsディレクトリ内へ新規ファイルを作成することです。
だからこそ、親ディレクトリであるuploads側の書き込みと検索・アクセスに必要な権限を確認します。
「Permission deniedだからwを付ける」ではなく、
何をしたい→その操作には何が必要→実行主体にそれがあるか
という順番です。
これだけでトラブルシューティングがかなり整理されます。
ステップ4：namei -lで経路を一本ずつ見る
ここで評価者の指摘にもあった、Linuxでかなり便利な確認方法を加えてみましょう。
util-linuxのnameiには、パスを構成する要素を追って表示する機能があります。-lを指定すると、各要素についてモードや所有者などを確認できます。
たとえば、
namei -l /srv/app/uploads/example.txt
のように確認します。
ポイントは、example.txtだけではなく、
/
srv
app
uploads
example.txt
というパスの途中まで縦に追えることです。
たとえばuploads自体は適切でも、その手前の/srv/appを対象ユーザーが通過できない設定なら、そこで問題になります。
僕はこの考え方を「目的地ではなく、道中のゲートも調べる」と覚えるのがおすすめです。
ls -l example.txtだけを何度見ても原因が見つからないとき、問題が一つ上、さらに一つ上のディレクトリに隠れていることがあります。
ステップ5：原因を特定してから最小限の修正を考える
ここまで調べて、仮に「アプリの実行ユーザーが必要なグループとしてuploadsへ書き込めない」ことが原因だと判明したとします。
この段階で初めて修正方法を考えます。
大切なのは、777へ広げることだけがchmodではないということです。
たとえば設定の意図に応じて、所有者・グループの設計が適切なのか、必要な主体にだけ書き込みを許可できないかを検討します。
所有関係そのものが間違っている場合には、chmodではなくchownなどを検討すべきケースもあります。
つまり、
調査→原因特定→設計確認→必要な変更
という順番です。
777は所有者・グループ・その他のすべてにrwxを与える基本モードです。
権限不足が原因なら777への変更によって動作が変わる可能性はありますが、それだけでは「本来どのユーザーに書き込みを許可すべきだったのか」という問題を解決したことにはなりません。
僕は777そのものを「悪い数字」として暗記する必要はないと考えています。
問題なのは、なぜ拒否されているのか分からない状態で、必要以上にアクセス範囲を広げて原因を見えなくしてしまうことです。
逆に755や644なら無条件に適切というわけでもありません。
適切なモードは、対象の役割と必要なアクセスによって決まります。
【出典：Linux man-pages 『namei(1) – follow a pathname until a terminal point is found』 https://man7.org/linux/man-pages/man1/namei.1.html】
【出典：Linux man-pages 『chmod(1) – change file mode bits』 https://man7.org/linux/man-pages/man1/chmod.1.html】
chmodだけで解決しないのはなぜ？chown・umask・ACLも関係する
ここまでの内容を理解すれば、rwx・chmod・755というこの記事の中心部分は押さえられています。
ただし実際のLinuxでは、chmodで見える基本モードだけがアクセス制御のすべてではありません。
ここでは深入りせず、「chmodを確認して終わりではない理由」だけ整理しておきます。
chownは「誰のファイルか」に関係する
chmodが、その立場に対して何を許可するかを変更するコマンドなら、chownはファイルの所有者やグループの変更に使われます。
GNU版chownでは、所有者だけでなくグループを含めた指定もできます。
そのため、先ほどのuploadsの例でも、そもそも所有関係の設計が意図した状態になっていないなら、chmodだけを何度変更しても根本的な整理にならない可能性があります。
権限エラーを見るときに、
「モードがおかしいのか、それとも所有関係がおかしいのか」
を分けて考えることが大切です。
【出典：Linux man-pages 『chown(1) – change file owner and group』 https://man7.org/linux/man-pages/man1/chown.1.html】
umaskは新しく作るファイルの初期権限に関係する
「自分ではchmodしていないのに、どうして新しいファイルが最初から644なの？」
そんな疑問につながるのがumaskです。
Linuxでは、新しくファイルやディレクトリを作成するときの権限にumaskが関係します。
代表的な考え方として、通常ファイル作成時の候補が0666で、umaskが022なら、該当するビットが落とされて0644になるケースがあります。
つまり、
rw-rw-rw-
からumaskによって書き込み権限の一部が抑えられ、
rw-r–r–
になるイメージです。
ただしLinuxでは、親ディレクトリにデフォルトACLが設定されている場合など、単純なumaskだけでは説明できないケースもあります。
ここまで来ると、「新規ファイルがなぜこのモードになるのか？」という疑問もchmodだけでは完結しないことが分かりますよね。
【出典：Linux man-pages 『umask(2) – set file mode creation mask』 https://man7.org/linux/man-pages/man2/umask.2.html】
特殊権限やACLもある
さらに、ファイルモードにはsetuid・setgid・sticky bitなどがあります。
たとえばsticky bitは、Linuxの共有ディレクトリにおける削除・名前変更の制限を考える際に重要です。
また、ACLを利用する環境では、Owner・Group・Othersという3区分だけでは表現しにくいアクセス制御を設定できる場合があります。
そのため、
「ls -lでrwxを見たら許可されている。だから権限関係ではない」
と即断するのも早い場合があります。
さらにLinux環境では、従来のモードビット以外のアクセス制御機構が関係するケースも考えられます。
ここで初心者の方に覚えてほしいのは、個々の高度な仕組みではありません。
rwxはアクセス制御を理解する最初の地図であって、OSのセキュリティ機構のすべてではないということです。
まずOwner・Group・Othersとrwxを理解する。
次に必要になったとき、chown、umask、特殊権限、ACLなどへ範囲を広げる。
この順番なら、一気に大量の専門用語を暗記しなくても理解を積み上げていけます。
またPOSIXで定義される基本的なchmodの考え方と、GNU/Linuxで利用できる具体的な機能や追加のアクセス制御は、完全に同じ話ではありません。
「UNIX系なら全部同じ」と決めつけず、実際に利用しているOSやファイルシステムの仕様を確認する姿勢も大切です。
【出典：GNU Project 『GNU Coreutils Manual – File permissions』 https://www.gnu.org/software/coreutils/manual/coreutils.html】
【出典：Linux man-pages 『chmod(1) – change file mode bits』 https://man7.org/linux/man-pages/man1/chmod.1.html】
UNIX系OSの権限管理をどう理解する？現役SEとしての考察
ここからは僕自身の考えです。
UNIX系OSの権限を勉強するとき、最初から「644は何？」「755は何？」という数字当て問題として覚えるより、主体・対象・操作の3点から考える練習をするほうが実践につながりやすいと思っています。
たとえば、こんな問題を考えてみましょう。
ある通常ファイルについて、
- 所有者はrw-
- グループはr–
- その他は—
- 操作ユーザーは対象グループの立場でアクセスする
- そのユーザーがファイルを書き換えたい
という条件だったとします。
この場合、グループに許可されている基本権限はrだけなので、読み取りはできても書き込みに必要なwがありません。
数字を一切使わなくても考えられます。
そのあとで、
rw-r—–
だから640だ、と変換すればいいんです。
僕はこちらの順番のほうが、chmodの数字と実際の操作を結び付けやすいと感じています。
Permission deniedは「OSが意地悪している」のではない
もう一つ、僕が重要だと考えているのは、Permission deniedを単なる邪魔なエラーとして扱わないことです。
OS側から見れば、設定されているアクセス制御に基づいて要求を拒否した結果かもしれません。
そこでsudoを付けて動かす、権限を最大まで広げる、といった方法だけでエラー表示を消してしまうと、なぜ通常の実行方法では拒否されたのかという重要な情報を見逃す可能性があります。
僕なら、まず次のように分解します。
- Who：誰が操作している？
- What：何をしようとしている？
- Where：どのファイル・ディレクトリが対象？
- Why：どの条件で拒否された？
- How：どの権限・所有関係なら要件を満たす？
特にWebアプリのような環境では、最初のWhoを間違えるだけで調査全体がずれてしまいます。
だからこそ、僕はchmodより先に「誰として動いているのか」を意識します。
755や644を「安全な数字」として覚えない
ここには、よくある初心者向け解説とは少し違う視点もあります。
777を避けて755や644を使えばよい、と数字だけ置き換えるのも、本質的には同じ「数字の丸暗記」になってしまいます。
たとえば644ではOthersにも読み取りが許可されます。
そのファイルをOthersから読める状態にすること自体が要件に合わないなら、「644はよく見るから」という理由だけで採用するべきではありません。
755も同じです。
ディレクトリなのか実行ファイルなのか、誰にアクセスさせるのかによって評価は変わります。
つまり重要なのは、
「何番にすればいい？」ではなく、「誰に、何を許可する必要がある？」
から考えることです。
これは権限管理だけでなく、システム設計全般にも通じる考え方だと思います。
必要な主体へ必要な操作だけを許可し、その理由を説明できる設定にする。
僕は、そこまで考えられるようになって初めて、chmod 755という数字を「覚えた」のではなく「理解した」と言えるのではないかと考えています。
まとめ：UNIX系OSの権限は「主体・対象・操作・経路」で調べよう
UNIX系OSの基本的なファイル権限は、Owner・Group・Othersに対してr・w・xのどこまでを許可するか決める仕組みです。
通常ファイルではrが読み取り、wが書き込み、xが実行を表します。一方、ディレクトリではrが一覧取得、wがエントリの変更に関係し、xは中の対象へアクセスするための検索・通過という重要な役割を持ちます。
chmodの755はrwxr-xr-x、644はrw-r–r–です。
4＝r、2＝w、1＝xという意味が分かれば、数字を丸暗記する必要はありません。
そしてPermission deniedが発生したら、実行主体→所有者・グループ→必要なrwx→親ディレクトリを含む経路→必要な変更という順番で確認してみましょう。
Linuxならid、ls -lやls -ld、statに加えて、パスを構成する要素を追えるnamei -lも切り分けの材料になります。
chmodは権限エラーを力ずくで消すためのコマンドではありません。
「誰が」「何に」「何をしたいのか」、さらに「そこまでの経路を通れるのか」を確認して、必要なアクセスだけを設定する。
この考え方が身につけば、755や644を暗記する段階から一歩進んで、Permission deniedの原因を自分で追えるようになります。
よくある質問
UNIX系OSのrwxとは何ですか？
rはRead（読み取り）、wはWrite（書き込み）、xはExecute/Search（実行・検索）に対応する基本的な権限です。
通常ファイルとディレクトリでは意味が異なり、ディレクトリのxは内部の対象へアクセスするための検索・通過に関係します。
chmod 755と644の違いは何ですか？
755はrwxr-xr-xで、所有者にはrwx、グループとその他にはr-xを設定します。
644はrw-r–r–で、所有者にはrw、グループとその他にはrを設定します。どちらが適切かはファイルやディレクトリの用途、アクセスさせたいユーザーによって判断します。
Permission deniedが出たら何を確認すればいいですか？
まず失敗した処理を実行しているユーザーを確認し、次に対象の所有者・グループとrwx、必要としている操作、親ディレクトリを含むアクセス経路を調べます。
Linuxではid、ls -ld、stat、環境によってはnamei -lなどを組み合わせると、対象だけでなく「そこへ到達するまで」の問題も切り分けやすくなります。
高橋健太（たかはしけんた）
現役SEのIT探求ブロガー
コメント