Ubuntu EACCES (13) 対策：アクセス拒否エラー「Permission denied」発生時の権限設定と対策編

【注意】本記事は、Ubuntuで発生するEACCES(13)／「Permission denied（アクセス拒否）」の一般的な原因と対策を整理した情報提供です。実環境では運用要件・共有ストレージ・仮想化/コンテナ・セキュリティ機構（AppArmor等）・組織の権限設計により最適解が変わります。重要データや業務影響がある場合は、判断を誤ると復旧難易度や停止時間が増えることがあるため、株式会社情報工学研究所のような専門事業者に相談してください。

　

第1章：また「Permission denied」か…深夜のSREがため息をつく瞬間から

「ログを見る限り、ファイルは存在する。パスも合ってる。なのにPermission denied。え、なんで？」――この瞬間のモヤモヤ、現場の人ほど分かります。エラー文は短いのに、原因の候補が多すぎて、切り分けの入口が見えない。しかも本番だと、サービスを止めて検証する余裕はない。だからこそ、まずは“空気を落ち着かせる”ための型が必要です。

ここで大事なのは、権限問題を「chmodすれば直る話」と雑に扱わないことです。権限はLinuxの基本機能ですが、実運用ではACL、sudo、systemd、NFS、コンテナ、AppArmorなどが重なり、拒否の理由が一段深い場所に隠れていることが珍しくありません。

---

読者の頭の中の会話、たぶんこうです。

• 「自分のユーザーで読む分にはOKなのに、アプリからだと拒否される…“実行ユーザー”が違うやつか？」

• 「sudo付けてもダメ？ え、rootでもダメって何が拒否してるの？」

• 「権限いじって直したら、今度は監査に怒られそう。最小変更で収束させたい…」

そう感じるのは自然ですし、むしろ健全な疑いです。権限は“広げれば動く”けれど、広げた分だけ事故の芽も増えます。この記事では、まず被害最小化（ダメージコントロール）として「どこで拒否されたか」を短時間で特定し、そのうえで恒久対策（権限設計の型）に落とし込む流れを作ります。

---

最初に、今日のゴールを決めます。EACCESに遭遇したら、次の3つを順に確実化します。

1. 拒否した主体（カーネルの通常権限か、AppArmor等の追加制御か）を分ける

2. 拒否された対象（ファイルそのものか、親ディレクトリの探索権限か）を特定する

3. 恒久対策として「誰に・どこまで・いつ」権限を与えるべきか設計に戻す

この順番を守ると、場を整えるように切り分けが進みます。逆に、いきなりchmod 777のような操作をすると、一時的に動いても原因が消えてしまい、同じ障害が形を変えて再発しやすくなります。

　

第2章：EACCES(13)の正体――「誰が」「どこで」拒否したかを分解する

Ubuntuでよく見る「Permission denied」は、多くの場合システムコールの失敗として現れます。代表例は、ファイルを開く、ディレクトリをたどる、実行する、ソケットにバインドする、などです。アプリのログには文字列として出ますが、実体は「何をしようとして、どの権限チェックで落ちたか」の話です。

まず、EACCES(13)と混同しやすいものを分けます。Linux系では「権限がない」系のエラーが複数あり、原因の当たり方が少し違います。

エラー	よくある場面	典型原因
EACCES (13)	open/execve/chdir など	ファイル権限、親ディレクトリの探索権限、ACL、追加制御（AppArmor）
EPERM (1)	chmod/chown/mount など	操作自体に必要な特権がない、ケーパビリティ不足、保護属性
ENOENT (2)	存在しないファイル	パス誤り、シンボリックリンク切れ、コンテナ内パス差異

「Permission denied」だけ見ていると、原因が“権限”に見えますが、実際には「親ディレクトリにx（探索権限）がない」「シンボリックリンク先に辿れない」「AppArmorでプロセスが閉じ込められている」など、発生点がズレていることがあります。

---

ここでの分解はシンプルです。次の2つに切り分けます。

