mediumFoundationSymptom-first#permissions#chmod#chown#acl#access

Permission denied — file access denied due to ownership or mode

Permission denied when accessing a file or directory

Likely source:configurationsecurity

Focused incident mode — strips away everything but this runbook.

Symptoms

  • Permission denied when accessing a file or directory
  • Application fails with EACCES error
  • Cannot read/write to a file you expect to have access to

Evidence to grab

Collect these artifacts before you change anything — they prove (or rule out) each cause.

  • File ownership and permissions

    ls -la <path> && stat <path>

  • Process user and groups

    id <user> && groups <user>

Diagnostic flow

Run the steps in order, marking each claim confirmed or refuted. The evidence you gather feeds the ranked causes below.

Guided decision tree is ready.

Steps with commands, expected output, and pass/fail branches.

Ranked root causes

Evidence checklist

  • ls shows the file owned by root instead of the application user
  • Application was installed as root but runs as a service user

Confirm before fixing

ls -la <path>
READ

Check the UID and GID

Fix

chown <user>:<group> <path>
CHANGE

Change the file ownership to the correct user

Resolution runbook

Apply from top to bottom after the cause is confirmed. Review every command before running it — risk tags are shown on each.

1
ls -la <path> && stat <path>
READ

Check file ownership and permissions

2
ps -p <PID> -o user,group,cmd
READ

Check which user the process runs as

3
chown <user>:<group> <path> && chmod <mode> <path>
CHANGE

Fix ownership and permissions

4
getenforce 2>/dev/null && ausearch -m avc --ts recent | tail -5
READ

Check for SELinux denials

Prevention

  • Document the required file ownership and permissions for each service in a deployment runbook.
  • Use Ansible/Chef/Puppet to enforce file permissions consistently.
  • Set umask in service unit files so created files have correct defaults.
  • Test permission changes in staging before applying to production.

Related runbooks

Same stack, same failure family — worth a skim.

Sudo not working — user not authorized for sudomedium

sudo: <user> is not in the sudoers file. This incident will be reported.

LinuxFoundation3 causes
Open runbook

Commands marked READ CHANGE DESTRUCTIVE — never run DESTRUCTIVE commands against production data you cannot restore. Copy → verify → execute.