Fix a Linux server that has permission denied

We'll check ownership with ls -la, fix permissions with chmod and chown, and confirm SELinux or AppArmor—or tell you when to escalate.

Category
Troubleshooting · Servers & Linux
Time
10–25 min
Last reviewed
What you'll need
  • SSH or console access with sudo

Step-by-step diagnostic

Step 1 of 5
Show full guide

Steps

Goal: Check ownership and permissions, fix with chown and chmod, and confirm SELinux or AppArmor.

  • Run ls -la on the file or directory.
  • Good: You see owner, group, and mode. Proceed to Fix permissions.
  • Bad: Confirm the path is correct.

Check ownership

Goal: Identify who owns the file and what permissions it has.

  • ls -la shows owner, group, and mode. The user must be owner, in the group, or have “other” access.
  • Good: You know what to fix. Proceed to Fix chown and chmod.
  • Bad: Check parent directory permissions with namei -l.

Fix chown and chmod

Goal: Set correct ownership and permissions.

  • sudo chown user:group file or sudo chown -R user:group dir. sudo chmod 755 dir or 644 file. Add user to group: usermod -aG group user.
  • Good: Access works. You are done.
  • Bad: Check SELinux or AppArmor.

When to escalate

Escalate if:

  • Changing ownership or permissions breaks the application.
  • SELinux/AppArmor policy changes are required.
  • The system is managed by config management.

Provide ls -la output, getenforce/aa-status, and the exact error.

Verification

  • The user can read, write, or execute the file as needed.
  • No “Permission denied” errors.
  • Service or application runs with correct privileges.

Escalation ladder

Work from the device outward. Stop when the problem is fixed.

  1. Check ls -la Identify owner, group, and permissions.
  2. chown and chmod Fix ownership and permissions.
  3. Group membership Add user to correct group; log out and back in.
  4. SELinux/AppArmor Check getenforce, aa-status; fix context or profile.
  5. Escalate Provide ls -la, getenforce/aa-status, and error.

What to capture if you need help

Before calling support or posting for help, have these ready. It speeds everything up.

  • ls -la output for the file/dir
  • getenforce or aa-status
  • Steps already tried

Does ls -la show the wrong owner or restrictive permissions?

Check who owns the file and what the mode is.

Run `ls -la` on the file or directory. Wrong owner: `sudo chown user:group file`. Restrictive mode: `sudo chmod 755 dir` or `644 file`. User not in group: `sudo usermod -aG group user`.

You can change your answer later.

Fix chown and chmod

`sudo chown user:group file` or `sudo chown -R user:group dir`. `sudo chmod 755 dir` or `644 file`. Add user to group if needed: `usermod -aG group user`. Log out and back in.

Is SELinux or AppArmor blocking?

getenforce (RHEL) or aa-status (Ubuntu).

Run `getenforce` (RHEL) or `aa-status` (Ubuntu). Enforcing: check logs for denials. Temporarily `setenforce 0` to test. Fix context with chcon/restorecon or adjust AppArmor profile. Permissive/disabled: not the cause—recheck permissions.

You can change your answer later.

Fix SELinux/AppArmor

SELinux: chcon or restorecon. AppArmor: aa-complain or fix profile. If policy change needed, escalate.

Done

Permissions fixed. Access should work.

Reviewed by Blackbox Atlas

Frequently asked questions

Why would Linux show permission denied?
Wrong owner or group, restrictive file permissions (chmod), SELinux/AppArmor policy, or the user needs sudo. Check ls -la first.
Can I fix permission denied myself?
Yes. Use chown to fix ownership, chmod to fix permissions. Check SELinux (getenforce, setenforce 0 temporarily) or AppArmor. Add user to the correct group.
When should I escalate permission issues?
If changing ownership or permissions breaks the application, SELinux/AppArmor blocks required access, or the system is managed by config management (Puppet, Ansible).

Rate this guide

Was this helpful?

Thanks for your feedback.

Continue to