• 通常のUNIX権限/ACLによる拒否：所有者・グループ・その他、またはACLのルールで拒否される

• 追加のセキュリティ機構による拒否：AppArmor（Ubuntuで一般的）、SELinux（環境により）、systemdの制限など

現場の会話で言うと、「chmodしたのに直らない」パターンは後者が混ざっている可能性が高いです。UbuntuではAppArmorが有効なケースが多く、プロセスがアクセスできるパスがプロファイルで制限されます。この場合、ファイルの権限だけ整えても拒否が続きます。

---

さらに「どこで拒否されたか」を細かく見ると、切り分けが速くなります。たとえば、ファイルを読む権限（r）があっても、親ディレクトリに探索権限（x）がないと到達できません。ディレクトリの権限は直感とズレやすいので、ここを押さえます。

対象	必要になりやすい権限	典型的な落とし穴
ファイルの読み取り	ファイルに r ＋ 親ディレクトリに x	親に x がない／ACLで拒否
ディレクトリの一覧表示	ディレクトリに r（一覧）＋ x（探索）	x だけあると「入れるが一覧が見えない」
プログラム実行	実行ファイルに x ＋ 親ディレクトリに x	マウントオプション noexec など（環境依存）

この章の結論は「拒否の主体」と「拒否された地点」を分けることです。次章では、具体的に“たった3点”を確認するだけで、原因候補を大きく絞る手順に入ります。

　

第3章：最初に潰す思い込み――パス・実体・実行ユーザーの3点確認

切り分けを「リセット」するなら、まずは3点です。ここを飛ばすと、以降の作業が全部ズレます。現場の本音としては「急いで直したい」のですが、急いでいるときほど最短ルートは“確認の型”です。

1. パスは本当にそのファイルか？（シンボリックリンク、相対パス、chroot/コンテナ差異）

2. 実体はどこにあるか？（親ディレクトリを含めて到達できるか）

3. 実行ユーザーは誰か？（ログインユーザーではなく、プロセスの実効UID/GID）

---

まず「パス」です。アプリの設定ファイルや環境変数でパスが変わると、想定外の場所を見に行ってEACCESになることがあります。特に、相対パス（./data 等）は、起動ディレクトリが変わっただけで別物になります。確認には、次のような観点が有効です。

• ファイルがシンボリックリンクなら、リンク先まで追えているか

• systemd起動なら WorkingDirectory がどこか

• コンテナならホストとコンテナ内のパスが一致しているか（マウントポイント）

次に「実体」。親ディレクトリを1段ずつ検査すると、どこで探索権限が切れているかが分かります。Linuxではディレクトリの x が“通行権”に相当します。これが欠けると、最終ファイルにrがあっても到達できません。

代表的な確認コマンド例（出力は環境で異なります）。

ls -ld /path /path/to /path/to/target namei -l /path/to/target id ps -o user,uid,euid,group,gid,egid,comm -p <PID>

---

そして一番の落とし穴が「実行ユーザー」です。たとえば、手元で手動実行すると通るのに、サービスとして動かすと拒否される。これは“あなたのユーザー”ではなく、systemdが指定した User= のユーザーで動いている可能性が高いです。

心の会話としてはこうなります。

• 「俺の端末では動くのに、CIだと落ちる…」

• 「sudoで試したら通った。じゃあ権限不足だ。…でも本番でsudo前提にはできないよな」

ここで重要なのは、“動く権限”ではなく、“運用として許容できる権限”に落とすことです。たとえばログディレクトリに書けないなら、アプリユーザーに必要最小限の書き込みを与えるか、出力先を設計として変更するか。場当たり的に所有者を全部変えると、今度は別プロセスが書けなくなり、二次障害が起きます。

この章の結論は「確認を3点に絞る」ことです。次章では、chmod/chown/chgrpという基本操作を、事故りやすいポイント（ディレクトリ権限、共有グループ運用、再帰変更のリスク）まで含めて整理します。

　

第4章：chmod/chown/chgrpの基本と罠――“見えてる権限”が真実とは限らない

