Python runtime, filesystem, CLI python os permission io
Ryan Holloway Senior DevOps Engineer

OSError: [Errno 13] Permission denied: 'X'

Encountering OSError: [Errno 13] Permission denied means your Python script was denied access to a file or resource; this guide explains how to fix it.

As a Senior DevOps Engineer, I've debugged countless permission issues, and OSError: [Errno 13] Permission denied is one of the most common and, frankly, most frustrating errors you'll hit in Python, especially when dealing with filesystem operations. It pops up when your program tries to do something – read a file, write to a directory, execute a script – and the operating system says, "Nope, not allowed." The 'X' in the error message will specify the exact file or directory that caused the problem.

What This Error Means

At its core, OSError: [Errno 13] Permission denied signifies a failed attempt to perform a file system operation due to insufficient privileges. Let's break down the components:

  • OSError: This is a general error class in Python (a subclass of IOError in older Python 2, and PermissionError is a direct subclass of OSError since Python 3.3). It indicates a problem with an operating system function call.
  • [Errno 13]: This is the specific error number reported by the underlying operating system. Error number 13 universally means "Permission denied" across POSIX-compliant systems (Linux, macOS, Unix-like).
  • Permission denied: The human-readable interpretation of Errno 13.
  • 'X': This placeholder is crucial. It will be the path to the file or directory that your Python script attempted to access without the necessary permissions. Pinpointing this 'X' is the first step to resolution.

Essentially, your Python process, running under a specific user account, asked the operating system to interact with 'X', and the OS, after checking its security rules, rejected the request.

Why It Happens

Operating systems are built with security models to prevent unauthorized access and protect system integrity. Every file and directory has associated permissions and ownership information. When your Python script attempts an operation (read, write, execute), the OS checks the following:

  1. The User: What user account is running the Python script? Every process runs as a specific user (and usually a primary group).
  2. The Resource: What are the ownership and permissions of the file or directory 'X'?
  3. The Operation: What is the script trying to do (read, write, execute)?

If the user running the script doesn't have the appropriate permissions (either directly, or via group membership, or "other" permissions), the OS throws Errno 13. It's a fundamental security gate in action.

I've seen this in production when a service account's permissions were too restrictive, or more commonly, when a service started by root created a file that a non-root service later tried to modify.

Common Causes

Let's list the usual suspects that lead to this specific permission error:

  • Incorrect File/Directory Permissions: This is the most frequent cause. A file might be owned by root and only have read access for other users, but your script needs to write to it. Or a directory might lack the 'execute' permission, preventing listing its contents or creating files within it.
  • Incorrect File/Directory Ownership: The file or directory is owned by a different user or group than the one running your Python script. While permissions can grant access to non-owners, direct ownership often simplifies things.
  • Running as the Wrong User: Your Python script might be designed to run as user appuser, but it's inadvertently being run by www-data (common in web servers) or even root (which can cause other issues, ironically by creating files with root ownership that other users can't touch).
  • Parent Directory Permissions: You might have write permissions to a specific file, but not to the directory containing it, preventing creation of new files there. Similarly, if you're trying to list contents of a directory, you need execute permissions on that directory.
  • File Already Open/Locked: Less common for Errno 13 but possible. Another process might have an exclusive lock on the file, preventing your script from accessing it.
  • SELinux/AppArmor Restrictions: On some Linux distributions (like RHEL/CentOS with SELinux or Ubuntu with AppArmor), security modules provide an additional layer of mandatory access control. Even if standard chmod permissions look fine, SELinux might be denying access based on its policies.
  • Network File System (NFS/SMB) Issues: If 'X' is on a mounted network share, the permissions are managed by the remote server, and misconfigurations there can manifest as Permission denied on the client.
  • Trying to Write to System Directories: Attempting to write files directly into /usr/bin, /etc, or /var/log (without specific setup) will almost always result in this error unless running as root.

Step-by-Step Fix

Here's how I typically troubleshoot and fix OSError: [Errno 13] Permission denied.

  1. Identify the Exact Resource ('X'):
    The error message itself provides the crucial piece of information: Permission denied: 'X'. Copy this 'X' (the file or directory path) precisely. If it's a directory and you're trying to create a file, the permission issue might be with the directory itself, not the (non-existent) file.

  2. Determine the User Running the Python Script:
    This is paramount. In a terminal, you can check your current user with:
    bash whoami
    If your script is part of a service (e.g., systemd, Gunicorn, Apache), check its configuration file for User= or ExecUser= directives. If it's a Docker container, you need to know the USER specified in the Dockerfile or docker run command.

  3. Check Permissions and Ownership of 'X':
    Use ls -l on the identified resource.
    bash ls -l /path/to/X
    Example output:
    -rw-r--r-- 1 root root 1234 May 15 10:30 /path/to/X drwxr-xr-x 2 appusr appgrp 4096 May 15 09:00 /path/to/directory

    • The first character (- or d) indicates file or directory.
    • The next nine characters are permissions (user, group, others).
    • root root or appusr appgrp are the owner and group.

    Compare these permissions with what your script needs and who is running it.
    * Read (r): Needed to open and read a file.
    * Write (w): Needed to modify or delete a file, or to create new files in a directory.
    * Execute (x): Needed to run a script, or to enter and list the contents of a directory.

  4. Adjust Permissions or Ownership (if necessary):
    Once you understand the required permissions, you have options:

    • Change Ownership (chown): If the file/directory should truly belong to the user running the script. Use sudo if you're not the current owner.
      bash sudo chown youruser:yourgroup /path/to/X
      Replace youruser and yourgroup with the user/group running your script.

    • Change Permissions (chmod): This is often the safest approach if ownership is correct but permissions are too restrictive.

      • Grant write to owner: chmod u+w /path/to/X
      • Grant write to group: chmod g+w /path/to/X
      • Grant write to others (use with caution!): chmod o+w /path/to/X
      • Recursive for directories (-R): Be very careful with this. chmod -R appuser:appgroup /path/to/directory

      A common good practice for directories where your app creates files is 775 (rwxrwxr-x):
      bash sudo chmod 775 /path/to/directory
      And for files 664 (rw-rw-r--):
      bash sudo chmod 664 /path/to/file
      Never use chmod 777 (rwxrwxrwx) in production without understanding the significant security implications. It makes the resource writable by anyone on the system. I've only used it for quick local testing and immediately reverted it.

  5. Check Parent Directory Permissions:
    If your script is trying to create a new file, the permission issue isn't with the file itself (since it doesn't exist yet), but with the parent directory where the file would be created. Ensure the user running your script has write (w) and execute (x) permissions on that parent directory.
    bash ls -ld /path/to/parent/directory
    Look for w and x for the appropriate user/group/other.

  6. Check for SELinux/AppArmor (Linux specific):
    If standard permissions look fine but the error persists, check these security modules.

    • SELinux:
      bash sestatus # Check if SELinux is enforcing sudo setenforce 0 # Temporarily set to permissive (DANGER: do not do this in prod!) audit2allow # Tool to generate policy rules
      In my experience, audit.log is where you'll find the specific denials.
    • AppArmor:
      bash aa-status # Check status
      Check /var/log/syslog or dmesg for AppArmor denial messages.

  7. Restart the Service/Application:
    After making any permission changes, it's often necessary to restart the application or service running your Python script for the changes to take effect. This ensures the process picks up the new environment and permissions.

Code Examples

Here are some Python snippets related to permissions:

  1. Demonstrating PermissionError (Python 3.3+):
    This script will likely fail if you try to run it on a protected system path.

    ```python
    import os

    Attempt to create a file in a common system directory

    This path will almost certainly require root permissions to write to

    protected_path = "/usr/local/bin/my_app_test_file.txt"

    try:
    with open(protected_path, "w") as f:
    f.write("This is a test.")
    print(f"Successfully wrote to {protected_path}")
    except PermissionError as e:
    print(f"Error: {e}")
    print(f"Failed to write to {protected_path}. Check permissions.")
    except Exception as e:
    print(f"An unexpected error occurred: {e}")
    ```

  2. Checking Writable Permissions Before Writing:
    A robust script should always check if a path is accessible before attempting an operation.

    ```python
    import os

    target_directory = "/tmp/my_app_data"
    target_file = os.path.join(target_directory, "output.log")

    Create directory if it doesn't exist

    if not os.path.exists(target_directory):
    try:
    os.makedirs(target_directory, exist_ok=True)
    print(f"Created directory: {target_directory}")
    except PermissionError:
    print(f"Error: Permission denied when trying to create directory {target_directory}. Exiting.")
    exit(1)
    except OSError as e:
    print(f"Error creating directory {target_directory}: {e}. Exiting.")
    exit(1)

    Check if the directory is writable by the current user

    R_OK for read, W_OK for write, X_OK for execute

    if os.access(target_directory, os.W_OK | os.X_OK):
    print(f"Directory {target_directory} is writable and executable.")
    try:
    with open(target_file, "a") as f: # "a" for append
    f.write("Log entry: Script ran successfully.\n")
    print(f"Successfully appended to {target_file}")
    except PermissionError as e:
    print(f"Error: {e}")
    print(f"Failed to write to {target_file} despite directory being writable. Check file permissions or locks.")
    except Exception as e:
    print(f"An unexpected error occurred while writing to file: {e}")
    else:
    print(f"Error: Directory {target_directory} is not writable or executable by the current user.")
    print("Please check directory permissions.")
    ```

Environment-Specific Notes

Permission issues are exacerbated in complex environments.

  • Cloud (AWS, Azure, GCP):

    • AWS S3: This isn't a traditional filesystem, but you'll encounter similar "permission denied" errors. The fix lies in S3 bucket policies, IAM user/role policies, and potentially object ACLs. Ensure your EC2 instance's IAM role has s3:PutObject, s3:GetObject, etc., for the specific bucket and path.
    • AWS EFS/EBS: If your Python app writes to an attached EBS volume or an EFS mount, standard Linux chown/chmod rules apply. EFS specifically often needs careful configuration of its mount targets and security groups. I've spent hours debugging EFS permissions where the EC2 instance's user couldn't write to the mounted volume due to incorrect NFS export options or local user/group mapping.
    • Cloud Storage APIs: When using Python SDKs for cloud storage (e.g., Google Cloud Storage, Azure Blob Storage), "permission denied" typically means your service account or API key lacks the necessary permissions on the cloud resource itself, not the local filesystem.

  • Docker/Containers:
    This is a very common source of Errno 13.

    • User within Container: By default, processes in Docker containers often run as root. However, many best practices recommend running applications as a non-root user within the container for security. If your Dockerfile sets a USER directive, ensure that user has permissions for the directories your Python app uses.
    • Volume Mounts: When you mount a host directory into a container (-v /host/path:/container/path), the permissions on /host/path are critical. The user inside the container must have appropriate permissions on the host filesystem's mounted path. If appuser inside the container tries to write to /container/path which maps to /host/path owned by root:root with 755 permissions, you'll get Permission denied. A common fix is to ensure the UID/GID of the user inside the container matches a user/group on the host that has access to the mounted volume, or simply chown the host directory to the container's user.
    • Image Layers: Files created during docker build (e.g., RUN commands) inherit permissions from the user running that build step. If subsequent steps, or the final runtime user, change, you might hit permission issues.

  • Local Development:
    Often the simplest. If you get Permission denied on your local machine, it's usually a straightforward case of:

    • Attempting to write to system directories (/usr, /var, /etc).
    • Downloading a file that ended up owned by root (e.g., from sudo pip install), then trying to modify it as your regular user.
    • Trying to write to a directory owned by another user or created by sudo previously.
      Simply using sudo for chown or chmod on the affected files/directories (or running the script itself with sudo for testing, though generally not recommended for development processes) will often resolve it.

Frequently Asked Questions

Q: Why does my script work when I run it with sudo python script.py but not with python script.py?
A: Running with sudo temporarily elevates your script's privileges to that of the root user. root has ultimate control over the filesystem and bypasses most standard permission checks. This confirms your problem is indeed a permission issue related to the user your script normally runs as. However, running applications as root is a security risk and generally not recommended for production.

Q: Is chmod 777 always a good idea to fix this error?
A: No, absolutely not. While chmod 777 will grant read, write, and execute permissions to everyone (owner, group, and all other users), it's a significant security vulnerability. Any other process or user on the system could then read, modify, or delete your files, potentially leading to data corruption or security breaches. Use it only for very temporary debugging on non-sensitive files, and revert immediately. Prefer chmod 775 or chmod 664 and adjust ownership with chown if needed.

Q: How can I debug this error in a production environment where I can't just sudo or change ownership easily?
A: In production, you typically need to coordinate with a system administrator.
1. Check logs: Review your application logs, system logs (syslog, journalctl), and potentially audit logs (e.g., audit.log for SELinux) for more context.
2. Identify process user: Determine exactly which user account the service is running under.
3. Inspect target paths: Use ls -l on the specific file or directory (and its parent) identified in the error to inspect permissions.
4. Least privilege: Request minimal, specific permission changes from your administrator, like adding the service user to a specific group or granting specific chmod flags.

Q: What if the file 'X' in the error message doesn't exist yet?
A: If your script is trying to create a new file, the Permission denied error will point to the directory where the file was supposed to be created, not the non-existent file itself. The issue is that the user running the script lacks the necessary write and execute permissions for that parent directory.

Q: What's the difference between OSError and PermissionError in Python?
A: PermissionError is a specific subclass of OSError that was introduced in Python 3.3. It's raised when an operation is attempted on an object (like a file or directory) that is explicitly denied by the operating system due to insufficient permissions. While OSError is a broader error for OS-related issues, PermissionError is more precise for this specific scenario. Catching PermissionError directly is generally better practice for specific permission issues.