Operation not permitted

Cannot change file owner: operation not permitted in Linux

You get 'operation not permitted' when using chown on a file you own. This guide walks you through fixes from quick to deep.

Quick Fix (30 seconds): Use sudo

This is the most common reason. You need root privileges to change file ownership, even if you own the file. That catches a lot of people.

If you run chown user:group file and see "operation not permitted," try adding sudo before the command:

sudo chown user:group file

After running, check with ls -l file. You should now see the new owner. Works on Ubuntu 22.04, Rocky Linux 9, and most distros.

Moderate Fix (5 minutes): Check file attributes and filesystem

If sudo didn't help, something else is blocking the change.

1. Check for immutable attribute

The file might have the immutable attribute set. That prevents any changes, including ownership. Run:

lsattr file

If you see an i in the output, the file is immutable. To remove it:

sudo chattr -i file

Now try sudo chown again. After you're done, you can re-add the attribute with sudo chattr +i file if needed.

Real-world trigger: This happens often with config files in /etc that sysadmins locked down. I've seen it with /etc/resolv.conf on hardened servers.

2. Check filesystem mount options

Some filesystems mount with the noexec or nosuid options, but the one that blocks chown is noacl or user_xattr. More commonly, NFS mounts refuse chown from client side unless you have root squashing disabled.

Run:

mount | grep /path/to/mountpoint

Look for noacl or nouser_xattr in the options. On an NFS mount, you'll see type nfs. NFS servers often squash root access by default. To fix that, you need to edit /etc/exports on the NFS server and add no_root_squash:

/exported/dir client_ip(rw,no_root_squash,sync)

Then restart NFS services on the server. After that, sudo chown should work from the client.

Advanced Fix (15+ minutes): Extended attributes, ACLs, and kernel restrictions

If the first two fixes didn't work, you're dealing with something deeper.

1. Check ACLs

ACLs (Access Control Lists) can override normal ownership. Run:

getfacl file

If you see entries like user:someone:rwx but no owner write permission, ACLs may block chown. Remove them with:

sudo setfacl -b file

Then try chown again.

Real-world trigger: I've seen this on shared directories in academic labs where ACLs were set by an admin, then a user tried to change ownership on a file they created inside.

2. Check for Linux Security Modules (SELinux/AppArmor)

SELinux can block chown even for root. Check SELinux status:

getenforce

If it says Enforcing, check the audit log:

sudo ausearch -m AVC -ts recent | grep chown

Or look at /var/log/audit/audit.log. If you see denials, you can either set SELinux to permissive temporarily to test:

sudo setenforce 0

Then try chown. If it works, you need to either adjust the SELinux policy or fix the file context. Re-enable SELinux with sudo setenforce 1 after testing.

For AppArmor, check sudo aa-status and look for profiles that might block file operations. This is rarer but happens on Ubuntu with snap packages.

3. Check kernel capabilities

Modern filesystems like ext4, XFS, and Btrfs support capabilities. A file might have CAP_FOWNER or CAP_CHOWN set in ways that confuse things. You can check with getcap:

getcap file

If you see something like = cap_fowner+eip, that can interfere. Remove with:

sudo setcap -r file

4. Last resort: Reboot into recovery mode

If nothing works, the file may be on a read-only filesystem or have hardware issues. Reboot into single-user mode:

sudo reboot

At the GRUB menu, press e, find the line starting with linux, add single or 1 at the end, press Ctrl+X to boot. Then you're as root and can run chown freely.

If it works there but not in normal mode, you have a systemd service or init script locking the file. Check systemctl list-units | grep file or look at /etc/init.d/ scripts that watch the file.

Quick recap

  1. Try sudo first. That fixes 90% of cases.
  2. Check immutable attribute with lsattr.
  3. Check if it's an NFS mount or other network filesystem.
  4. Check ACLs and SELinux if you're on a security-focused distro.
  5. Reboot into single-user mode as a nuclear option.

I've walked dozens of techs through this. The immutable attribute catches people more than you'd think. And NFS root squashing is almost always the culprit on shared storage.

Related Errors in Linux & Unix
Linux OOM Killer: When Your App Gets Murdered by the Kernel Fix 'permission denied' on Linux scripts & files Fix SSH Permission Denied with Public Key Authentication Fix Nginx Redirect Delay: Stops Waiting 5-10 Seconds

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.