chmod/chown/chgrpは基礎ですが、実運用で「権限変更＝正義」になりやすいところが怖い点です。ここでは、最小変更で“収束”させるための考え方を先に置きます。ポイントは、対象を3つに分けることです。

• 対象がファイルかディレクトリか（必要権限の意味が違う）

• 単発対応か、運用ルールとして継続するのか（umask/ACL/グループ設計が関わる）

• 誰のために開けるのか（ユーザー・グループ・その他のどこを広げるか）

---

まず、ディレクトリ権限の誤解を整理します。ディレクトリの r/w/x はファイルと意味が違います。特に x（探索）が肝です。

ディレクトリ権限	意味	現場での症状
r	中身の一覧（名前）を読める	ls が通る／ただし入れるとは限らない
x	中に入る・パスを辿る（探索）	cd できる／ファイルに到達できる
w	作成・削除・リネームが可能（※xと組み合わせが重要）	ログ出力や一時ファイル作成に影響

よくある事故は「ファイルにrを付けたのに直らない」です。原因は親ディレクトリにxがない、または途中のどこかで権限が切れているケースです。だから第3章で示したように、親から1段ずつ辿る確認が効きます。

---

次に所有者とグループ。BtoBの現場では、単一ユーザーに寄せるより、グループ単位で権限を設計するほうが運用が安定します。たとえば、アプリ運用用のグループを作り、そのグループに書き込み権限を付ける。ここで「setgidビット」をディレクトリに付けると、配下の新規ファイルがグループを引き継ぎやすくなり、権限ズレの再発を抑えられます（ただし、環境と運用ポリシーに依存します）。

ただし、再帰的なchown/chmodは“強い”操作です。直ったように見えても、別サービスの所有権まで変わって後で炎上（クレーム対応）になることがあります。特に共有サーバや複数アプリ同居環境では、影響範囲の見積もりが必須です。

---

最後に「見えてる権限が真実とは限らない」問題です。ls -l で見えるのは基本権限（所有者/グループ/その他）ですが、実際にはACLやAppArmorなどが別レイヤで効きます。つまり、chmodで開けたつもりでも、別レイヤが拒否している可能性が残ります。次章以降で、ACL（getfacl/setfacl）やumask、sudo/systemd、共有ストレージといった“重なり”を順にほどいていきます。

ここまでの段階での現実的な指針としては、最小変更で暫定復旧（被害最小化）→原因の確定→恒久対策の順が安全です。業務影響が大きい場合や、監査・セキュリティ要件が絡む場合は、一般論だけでは判断が難しいため、専門家に設計の観点から相談するのが結果的に早いことがあります。

　

第5章：ACLで起きる「例外ルール」――getfacl/setfaclで可視化して腹落ちさせる

「ls -l では読める権限に見えるのに、実際はPermission denied」――このズレを生む代表格がACL（Access Control List）です。Ubuntuでも、共有ディレクトリやチーム運用の都合でACLを入れている現場は珍しくありません。問題は、ACLが“例外ルール”として静かに効くため、ぱっと見で気づきにくいことです。

ACLは、所有者/グループ/その他の3区分だけでは表現できない権限（「このユーザーだけ許可」「このグループには拒否」など）を付与できます。つまり、従来のUNIX権限を理解している人ほど「これで足りるはず」と思い込みやすい。ここが落とし穴です。

---

まずは可視化です。ACLが設定されているファイルやディレクトリは、環境によっては ls -l の権限表示の末尾に「+」が付くことがあります（例：drwxr-x---+）。ただし、すべての表示形態で気づけるとは限りません。確実なのは getfacl で実体を見ることです。

getfacl /path/to/target getfacl -R /path/to/dir | less

見どころは次の行です。

• user: や group: に個別指定が入っていないか

• mask: が意図せず権限を絞っていないか（ACLの実効権限に影響）

• default: がディレクトリに設定され、新規作成時に継承していないか

---

ここで現場の「心の会話」を一つ。ACLが見つかった瞬間、こうなりがちです。

