chmod: changing permissions of 'file': Operation not permitted means the kernel refused the call outright — this is not the same as a permission bit failing you. In order of likelihood: you don’t own the file, an immutable flag is set, the filesystem is mounted read-only, root is being squashed over NFS, or a security layer (SIP, a container’s read-only layer) is in the way. Permissions never enter into it — chmod is asking for authority, and something above the bits is answering no.

The five real causes, in diagnosis order

Symptom check	Cause	Fix
ls -l file shows another owner	Only the owner (or root) may chmod	sudo chmod … or sudo chown you: file
lsattr file shows i (Linux)	immutable flag — even root is refused	sudo chattr -i file
ls -lO file shows uchg (macOS)	BSD user-immutable flag	sudo chflags nouchg file
findmnt -T . / mount shows ro	filesystem mounted read-only	remount rw; investigate why it flipped (disk errors auto-remount ro)
works as user, fails as sudo on NFS	root squashed to nobody	chmod from the server, or as the owner

Two platform extras: on macOS, paths under /System, /bin, /usr (except /usr/local) are protected by SIP — no amount of sudo helps, and the fix is “don’t chmod system paths”. In containers, the file may sit on a read-only image layer — copy it out or fix the image. And on FAT32/exFAT/NTFS mounts there are no Unix bits to change; the call fails or is ignored and mount options set the effective mode instead.

EPERM vs EACCES — which error you got matters

$ chmod 644 /etc/shadow
chmod: changing permissions of '/etc/shadow': Operation not permitted   ← EPERM: not the owner

$ ./deploy.sh
bash: ./deploy.sh: Permission denied                                     ← EACCES: missing x bit — chmod +x fixes this

Mixing them up sends people chasing the wrong fix: sudo cures EPERM-from-ownership but can’t cure immutability; chmod +x cures EACCES-on-exec but does nothing for a file you don’t own.

The 30-second diagnosis

ls -l file          # who owns it? (not you → sudo/chown)
lsattr file         # 'i' flag?      (Linux; macOS: ls -lO for uchg)
findmnt -T .        # filesystem mounted ro?
stat -f file        # macOS/BSD alternative flag view

Whatever the fix, when the mode finally does change, verify it did what you meant — paste the octal or ls -l string into the calculator — and if the file is inside a directory tree you’re re-permissioning, the recursive traps article covers what -R will flatten along the way.

Frequently asked questions

Why does chmod say Operation not permitted even with sudo?

Then it isn't ownership. The remaining causes: an immutable flag (chattr +i on Linux — check with lsattr file, remove with chattr -i; uchg on macOS — check with ls -lO, remove with chflags nouchg), a filesystem mounted read-only, or macOS SIP protecting system paths. sudo can't override any of those — you must remove the flag, remount rw, or work somewhere unprotected.

What's the difference between Operation not permitted and Permission denied?

Operation not permitted (EPERM) means the operation itself is refused — you don't own the file, it's flagged immutable, or the filesystem/security policy forbids it. Permission denied (EACCES) means the permission bits decided against you — e.g. executing a file with no x bit, or entering a directory you can't traverse. Roughly: EPERM = "you may not change this", EACCES = "you may not do this".

chmod fails on files copied to a USB stick — why?

FAT32/exFAT/NTFS have no Unix permission bits, so there's nothing for chmod to change — Linux either fails the call or silently ignores it depending on the mount. The whole filesystem gets its 'permissions' from mount options like umask=, fmask=/dmask=. Copy the file to a Linux filesystem, chmod it there, or fix the mount options.

Can I chmod a file owned by another user if I'm in their group?

No — group membership grants whatever the bits allow for using the file, but changing the mode requires being the owner (or root). Even a group-writable file can't be chmod'ed by a group member. Ask the owner, or use sudo/sudo chown if you administer the box.

Why can't I chmod a symlink?

chmod on a symlink path actually changes the target's mode — symlink permissions themselves are meaningless (ls shows lrwxrwxrwx always). If the target doesn't exist or you don't own it, that's your error. On Linux, chmod -h/the fchmodat AT_SYMLINK_NOFOLLOW path can't change symlink bits anyway — there are none to change.