Linux 'Operation Not Permitted' When Copying System Files

When This Error Pops Up

You're running cp /etc/shadow /backup/shadow.bak and BAM — cp: cannot open '/etc/shadow' for reading: Operation not permitted. Or maybe you're trying to copy logs like /var/log/secure or a config file like /etc/passwd. Same error.

This isn't a permissions thing — you might be root and still get it. I've seen this on RHEL 9, Ubuntu 22.04, and even older CentOS 7 boxes. It's frustrating because ls -l shows you own the file, but cp still fails.

Root Cause: File Attributes or SELinux

There are two main culprits:

• Immutable file attribute — Some system files have the i attribute set. This makes them read-only even for root. The chattr command controls this.
• SELinux context blocking — On SELinux-enabled systems, copying a file can lose its security context. If the destination has a different context, the copy fails.

Had a client last month whose whole log rotation broke because /var/log/secure had the i attribute set from a security script. Took me 10 minutes to find it. So check attributes first.

Step-by-Step Fix

Step 1: Check File Attributes

Run this on the file that's giving you trouble:

lsattr /etc/shadow

You'll see something like ----i--------- /etc/shadow. That i means immutable — you can't even read it for copying.

If you see a (append only) or d (no dump), those can also block copies. But i is the most common.

Step 2: Remove the Immutable Attribute (If You Need To)

Be careful — this is a system file. Only do this if you're sure you need to copy it. Use:

chattr -i /etc/shadow

Then copy the file. After the copy, set the attribute back:

chattr +i /etc/shadow

Skip this if you're just copying logs or non-critical files. For logs, removing the attribute won't break anything.

Step 3: Check SELinux Context

If attributes are clean, check SELinux:

ls -Z /etc/shadow

You'll see something like system_u:object_r:shadow_t:s0. That's the context.

When copying, the destination directory might not allow that context. Check the destination with:

ls -Z /backup/

If the directory has a different type (like default_t), SELinux may block the copy. The fix is to preserve context during copy:

cp -a /etc/shadow /backup/shadow.bak

The -a flag preserves attributes and SELinux context. If that still fails, temporarily set SELinux to permissive:

setenforce 0
cp -a /etc/shadow /backup/shadow.bak
setenforce 1

But don't keep SELinux off — that's asking for trouble.

Step 4: Use Rsync as a Workaround

Sometimes cp just won't work for certain system files. Try rsync instead:

rsync -avX /etc/shadow /backup/shadow.bak

The -X flag preserves extended attributes, including SELinux context. This bypasses most attribute and SELinux issues.

What If It Still Fails?

If you've done all the above and still get the error, check these:

• Filesystem is read-only — Run mount | grep ' / '. If it says ro, remount with mount -o remount,rw /.
• AppArmor blocking — On Ubuntu or Debian, AppArmor might block the read. Check sudo journalctl | grep DENIED for hints.
• File is a special device or proc — If you're trying to copy /proc/ or /sys/ files, those aren't real files. Use cat or dd instead of cp.
• Disk quota or inode limit — Check with df -i on the destination. If inodes are full, you can't create new files.

If none of that works, try copying as a different user — some daemons set file ACLs that block even root. Use getfacl /etc/shadow to check. But that's rare for system files.

One last trick: create a tar archive instead. tar cvf /tmp/shadow.tar /etc/shadow often bypasses attribute checks because tar reads the file through its own layer.

That's it. Check attributes first, then SELinux, then try rsync. 90% of the time, it's the i attribute or SELinux context. Don't waste time on sudo or chmod — that won't fix this.