• 「え、ACL入ってたのか…誰がいつ足した？」

• 「今直すなら消せばいい？ でも消していいのか分からない…」

この不安は正当です。ACLは“運用設計の意思”を反映している場合があります。たとえば、監査対応で「特定ユーザーだけ閲覧可」にしている、委託先に一時的に権限を渡した、などです。無闇に消すと、セキュリティ事故や業務上のトラブルになり得ます。

---

対策の基本は「影響範囲を見積もる」「最小変更で収束させる」です。次のような整理が役に立ちます。

状況	よくある原因	現実的な打ち手
特定ユーザーだけ拒否される	ACLで個別拒否/未付与、maskで実効権限が落ちる	getfaclで差分確認→必要最小のACL追加/修正
新規ファイルだけ毎回権限がズレる	default ACL や umask の影響	default ACL/umask/グループ設計を見直す
chmodしても直らない	ACLや追加制御が優先/併用	ACLの実効権限を確定→次章のumaskやsystemdへ

この章の結論は、ACLは「見えにくい例外ルール」なので、まず可視化してから触るです。次章では、運用で再発しやすい「umask」と“新規作成物の権限が勝手にズレる”問題を、仕組みとして抑え込みます。

　

第6章：umaskとデフォルト権限――新規ファイルが毎回ズレる根本原因

Permission deniedが「一度直したはずなのに、翌日また出る」タイプで再発するとき、犯人になりやすいのがumaskです。umaskは“デフォルト権限をどう削るか”の設定で、プロセスが新規ファイルやディレクトリを作るときに効きます。つまり、過去のファイルは直しても、未来のファイルがまたズレて、エラーが再発します。

この再発は、現場の温度を上げます。

• 「昨日直したのにまた？ 俺の作業、意味あった？」

• 「運用で毎回手直しとか、無理だよ…」

この感覚は正しいです。ここは“手作業”ではなく“仕組み”で温度を下げるべき領域です。

---

umaskはプロセス単位で効きます。ログインシェル、sudo、systemdサービス、cron、コンテナ、どの経路で起動したかで値が変わることがあります。ここがややこしいポイントで、開発者がローカルで試したときのumaskと、本番サービスのumaskが違う、ということが起きます。

確認の例（実行環境に合わせて使い分けます）。

umask grep -R "UMask" /etc/systemd/system /lib/systemd/system 2>/dev/null systemctl show <service> -p UMask

---

新規ファイル/ディレクトリの“典型的な差”を整理します。

作成物	本来の最大権限（一般的）	umaskで削られる	現場の症状
ファイル	666（rw-rw-rw-）	umask分が引かれる	グループが読めずアプリが落ちる
ディレクトリ	777（rwxrwxrwx）	umask分が引かれる	探索権限xが落ちて到達できない

よくあるのが「ログディレクトリ配下に新しいファイルが作られた瞬間だけ読めない／書けない」です。これは、作成プロセスのumaskが厳しすぎて、運用想定より閉じた権限で生成されるために起きます。chmodで既存ファイルを直しても、将来作られるファイルには効きません。

---

恒久対策としては、次のどれを採るかを設計で決めます。

• systemd側でUMaskを固定し、サービスが作るファイルの権限を一貫させる

• グループ運用＋setgidディレクトリで、所有グループのズレを抑える

• default ACLで、新規作成物に必要権限を継承させる

どれが最適かは「監査」「委託先の範囲」「事故時の影響範囲」によって変わります。一般論としては、運用チームが理解しやすく、レビュー可能な仕組みに寄せるほど、長期的にトラブルが減ります。

この章の結論は、再発するEACCESは“作成時のルール（umask/継承）”が原因になりやすいということです。次章では「sudoでも通らない」「rootでもダメ」に見えるケースを、sudoers・setuid・capabilitiesの観点で整理します。

　

第7章：sudoでも通らない理由――sudoers / setuid / capabilities の使い分け

