Bash error: "Operation not permitted"

"Operation not permitted" means the OS refused the syscall, not just file permissions. Learn how it differs from "Permission denied" and how to fix it.

Error String

bash: /dev/xxx: Operation not permitted

Tldr

"Operation not permitted" is EPERM: the kernel rejected the operation because it requires a capability you do not have (root, CAP_SYS_ADMIN, immutable-file flag, etc.), not merely file mode bits. Re-run as root, drop the immutable attribute, or check container/security policy restrictions.

Cause

This differs from "Permission denied" (EACCES), which is about file mode bits and ownership. EPERM shows up when you try to kill a process you do not own, change ownership of a file you do not own, write to a file with the immutable attribute set (chattr +i), or perform an operation blocked by seccomp/AppArmor/SELinux inside a container. Docker and other sandboxes commonly surface this for operations like changing system time or mounting filesystems.

Repro

#!/usr/bin/env bash
set -euo pipefail

chattr +i notes.txt   # mark immutable (needs root once)
echo "more" >> notes.txt   # bash: notes.txt: Operation not permitted

Fix

#!/usr/bin/env bash
set -euo pipefail

# Check for the immutable attribute first
lsattr notes.txt

# Remove it, then the write succeeds
sudo chattr -i notes.txt
echo "more" >> notes.txt

# For process signals you don't own, use sudo or the right user
sudo kill -TERM 1234

Explanation

When you see "Operation not permitted" ask: does this require a capability, not just file access? Common fixes are running as root/sudo, using `chattr -i` to clear the immutable flag, or checking `dmesg`/audit logs for SELinux/AppArmor denials. In Docker, add the specific capability with --cap-add instead of running --privileged.

Faq

Q

How is this different from "Permission denied"?

A

"Permission denied" (EACCES) means the file mode/ownership disallows the action. "Operation not permitted" (EPERM) means the kernel requires a privilege or capability that even file owners do not automatically have, such as changing another user's process or an immutable file.

Q

Why does chmod fix "Permission denied" but not this?

A

chmod changes file mode bits, which only affects EACCES checks. If the real blocker is an immutable attribute or a missing capability, chmod has no effect — check `lsattr` and your container security policy instead.

Q

Does running as root always fix it?

A

Usually, but not always. Inside a container with seccomp or AppArmor profiles, even root can be denied certain syscalls. Check `dmesg` or `journalctl -k` for the specific denial.