chmod: Operation Not Permitted (tested)
This error (often searched as 'chmod permission denied') means the current user isn't allowed to change this file's permissions at all — and on Linux, that's a strict rule: only the file's owner or the root user can run chmod on it, no matter what permission bits are currently set.
1. Reproduced: chmod on a file you don't own
ls -la /etc/shadow
-rw-r----- 1 root shadow 1116 Sep 26 14:35 /etc/shadow
chmod 777 /etc/shadow
chmod: changing permissions of '/etc/shadow': Operation not permittedNotice this fails even though the attempted mode (777, wide open) has nothing to do with the problem — chmod checks who you are before it looks at what you're asking for. A non-owner, non-root user can't change a file's mode to anything, including making it more permissive.
2. The same command works instantly on a file you do own
chmod 755 /tmp/chmodtest/notmine.txt
ls -la /tmp/chmodtest/notmine.txt
-rwxr-xr-x 1 jacque jacque 0 Oct 3 05:32 /tmp/chmodtest/notmine.txtSame user, same command, only the file's ownership differs. This confirms the error is purely about ownership, not about the specific mode bits requested or the file's current permissions.
3. The fix: become the owner, or become root
There's no chmod flag or mode number that works around this — the only real fixes are:
- Run it as root (e.g.
sudo chmod ...), if you're authorized to and the system allows it. - Take ownership first, if you're root or otherwise authorized:
chown youruser file && chmod 755 file. - Ask whoever owns it to make the change, if it's not your file and you don't have root access — which is frequently the correct outcome, not just a workaround. A permission boundary that can't be bypassed without root is usually there on purpose.
4. A common trap: "it worked yesterday" after a file got copied or extracted as a different user
A frequent real-world trigger isn't a stranger's file — it's your own project file that ended up owned by someone else without you noticing, commonly because:
- A file was extracted from a tarball/zip or copied with
sudo/as root at some point, silently leaving it root-owned in what otherwise looks like your own project directory. - A Docker bind mount wrote a file as the container's internal user (often root or a numeric UID that doesn't map to your host user), leaving host-side files with foreign ownership.
Check with ls -la before assuming your chmod command itself is wrong — if the owner column isn't your username, that's the actual cause, and no amount of adjusting the mode number will fix it.
5. Is this the same as "Permission denied"?
They're closely related but not identical wording: chmod itself specifically says Operation not permitted (as reproduced above) when the problem is ownership. A plain Permission denied more often shows up on other operations (opening, writing, executing a file) where regular Unix read/write/execute bits — not ownership of the chmod call itself — are what's blocking you. If you're chasing a different "Permission denied" (e.g. "bash: ./script.sh: Permission denied"), that's usually missing execute bit (chmod +x script.sh, which you'd need to actually own the file to run) rather than this ownership-level error.
Frequently asked questions
Why does chmod fail even when I'm trying to make the file MORE open (777)?
We confirmed this directly: chmod checks who's running the command before it looks at the requested mode at all. A non-owner, non-root user can't change the mode bits in either direction, no matter what number is requested.
What actually fixes this — a different chmod flag?
No flag or mode number bypasses it. We tested this: the only real fixes are running as root (sudo), having root change ownership to you first (chown), or asking the actual owner to make the change themselves.
My own project file suddenly has this error — why?
Check its owner with ls -la first. A common real-world cause is the file having been extracted/copied with sudo at some point, or written by a Docker container as a different UID via a bind mount — both silently leave files owned by someone other than your normal user even inside what looks like your own directory.
Is 'Operation not permitted' the same as 'Permission denied'?
They're related but we distinguish them specifically: chmod itself says Operation not permitted for this ownership-level failure. A separate 'Permission denied' (e.g. when running a script) more often means a missing execute bit on a file you do own, which plain chmod +x — something you can run yourself — fixes.
Does this happen on files I created myself?
Only if ownership changed after creation — normally you own files you create and chmod works immediately, which we confirmed (the second reproduction above). If you're seeing this on a file you're sure you created, check ls -la's owner column; it's likely changed via a copy/extract/mount operation that ran as a different user.
Written with AI assistance. Measured on 2026-10-03 on a real Linux system, running chmod against a file the current user doesn't own. Every error message below is copy-pasted output, not paraphrased. PlainHeaders is our extension; these are standard Linux tools.