権限トラブルでありがちな“誤解の加速”が、「sudoを付ければ何でもできるはず」という感覚です。実際、sudoで解決することも多いのですが、運用として“sudo前提のアプリ”は設計が破綻しやすい。さらに、sudoでも通らないケースがある。ここが混乱ポイントです。

---

まず整理します。Linuxの特権には段階があります。

• sudo：コマンド実行時に別ユーザー（多くはroot）として実行できる仕組み。sudoersで許可が決まる

• setuid：実行ファイルに「実効UIDを所有者にする」性質を付ける仕組み。古典的だが扱いに注意が必要

• capabilities：root権限を丸ごと渡すのではなく、必要な権限だけを付与する考え方

「現場が楽になるなら導入したいけど、トラブルは増やしたくない」という本音に対しては、一般にcapabilitiesやsystemdの権限付与の方が、sudo乱用より設計が安定しやすい傾向があります。もちろん、要件次第です。

---

sudoでも通らない（または期待通りにならない）典型例を挙げます。

• sudoしてもアクセス先が変わる：rootの環境変数やカレントディレクトリが変わり、別パスを見てしまう

• sudoで起動したが、子プロセスは別ユーザー：systemdやアプリが内部で権限を落としている

• 追加制御が拒否：AppArmor等がプロセスの振る舞いを制限し、rootでも許可されない設計がある

特に3つ目は「rootでもダメ」の正体になりがちです。UbuntuではAppArmorプロファイルが適用されていると、プロセスがアクセスできるパスが制限されます。ここは“権限”というより“ポリシー”の話で、chmod/chownとは別レイヤです。

---

設計の観点では、次のように考えると整理しやすいです。

やりたいこと	安定しやすい方針	注意点
特定ポートにバインドしたい（例：1024未満）	capabilitiesで必要権限のみ付与	バイナリ更新時の継承や運用手順が必要
一時的な調査/復旧でroot作業したい	sudoで限定コマンド許可	恒久運用をsudo前提にしない
アプリを常時rootで動かしたい	原則避ける（設計見直し）	被害範囲が大きくなりやすい

この章の結論は、sudoは“切り分けや暫定復旧”には強いが、“恒久運用の答え”とは限らないです。次章では、Ubuntu運用で現実にハマりやすいsystemdの設定（User/Group/Protect* 等）が、Permission deniedの原因になるケースを整理します。

　

第8章：systemdの防御設定が締め出す――User/Group/Protect*と実行権限の関係

Ubuntu運用で「手動だと通るのに、サービスだとPermission denied」が出るとき、systemdユニットの設定が原因になっていることがよくあります。ここは盲点になりやすい。なぜなら、アプリ開発者が意識するのはソースコードとファイル権限ですが、systemdは“プロセスの実行環境そのもの”を制御するからです。

現場の心の声はだいたいこうです。

• 「同じコマンドを叩いてるのに、サービスだとダメ…？」

• 「ユニットファイル、誰がどこまで固めたんだっけ」

このモヤモヤは自然です。systemdは運用の安全性を上げる一方で、制限が強いと意図せずアクセス拒否を起こします。ここでは、よく効く項目を“チェックリスト化”して、切り分けをストッパーで整理します。

---

まず基本は、サービス実行ユーザーです。ユニットに User= や Group= が書かれていると、ログインユーザーの権限は関係ありません。第3章の「実行ユーザー確認」がここに繋がります。

次に、systemdの保護系設定です。Ubuntu環境でも、セキュリティ強化の一環としてよく使われます。代表的なものを整理します。

設定	効果（ざっくり）	Permission deniedになりやすい例
ReadOnlyPaths= / InaccessiblePaths=	指定パスを読み取り専用/不可にする	/var/log や /etc 配下への書き込み・参照が拒否
ProtectSystem=	システム領域を保護	想定外の書き込み先がシステム側にあると失敗
ProtectHome=	/home 等へのアクセス制限	ホーム配下の設定・鍵・キャッシュにアクセスできない
PrivateTmp=	/tmp をサービス専用にする	別プロセスと/tmp経由で連携していると見えなくなる
UMask=	サービスのumaskを固定	新規作成物の権限が閉じて再発（第6章と接続）

