0

i wanted to change the ownership of one specific folder and I think I messed it up. I run following command:

sudo chown -R ubuntu /

(I was thinking it will only change the folder I was located in)

The last output lines were:

chown: changing ownership of '/proc/2330478/task/2330478': Operation not permitted
chown: changing ownership of '/proc/2330478': Operation not permitted

Is there anything I can do to undo? Or anything to minimize the mess?

(the farce is that i was in the process of implementing a backup mechanism) I wanted to change the ownership of one specific folder to upload a backup script into it via win_scp. So at the moment I'm in panic. BR

Marcelo
  • 3,561
jjx
  • 9
  • Hi @roaima, the farce is that i was in the process of implementing a backup mechanism) I wanted to change the ownership of one specific folder to upload a backup script into it via win_scp. So at the moment I'm in panic. – jjx Jul 28 '23 at 20:41
  • if it's rpm based then it may be possible to recover but I assume your distro is ubuntu or confirm which distro it is – csx4 Jul 28 '23 at 21:21
  • 2
    Linux uses a complex scheme of users and group file ownership (at least 14) to perform "separation of privilege" and "separation of access". By your changing all these ownerships to a single user you have destroyed inforrmation. You could manually change the groups back, fix the missing SUID and SGID bits, etc. (once you figure out what they should be), but a reinstall will be quicker. Much quicker. You should also read man chown before you sudo chown. – waltinator Jul 28 '23 at 21:51
  • 1
    Thank you all for your fast responses. I admit I have to reinstall everything. I'm trying to rescue some files, but even that seems to be challanging as WinSCP isn't working anymore now :-( . I wrote another question regarding this issue. https://unix.stackexchange.com/questions/752692/trying-to-transfer-files-from-my-ubuntu-server-running-in-oracle-cloud-to-my-w – jjx Jul 28 '23 at 22:44
  • If /home is a seperate disk partition, you can tell the installer to put /home on the same partition, AND Uncheck the "Format" checkbox. Do NOT format /home. Otherwise, buy a big USB key, reformat to ext4 (boot your install disk in "Try Ubuntu" mode, or download a Live USB, and try to copy all of $USER's files, plus any application data you want to keep to the big USB key. Then, plan your reinstall, do your reinstall, reinstall your other applications, them copy stuff from the big USB key to your shiny, new system. Be prepared to struggle to get everything to integrate/work. – waltinator Jul 29 '23 at 03:25

2 Answers2

0

The command you ran is changing permissions on entire system from / .

I am sorry to say unless you have backups you have to reinstall the whole system.

Hoodad Tabibi
  • 335
0

Despite other answers (or comments) say you are doomed, there is a good chance you can recover your system if you are able to boot from an external device. It will actually depend on some factors like if your installed system is encrypted, if your system is configured to allow external drives boot and similar issues. If this isn't the case, although this will be cumbersome and require hard work, you still have hope.

I use to have a couple of recovery functional bootable USB drives around, but even if you don't have one, you can create or even download a bootable Linux image from the internet (recommend a reliable source like your Linux distribution official home page).

At this point, after booting with the external drive, you can mount your internal "damaged" root system on /tmp/myroot:

# mkdir /tmp/myroot

# mount /dev/[whatever device is your internal root] /tmp/myroot

Then you should be able to chown the most important executables on /tmp/myroot/bin and /tmp/myroot/usr/bin. This will be a somewhat long list, but you would need at least /tmp/myroot/bin/sh, /tmp/myroot/bin/login, /tmp/myroot/bin/rpm, /tmp/myroot/bin/chown itself and probably a few others. The lazy approach is to temporarily move them and copy your external recovery directories to the internal system being recovered:

# mv /tmp/myroot/bin /tmp/myroot/damaged-bin

# mv /tmp/myroot/usr/bin /tmp/myroot/usr/damaged-usrbin

# cp -a /bin /tmp/myroot/bin

# cp -a /usr/bin /tmp/myroot/usr/bin

This will also involve other changes like recovering the ownership of /var (currently mounted as /tmp/myroot/var) and other directories. Again, the list may be long.

After doing this, you will have a minimally bootable system (as single user) and, after booting again, considering you are using a rpm based distribution, you can use rpm --setugids -a to recover all system files ownerships (you will have to manually set the ownership of files on your home, etc...).

This answer is intended to provide the general idea of an approach that should work to recover your system. All the detailed steps probably require more directories and files to be adjusted before being able to boot the internal system in single user mode.

PS: Recovering from a backup would certainly be the best approach, and this is lessons learned. Even after recovering it manually, this will be like a refurbished car, it will never be the same...

Wish you good luck!

Marcelo
  • 3,561