Diagnosing and Fixing Unix "Permission Denied" Errors

Recognizing the Symptom

When a command returns Permission denied, the process is simply unable to perform the requested action on a file or directory. The error can stem from missing POSIX bits, an explicit ACL denial, or filesystem mount restrictions. The first step is to match the symptom to the likely cause before changing any settings.

Diagnostic Table

Symptom	Likely Cause	Diagnostic Command
Cannot read file contents	Missing read bit for user/group/other	ls -l <file>
Cannot enter a directory	Missing execute bit on a path component	ls -ld <path>
Cannot create or delete files	Missing write bit on parent directory	ls -ld <parent>
Access denied despite correct ls -l output	Restrictive ACL entry	getfacl <file>
Execution fails on a valid binary	Filesystem mounted with noexec or ro	mount | grep <mountpoint>

Step 1: Verify Process Identity

Permissions are evaluated against the process’s effective UID and GID. Run id from the offending user’s shell:

$ id
uid=1001(user) gid=1001(user) groups=1001(user),100(sudo)

Confirm that the UID/GID match the expected owner or group of the target file.

Step 2: Inspect File Metadata

Use stat to display mode bits and ownership:

$ stat /path/to/file
  File: "/path/to/file"
  Size: 1024   Blocks: 8          IO Block: 4096   regular file
Device: 802h/2050d  Inode: 1234567  Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1001) user  Gid: ( 1001) user
Metadata: ...

The Access line shows the octal mode. For a directory, the execute bit (x) allows traversal; for a file, it allows execution.

Step 3: Check for Access Control Lists (ACLs)

Standard POSIX permissions can be overridden by ACLs. An ACL is indicated by a + after the permission string in ls -l:

$ ls -l /path/to/file
-rw-r--r--+ 1 user user 1024 Nov 11 12:00 file

Retrieve the ACL entries:

$ getfacl /path/to/file
# file: /path/to/file
# owner: user
# group: user
user::rw-
user:alice:---
group::r--
other::r--

Here, user alice is explicitly denied all permissions, regardless of the group or other bits.

Step 4: Validate Filesystem Mount Options

If the file’s mode and ACLs look correct but the error persists, the underlying filesystem may impose restrictions. Check mount options:

$ mount | grep "/mnt/data"
/dev/sdb1 on /mnt/data type ext4 (rw,noexec,relatime)

A noexec option blocks binary execution, and ro prevents any writes.

Fixes Tied to Findings

Missing or Incorrect Ownership

Change the owner to the intended user or group:

$ sudo chown newuser:newgroup /path/to/file
# Verify
$ stat /path/to/file | grep Access
Access: (0644/-rw-r--r--)  Uid: ( 1002) newuser  Gid: ( 1002) newgroup

Use sudo to avoid accidental changes to system files.

Missing POSIX Bits

Add the required permissions with chmod:

$ chmod g+x /path/to/directory
# Verify
$ ls -ld /path/to/directory
drwxr-xr-x 2 newuser newgroup 4096 Nov 11 12:30 /path/to/directory

ACL Denials

Remove the restrictive ACL entry or grant the needed rights:

$ setfacl -x u:alice /path/to/file
# or
$ setfacl -m u:alice:r-- /path/to/file
# Verify
$ getfacl /path/to/file | grep alice
user:alice:r--

Filesystem Mount Restrictions

Remount the filesystem with appropriate options. For a temporary test, use:

$ sudo mount -o remount,rw /mnt/data
# or
$ sudo mount -o remount,exec /mnt/data

For permanent changes, edit /etc/fstab and remove noexec or ro as needed, then reboot or remount.

Escalation Criteria

• After correcting ownership or permissions, the error persists for a different user or process group.
• ACLs are present but cannot be modified due to lack of sudo privileges.
• Mount options cannot be changed because the filesystem is managed by a cluster or network share.
• The file resides on a system partition that is read‑only for safety reasons.

In these cases, involve the system administrator or the team responsible for the storage subsystem. Document the findings and the steps taken to avoid future confusion.

Practical Verification Checklist

1. Run id to confirm the process UID/GID.
2. Use stat to confirm mode bits and ownership.
3. If ls -l shows a +, run getfacl and adjust ACLs with setfacl.
4. Check mount for noexec or ro and remount if necessary.
5. Re‑attempt the operation as the affected user and confirm the error is resolved.

Each step should be logged. If the issue reappears after a system reboot or service restart, a deeper investigation into service‑specific umask settings or automated scripts that alter permissions is warranted.