---

ここで大事なのは、「保護設定を全部OFFにして直す」ではなく、どの制限が拒否しているのかを特定して、必要最小の許可に落とすことです。BtoBの現場だと、監査やインシデント対応の観点で「なぜその権限が必要か」を説明できる状態が求められます。

確認の観点としては、ユニットの実効設定を見て、アプリがアクセスするべきパスと照合するのが王道です。

systemctl cat <service> systemctl show <service> | grep -E "User=|Group=|UMask=|Protect|ReadOnlyPaths|InaccessiblePaths|PrivateTmp"

---

この章の結論は、systemdは“権限エラーの発生源”にも“再発防止の仕組み”にもなるということです。次章では、さらにややこしい「コンテナ」「NFS」「共有ストレージ」で起きるUID/GIDズレやroot_squashなど、権限が“別世界に持ち越される”問題を扱います。

　

第9章：コンテナ・NFS・共有ストレージの落とし穴――UID/GIDズレとroot_squash

Permission deniedが長引く案件で、最後に出てくる“ラスボス”が共有ストレージ系です。コンテナやNFS、NAS、クラウドストレージのマウントなどが絡むと、ローカルのchmod/chownの直感が効きにくくなります。ここで議論が過熱しがちなのは、誰の責任でもなく「境界の仕様」が原因で起きるからです。

---

代表的なのはUID/GIDのズレです。Linuxのファイル所有者は“名前”ではなく“数値（UID/GID）”で管理されます。ホストAではUID 1001がappuser、ホストBではUID 1001が別ユーザー、という状態で共有すると、所有者が意図せず変わります。コンテナも同様で、コンテナ内のユーザーIDとホスト側のIDが一致していないと、マウント先で拒否が起きます。

現場の会話としては、こういう感じです。

• 「コンテナ内では書ける想定なのに、ボリュームが拒否する…」

• 「chownしたら直る？ でもNFS側で反映されないんだけど」

---

NFSでは、サーバ側のエクスポート設定が絡みます。特に有名なのが root_squash です。これは“クライアント側のrootを、サーバ側では匿名ユーザー扱いにする”挙動で、セキュリティ上の理由で一般的に有効化されます。すると、クライアントでsudo/rootで操作しても、サーバ側では権限がない扱いになり、Permission deniedに見えます。

このパターンは「rootでもダメ」の典型で、chmod/chownでは解決しません。必要なのは、共有の設計（どのUID/GIDで書くか、どの範囲を許可するか）と、ストレージ側設定の整合です。

---

共有ストレージ絡みの切り分けを“収束”させるための観点をまとめます。

現象	疑うべきポイント	次に確認すること
ホストではOK、コンテナで拒否	コンテナの実効UID/GID、ボリューム所有権	コンテナ内のid、マウント先の所有UID/GID
sudo/rootでも拒否	NFSのroot_squash、サーバ側権限	NFSエクスポート設定、サーバ側の所有権/ACL
特定ホストだけ拒否	UID/GIDの不統一、名前解決の差	各ホストの /etc/passwd / id の整合

---

ここでの要点は、境界をまたぐと「同じユーザー」に見えても別物になるという現実です。BtoBの現場では、NASや仮想化基盤、コンテナ基盤、監査要件が絡み、単純に権限を広げれば良い話ではなくなります。一般論だけで突き進むと、想定外の情報流出リスク（損失・流出）を作りかねません。

次章では、これまでの切り分けを踏まえて「再発を止める権限設計の型」と「一般論の限界」を整理し、相談・依頼に自然につながる形でまとめます。

　

第10章：仕組みで再発を止める――権限設計の型と切り分けチェックリスト（相談の目安）

ここまで読んで、「結局、権限って“その場しのぎ”で直しても再発する」と感じたなら、それは正しいです。EACCESの多くは、単発のミスではなく“設計の隙間”から出てきます。だから最後は、個別のchmodテクニックではなく、仕組みとしての再発防止に落とします。

---

再発防止の基本は、権限を次の3レイヤに分けて設計することです。

1. 実行主体（プロセス）：どのユーザー/グループで動かすか（systemdのUser=等）

2. データ領域：どのディレクトリに読み書きするか（ログ、キャッシュ、永続データ）

3. 作成ルール：新規作成物の権限をどう揃えるか（UMask、setgid、default ACL）

この3点が揃うと、Permission deniedは“事故”ではなく“検出可能なズレ”になります。逆に、どれかが曖昧だと、担当者が変わったときに再発しやすい。

---

ここで、現場に効く「切り分けチェックリスト」を短くまとめます。夜間対応でも、これを順に潰すと空気を落ち着かせる効果があります。

• 実行ユーザー確認：プロセスの実効UID/GIDは誰か

• 到達確認：親ディレクトリを含めて探索権限(x)は足りているか

• ACL確認：getfaclで例外ルールがないか、maskで落ちていないか

• 作成ルール確認：umask/UMask、default ACL、setgidで再発しないか

• 境界確認：コンテナ/NFS/共有でUID/GIDやroot_squashが噛んでないか

• 追加制御確認：systemd保護設定やAppArmor等のポリシーで拒否されていないか

---

そして、ここが一番大事な「一般論の限界」です。権限はセキュリティそのものなので、

• 委託先・派遣・多拠点など、複数主体が関わる

• NAS/仮想化/コンテナ/クラウドが絡む

• 監査要件やログ保全、機密区分がある

• 障害復旧と同時に情報漏えい対策・BCPが要求される

こういった条件が重なるほど、ネット記事の一般論だけで“正解”を確定するのは難しくなります。なぜなら、権限の最適解は「業務影響」「攻撃面」「運用体制」「復旧期限」のトレードオフで決まるからです。

---

たとえば、同じEACCESでも、

• 一時的にログが書けないだけ（機能限定）

• 顧客データにアクセスできない（業務停止）

• 共有領域の権限が広がりすぎている（漏えいリスク）

では、優先順位も対処も変わります。ここを“勘”でやると、短期的に直っても、後で別のトラブルが起きて炎上します。

だからこそ、具体的な案件・契約・システム構成で悩んだときは、株式会社情報工学研究所のような専門家に相談する価値があります。権限設定を単なる設定作業としてではなく、「運用設計」「セキュリティ」「復旧（被害最小化）」「説明責任」まで含めて整理し、現場が回る形で落とし込むのがプロの仕事だからです。

　

補遺：主要プログラミング言語別「Permission denied」を増幅させない注意点

ここからは「実装側でEACCESをどう扱うか」を、現在よく使われる言語ごとに整理します。ポイントは共通していて、①実行ユーザーの前提をコード側で固定しない、②相対パスや作業ディレクトリの揺れを前提にする、③新規作成時の権限（umask/モード）を観測できるログを残す、この3つです。ここを押さえると、障害時の切り分けが“沈静化”しやすくなります。

---

共通（全言語）

• 相対パス前提を避ける：サービス起動経路（systemd/cron/CI）でカレントディレクトリは変わります。ログには「解決後の絶対パス」を出すと切り分けが速くなります。

• 誰として動いているかをログに出す：プロセスの実効UID/GID（少なくともユーザー名/グループ名）を起動時に記録すると、後から「手動実行との差」を説明できます。

• 新規作成物の権限を“観測”する：ファイル作成直後に stat 相当の情報（所有者/パーミッション）を出すと、umask/ACLの影響を見抜きやすくなります。

• 例外の握りつぶしをしない：Permission deniedを「再試行で誤魔化す」と、原因が残ったまま別の場所で再発します。再試行は被害最小化の手段としては有効ですが、ログに errno と対象パスは必ず残します。

---

Python

• 例外（OSError / PermissionError）から errno=13 を取れる形でログ：スタックトレースだけでなく、対象パス・操作（read/write/create）・実行ユーザーを合わせて残すと復旧が早いです。

• 一時ディレクトリの扱い：テンポラリ生成先がsystemdの制限やPrivateTmpの影響を受けることがあります。実行環境に依存するため、保存先を設定で切り替えられる設計が安全です。

Node.js（JavaScript/TypeScript）

• fs系APIのエラーコード（EACCES/EPERM）を区別：ログには code と syscall（open/write/mkdir等）を含めると、ファイル権限か操作権限かを切り分けやすいです。

• プロセスのumaskや実行ユーザー差を前提にする：ローカルで動いても、systemd配下やコンテナで別ユーザーになるのは普通に起きます。起動時に process.getuid()/process.getgid() 相当を記録すると再現が速いです。

Go

• os.OpenFile の mode 指定はumaskの影響を受ける：期待する権限がそのまま付与されるとは限りません。作成後に権限確認（stat）するログが役に立ちます。

• エラーのラップで原因が見えなくなるのを防ぐ：fmt.Errorfで包む場合でも、元のエラー（syscall/errno）を追える形で残すと、現場の“収束”が早いです。

Java（JVM系含む）

• 実行ユーザーはJVMではなくOSで決まる：アプリ側の設定でユーザーを切り替えているつもりでも、systemdのUser=が優先されます。起動ログにOSユーザー名を出すのが有効です。

• パス解決と権限エラーの混同に注意：存在しない（ENOENT相当）とアクセス不可（EACCES相当）が例外メッセージだけでは紛らわしいことがあります。対象パスと操作の明記が重要です。

C / C++

• errno=EACCES(13)とEPERM(1)の区別：同じ「権限がない」に見えても、原因の層が違います。ログには errno と対象パス、呼び出した操作（open/chmod/chown等）を出すのが基本です。

• 権限変更（chown/chmod）をアプリにやらせる設計は慎重に：運用側の権限設計と衝突しやすく、二次障害（別プロセスが書けなくなる）を招くことがあります。

PHP / Ruby

• Webサーバ実行ユーザー（www-data等）前提で設計する：CLIでは通るがWeb経由で拒否、が典型です。アップロード/ログ/キャッシュの書き込み先は、Web実行ユーザーに合わせて明示的に設計します。

• 共有ホスティングやNAS配下では所有権変更が効かない場合がある：ストレージ側の仕様（共有設定、NFS等）で制約が出るため、アプリ側だけで完結しないケースがあります。

.NET（C#）

• 例外メッセージだけで判断しない：アクセス拒否は、実行ユーザー差・サービス設定差・共有ストレージ境界で発生しやすいです。対象パス、操作種別、実行ユーザー情報をセットで残す設計が有効です。

シェルスクリプト（bash等）

• 実行環境差（sudo、cron、systemd）でPATHやumaskが変わる：同じスクリプトでも起動方法で挙動が変わります。冒頭でumask・whoami・pwdをログに出すだけで、切り分けが大きく前進します。

• リダイレクトの権限罠：sudo echo ... > /path のような書き方は、リダイレクト側がsudo対象外になりやすく、Permission deniedの原因になります。運用では特に注意が必要です。

---

最後にまとめです。言語が違っても、EACCESの本質は「OSが拒否した」という一点に集約されます。だから、実装側でできる最も堅いダメージコントロールは、拒否された対象（パス）・操作・実行ユーザー・発生頻度を正確に記録し、運用側の権限設計（systemd/ACL/umask/共有ストレージ）と突き合わせられる状態を作ることです。

一方で、実際の現場では「誰にどこまで権限を与えるべきか」は、契約条件・監査要件・共有範囲・BCP（停止許容時間）で最適解が変わります。一般論のテクニックだけで進めると、短期的に動いても別のリスク（過剰権限、共有領域の拡大、運用破綻）が残ることがあります。そうした局面では、株式会社情報工学研究所のように、運用・セキュリティ・復旧の観点を横断して整理できる専門家へ相談し、設計として“収束”させる判断が有効です。