Linux system errors
Permission Denied
Reviewed for reference consistency: August 11, 2026
the process does not have permission to access the resource
What 13 Means
The 13 error on the Linux system errors indicates permission denied — the process does not have permission to access the resource. This typically occurs due to the file's read, write, or execute permission bits do not grant the process's user or group the requested access.
Errno 13 is EACCES, 'Permission denied': the kernel refused a system call because the file's permission bits or a security policy block the process. The denial is path-specific: reading a file the user cannot read, writing into a directory without write access, traversing a directory component whose execute bit denies the search, or executing a file whose execute bit is missing or whose filesystem is mounted noexec. Debugging starts by comparing who the process runs as (id) with who owns the path (ls -l).
How to fix 13
General informational guidance, not professional advice. Commands can affect your system or data — back up first and proceed at your own risk. FixerCode is an independent reference, not affiliated with any vendor mentioned.
Inspect the file's current permissions and owner
List the permission bits, owner, and group for the path that triggered the denial to see which permission is missing.
ls -la /path/to/fileConfirm which user the process is running as
A process may run under a different user than expected, especially inside services, containers, or cron jobs.
whoami && idCheck for extended ACLs or security module denials
Standard permission bits may look correct while an ACL or a security module like SELinux or AppArmor blocks the access separately.
getfacl /path/to/file ; ausearch -m AVC -ts recent 2>/dev/null || journalctl -t audit --since '5 min ago'Verify the full directory chain is traversable
Even if the target file is readable, a missing execute bit on any parent directory prevents traversal to reach it.
namei -l /path/to/file
Technical Background
Error 13 (EACCES) is a kernel-level enforcement of security policy. It means the system call requested by the process was blocked because the user account running the process does not have the necessary permissions for that specific file or directory.
The man pages pin down where EACCES comes from: open(2) returns it when the requested access is not allowed or when search permission is denied for a directory in the path prefix; execve(2) returns it when execute permission is denied for the file or its interpreter, or when the filesystem is mounted noexec.
Creating a file follows the same rule in reverse: with O_CREAT, open(2) requires write access to the parent directory, and a denial there is also EACCES.
This can happen even for the 'root' user in environments with Mandatory Access Control (MAC) systems like SELinux or AppArmor, which can restrict even superuser access based on security profiles.
Common Causes
- The file's read, write, or execute permission bits do not grant the process's user or group the requested access
- A directory component of the path lacks the execute (search) bit, blocking traversal before the target is reached
- The file's execute bit is not set, or the filesystem carrying it is mounted with the noexec option
- Creating a new file inside a directory that does not grant the process write access
- A mandatory access-control policy (SELinux, AppArmor) denies the operation even when the traditional permission bits look permissive
Typical Scenarios
- A web server process running under a service account tries to read a configuration file owned by root with mode 0600
- A freshly written or downloaded script is executed before 'chmod +x', so the kernel refuses execve despite the file being readable
- A binary on a filesystem mounted with the noexec option is executed — the mount flag, not any permission bit, supplies the denial
- A script reaches a file only through a parent directory whose execute bit it lacks, so access fails even though the target file itself is readable
What to Know
Verification of file ownership and permission bits (using 'ls -l') is the first step in resolving access rejections. In restricted environments, auditing security profiles (like SELinux or AppArmor logs) may reveal mandatory policy blocks.
Frequently Asked Questions
Common questions about Linux 13 error
No. Error 13 is EACCES, 'Permission denied': the access check against the file's permission bits failed. Error 1 is EPERM, 'Operation not permitted': the operation itself is one an unprivileged process may not perform at all. chown(2) returns EPERM to a process without the CAP_CHOWN capability, and so does an attempt to modify a file marked immutable.
Yes. Two documented cases produce EACCES without any defect in the target file: search permission denied on one of the directories in the path prefix, and executing from a filesystem mounted noexec. Walking the path with namei -l shows which component denies traversal.
Executing is a separate permission from reading. execve(2) returns EACCES when execute permission is denied for the file, for a script's interpreter, or for the ELF interpreter. Read permission lets you display the file; the execute bit decides whether the kernel will run it.
Yes, under mandatory access control. SELinux or AppArmor policies can deny operations through the security layer itself, even when the traditional permission bits and the superuser account would otherwise allow them.
Related Error Codes
Related Errors From Other Categories
Similar error codes documented across different platforms and systems
The Docker CLI reached no daemon, so every command stops before doing any work.
The daemon answered, but the current Unix user lacks rights on the socket.
A newer client asked for an API version the connected daemon refuses to serve.
The registry refused the pull because the repository is private or unknown.