Fix 'Operation not permitted' chmod error on Linux

Quick answer for advanced users

If you're root and still getting 'Operation not permitted', check for the immutable flag with lsattr, then remove it with chattr -i, or check if the filesystem is mounted with noexec, nodev, or nosuid.

I've seen this error countless times. It's frustrating because the message is generic—it could mean ten different things. The most common cause is that you're not the file owner, but there's a handful of other sneaky reasons that trip people up. Let's walk through each one, starting with the quickest checks.

Why you're seeing this error

Linux protects files in layers. The first layer is standard permissions—read, write, execute. Above that sits ownership, which only lets the owner or root change permissions. Then there's the filesystem's own rules, like mount options and extended attributes. When any of these layers block you, the kernel returns EPERM (Operation not permitted) or EACCES (Permission denied). The error alone doesn't tell you which layer failed, so you have to test each one.

Here's a real-world example: you're trying to make a script executable in /mnt/usb, but it's mounted with noexec. No amount of chmod will help because the kernel ignores execute bits on that filesystem. Or maybe you're on a multi-user server and someone set the immutable attribute to prevent accidental deletion. Both give you the same cryptic message.

Fix steps: check ownership first

1. Check who owns the file. Run ls -l filename. Look at the third column. That's the owner. If it's not your user and you're not root, that's your problem. You can't chmod a file you don't own—unless you have sudo.
2. Try with sudo. If you have sudo access, run sudo chmod 755 filename. If that works, you were just missing privileges. If it still fails, move to step 3.
3. Check the immutable flag. Run lsattr filename. You'll see a bunch of letters like e, i, a. The i means immutable—even root can't change it without removing the flag first. Remove it with sudo chattr -i filename then retry chmod.
4. Check the filesystem mount options. Run mount | grep /path/to/mount. Look for noexec, nosuid, nodev, or ro (read-only). If you see any of those, you can't set execute bits or change permissions there. You'll need to remount it with the right options.

What to expect after each step

After running ls -l, you'll see the owner. If it's not you, you'll know why. After running sudo chmod, you should either see no output (success) or the same error. If you still see the error, the immutable flag is a likely culprit. When you run lsattr, you'll see ----i--------e---- for an immutable file. After chattr -i, running lsattr again should show the i gone.

Alternative fixes if the main ones fail

Prevention tip

Get into the habit of checking mount options before you put files on external drives. If you're on a shared system, use chattr +i only when you really need to protect a file—remember it can bite you later. And always use sudo -l to see what commands you can run without a password. That saves you from being locked out of your own files.

The real fix is knowing which layer is blocking you. Most of the time it's ownership—you just need sudo. But when sudo doesn't solve it, look at the flags and mounts. I've seen people waste hours reinstalling packages when all they needed was chattr -i.