35

I try to chown the owner of a file to root, but I can't. I'm doing this as root. I get the following message:

chown: changing ownership of `ps': Operation not permitted
Improve this question
1
  • An ls -lha and lsattr output would aid the solution :)
    – drAlberT
    Aug 31, 2009 at 10:15

8 Answers 8

Reset to default
65

The immutable attribute might be set on the file. Remove it with

chattr -i <file>
Improve this answer
6
  • 12
    It was -a. But thanks for the nod in the right direction.
    – Peter Stuifzand
    Aug 31, 2009 at 10:14
  • Thank you, How can I set immutable attribute on it again?
    – Zim3r
    Dec 6, 2012 at 17:24
  • chattr +i <file>
    – Cian
    Dec 23, 2012 at 21:09
  • 3
    chattr: Inappropriate ioctl for device while reading flags on
    – andilabs
    Jun 7, 2019 at 8:37
  • again not permitted!
    – Ario
    May 9, 2021 at 7:51
14

Several solution exists, some among them:

  • you have a filesystem does not lets you eg. uid:gid, eg: FAT
  • the drive has been mounted read-only
  • SELinux or other security enforcers apply
  • filesystem is set to read-only mode (xfs_freeze, for example)
  • file has the immutable flag set (man chattr)
Improve this answer
2
  • Filesystem is ext3, mounted read-write, No SELinux.
    – Peter Stuifzand
    Aug 31, 2009 at 10:05
  • It's also possible that the file is on an NFS file system, mounted root_squash, albeit unlikely given the file.
    – Cian
    Aug 31, 2009 at 10:06
5

I had same problem.

$ chattr -V -i dir
chattr 1.41.12 (17-May-2010)
Flags of dir set as s----a---------

Which was not enough. So i added the 'sa'

$ chattr -V -ais dir
chattr 1.41.12 (17-May-2010)
Flags of dir set as ---------------
$ chown root dir
$

Problem solved :)

Improve this answer
1
  • $ chattr -V -i ./nextcloud/ chattr 1.46.2 (28-Feb-2021) chattr: Operation not supported while reading flags on ./nextcloud/ didn't work :(
    – n1cK
    May 3, 2022 at 9:47
3

Funny. Did you check the system logs (/var/log/messages, /var/log/syslog, output of dmesg) for any clues?

Possible reasons:

  • You are running some security-enhanced Linux, such as SELinux. These place restrictions even on what root can do.
  • The file is on a file system that does not support file ownership, such as (V)FAT. Depending on mount options chmod/chown will give you errors.
Improve this answer
3

Try this:

[root@ root]# chattr -ais /bin/ls

after changing the ownership and group back to root.

Improve this answer
2

Every "guess" made by other answers is possible. A debugging hint may be to do a strace of the command, and look into the output in order to see what is the real problem in the syscalls themselves.

strace chown root /bin/ps 2>&1 | less
Improve this answer
1
  • 1
    I declare you my best friend for the next 3 days. Cheers. Now I know what to google other than "What could deny access to the root user"
    – timuçin
    Apr 16, 2023 at 11:31
1

I had the same problem with a directory, though the problem was that the folder was hosted on an NFS server with root_squash enabled. In that case, if you have root access to the NFS server, just run chown from there.

If you have the same problem but don't have root on the NFS server (only on the client), then (if you are responsible and know what you are doing) an alternative would be to become the user that owns the local folder (sudo su user.name) on the client and then run chown. (Note: becoming the local user might be overstepping your boundary as an admin though so make sure you know what you are doing).

Improve this answer
1
  • nfs was key for me. Logged in as root on one server, I could not chown, write files, replace files etc. in nfs-provided home directories. But when I logged onto the server that physically hosts those home directories, all of those file operations worked normally.
    – MiloNC
    Aug 18, 2022 at 19:49
0

on what kind of Filesystem is the "ps" file you are trying to chown ? Is the fs mounted as ro (readonly) ?

if you are talking about /bin/ps, on debian it's always like:

-rwxr-xr-x 1 root root 76132 2009-05-28 10:48 /bin/ps*
Improve this answer
3
  • The problem is my system was hacked and some files were replaced. Now I want to replace them with the originals but I doesn't work.
    – Peter Stuifzand
    Aug 31, 2009 at 10:03
  • 9
    If your system was hacked, then you don't want to put files back. You have no way of telling what's been broken, and nothing on the system is trustworthy. Wipe, and reinstall from backups.
    – Cian
    Aug 31, 2009 at 10:07
  • 1
    As Cian said, if your system was hacked and they got root access, don't replace files. It may still contain a (nearly) invisible rootkit that hijacks system calls. It may still be sniffing passwords, it may still have opened backdoors in your services, and and and (infinite number of possible things a hacked machine may contain). The reasonable thing to do is to turn off the machine and study its contents offline, by putting the disk to another box. Don't trust this machine at all and don't replace any binaries, they may contain valuable information to discover what the rootkit does.
    – kargig
    Aug 31, 2009 at 11:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .