Python "PermissionError: [Errno 13] Permission Denied" When Writing File

A PermissionError when writing a file means the operating system, not Python itself, is refusing the write — the fix requires identifying whether the issue is file/directory permissions, ownership, or the file being locked by another process, since each requires a different resolution.

The Problem

Writing to a file fails with:

PermissionError: [Errno 13] Permission denied: 'output.txt'

The file or its containing directory might appear to exist normally when checked, which makes the permission denial confusing without directly inspecting the actual permission bits and ownership.

Why It Happens

Errno 13 specifically means the OS-level permission check failed for the requested operation, for one of several common reasons:

• The file exists but is owned by a different user, or has permission bits that don't grant write access to the user your Python script is actually running as
• The containing directory itself doesn't grant write permission to your user, even if you're not directly modifying the directory's own permissions — creating a new file requires write permission on the directory it's being created within
• The file is currently open and locked by another process (common on Windows specifically, where file locking is stricter than on Unix-like systems by default) — a separate program, or even another instance of your own script, having the file open can block a new write attempt entirely
• Attempting to write to a path that's actually a system-protected location, requiring elevated (administrator/root) privileges that your current process doesn't have
• On some systems, security software or a mandatory access control system (like SELinux) enforcing additional restrictions beyond standard Unix permission bits, blocking access even when standard permissions appear to allow it

The Fix

First, check the actual permissions and ownership of both the target file (if it exists) and its containing directory:

import os
print(oct(os.stat('output.txt').st_mode))

Or directly from the command line:

ls -la output.txt
ls -la .  # check the containing directory's permissions too

If the file exists but is owned by a different user or lacks write permission for your user, adjust the permissions (if you have sufficient rights to do so) or ownership:

chmod 644 output.txt
# or, if you own the file but permissions are wrong:
sudo chown your_user:your_group output.txt

If the containing directory itself lacks write permission for your user (necessary even just to create a new file within it), confirm and correct directory permissions specifically, separate from the target file's own permissions:

ls -ld /path/to/directory
chmod 755 /path/to/directory

If you're running the script in a context without permission to write to the intended location at all (a system directory, a location owned by a different user entirely), write to a location your current user genuinely has permission to write to instead — often the safest, most portable fix, rather than attempting to escalate privileges just to satisfy a specific hardcoded path:

import tempfile
import os

output_path = os.path.join(tempfile.gettempdir(), 'output.txt')
with open(output_path, 'w') as f:
    f.write(data)

On Windows specifically, check whether the file is currently open in another application (a text editor, Excel, another running instance of your script) — Windows enforces file locking more strictly than Unix-like systems by default, and a file open elsewhere can produce exactly this permission error even though the underlying file permissions themselves are technically fine:

# Close any application that might have the file open, then retry
# Or, programmatically confirm nothing else has it open before writing

If you genuinely need elevated privileges to write to a specific protected location (rare, and worth reconsidering the actual design if this is a frequent requirement), run the script with appropriate elevated permissions explicitly, rather than the script silently failing partway through unexpected privilege requirements:

# Unix-like systems, if genuinely necessary
sudo python3 script.py

Still Not Working?

If standard Unix permissions and ownership all appear correct but the error persists specifically on a Linux system, check whether SELinux or AppArmor is enforcing additional restrictions beyond standard file permissions — these mandatory access control systems can block access even when conventional ls -la permission bits look entirely correct, and require checking their own separate logs or status tools to diagnose:

sudo dmesg | grep -i denied
sudo journalctl -xe | grep -i avc  # SELinux-specific denial logging

A denial entry appearing here, despite standard permissions looking correct, confirms a mandatory access control system as the actual root cause, requiring its own specific policy adjustment rather than any change to conventional file permission bits.