You've encountered one of Linux's more counterintuitive permission scenarios: being root yet unable to change ownership to root. The error chown: changing ownership of ps': Operation not permitted typically occurs when dealing with special files or filesystems with additional protection layers.

Several conditions can cause this:

• Immutable files (chattr +i)
• NFS or special mounted filesystems
• SELinux/AppArmor restrictions
• Files with capabilities set
• Read-only filesystems

First, check file attributes:

lsattr /path/to/file
stat /path/to/file

For SELinux contexts:

ls -Z /path/to/file
getenforce

For immutable files:

chattr -i /path/to/file
chown root:root /path/to/file

For NFS mounts, check export options on server side. For SELinux:

restorecon -v /path/to/file
setenforce 0 # temporary disable for testing

When dealing with special system files like /proc entries:

# This won't work on most /proc files
echo "Try modifying the source process instead"

For files with capabilities:

setcap -r /path/to/file # remove capabilities first

To avoid similar issues:

• Document filesystem mount options
• Audit SELinux policies regularly
• Implement proper attribute management in deployment scripts

---

It's counterintuitive when the root user encounters permission issues, since root typically has unrestricted system access. The error message:

chown: changing ownership of ps': Operation not permitted

indicates deeper system-level restrictions at play, even for the superuser.

This typically happens with:

• Immutable files (enabled through file attributes)
• Files on read-only filesystems
• Files protected by Security-Enhanced Linux (SELinux)
• Files on mounted filesystems with specific mount options
• System binaries protected by package managers

First examine extended attributes:

lsattr /path/to/file

If you see i (immutable) or a (append-only) flags, these prevent ownership changes:

----i--------- /bin/ps

To remove immutable flag (as root):

chattr -i /bin/ps

On SELinux-enabled systems (common in RHEL, CentOS):

ls -Z /bin/ps

Output might show special contexts like:

system_u:object_r:bin_t:s0 /bin/ps

To temporarily allow changes (security implications noted below):

chcon -t unconfined_exec_t /bin/ps

Check mount options for the containing filesystem:

mount | grep 'on / '

If you see ro (read-only) or nochown, remount with write permissions:

mount -o remount,rw /

Many system binaries are protected by the package manager. For RPM-based systems:

rpm -qf /bin/ps
rpm --setperms procps-ng
rpm --setugids procps-ng

Instead of changing ownership, consider:

1. Using capabilities for specific privileges:

setcap cap_net_raw+ep /bin/ping

2. Creating symlinks from a writable location:

ln -s /bin/ps /usr/local/bin/custom_ps
chown user:group /usr/local/bin/custom_ps

Modifying system binary permissions can:

• Create security vulnerabilities
• Trigger package verification failures
• Cause issues during system updates
• Violate compliance requirements

Always document changes and consider whether ownership modification is truly necessary versus alternative approaches.