1

By mistake I ran a stupid command with a typo in it. I created a user "teamspeak" and I wanted to change file owner of current directory and it's sub directories, but by mistake I ran it in the "/".

I was user "teamspeak" while I ran the command, not "root" and I ran something like this:

chown -r teamspeak:teamspeak /*

I seen many lines, the ones I was able to read were that it FAILED to change file owner, progress was around the /lib and maybe /boot when I pressed CTRL+C and stopped it.

But server doesn't become available after a restart (I am 90% sure is the file owner thing).

I am now about to boot it in rescue image mode that my host offers.

I was wondering if there is a way to revert the file permission thing.

AND/OR

A command to search for all files belonging to teamspeak:teamspeak and make them root:root

At least so I boot it properly and fetch all databases from my server.

Improve this question
4
  • possible duplicate of Restore default ownership in CentOS after terrible chown
    – Ignacio Vazquez-Abrams
    Feb 2, 2012 at 10:28
  • Do you have any backups?
    – user
    Feb 2, 2012 at 10:37
  • @Michael no backups so far but I will probably be able to boot from an external image (some rescue mode thing).
    – adrianTNT
    Feb 2, 2012 at 10:54
  • I was thinking less of being able to boot, and more of being able to recover easily. If you'd had a backup, you likely could have extracted the ownership information from there and applied it to your live system, quite likely without even needing to actually restore the backup.
    – user
    Feb 3, 2012 at 10:25

5 Answers 5

Reset to default
2

"A command to search for all files belonging to teamspeak:teamspeak and make them root:root"

Try

find / -user 'teamspeak' | xargs chown root:root
Improve this answer
4
  • Though as pointed out by @Khaled, this almost certainly won't solve the problem. I imagine it could actually make it worse, since anything that is now owned by teamspeak will have its ownership changed to root, which may very well not be the original ownership.
    – user
    Feb 2, 2012 at 10:37
  • For start I will just run the command to check current files owned by the wrong user; Because I seen many "failed to change owner" errors I am hoping there are just a few :D . That command is find / -user 'teamspeak' ?
    – adrianTNT
    Feb 2, 2012 at 11:11
  • To just list them, do find / -user 'teamspeak' -print
    – Safado
    Feb 2, 2012 at 18:02
  • -print is the default behavior with GNU find, but I agree that in cases like this it might be better to be explicit.
    – user
    Feb 3, 2012 at 10:24
1

The problem is that changing the files/folders owner back to root may not solve all your problems as root is not the owner of all files/folders.

I think you have two options:

  1. Re-install the OS if possible.
  2. Go in the tedious task of comparing this with another running system and changing the owner as needed. You can start with changing the owner to root as an initial step.
Improve this answer
1
  • Thanks. Host was able to start it and I did compare them with another system, it was around 20 folders that were changed, they were all supposed to be root:root but they were teamspeak:teamspeak on mine.
    – adrianTNT
    Feb 2, 2012 at 18:05
1

The odd thing was that the OP apparently brought down the machine (or at least prevented reboot) by running a command as user "teamspeak" instead of root. This shouldn't happen, unless there were already permission issues on the box before the command was run.

Janne's answer won't work, since the changed files probably shouldn't be root owned to start with, but the idea of using find may be valid.

I don't know where adrianTNT is in his recovery process, but here's the sanity check/validation I would do:

1) run that find / -user teamspeak and get a list of changed files 2) compare this list to the file ownerships of a different CentOS box 3) if a different CentOS box is not available (or can't be brought up quickly enough), at least do an eyeball of the file list. Look for system files that have changed ownership.

I think you will still want to look at a different CentOS box once you have this list. As said, a chown by a non-privileged user should not screw up the box like that. It's possible there were permission issues prior to your mistake.

Improve this answer
4
  • Progress is: since I posted the issue I never accessed the server (never booted) and I was waiting for my host to setup a "recovery mode" boot, where hopefully I can run the find / -user teamspeak command.
    – adrianTNT
    Feb 2, 2012 at 15:24
  • The reboot command WAS made as root, just the command that attempted to change file owner was made as teamspeak user. Before reboot I also added a script in /etc/init.d/ there is a chance that THIS is the boot issue instead of the file permission change that apparently failed.
    – adrianTNT
    Feb 2, 2012 at 15:27
  • 1
    Yes, that's what I meant: you ran the "chown" as a non-privileged user, so, on a proper box, it should not have caused any damage that would prevent you from successfully rebooting the machine. Either there's some other problem, or there were permission issues that existed earlier that allowed the non-root "chown" to cause real damage. The "chown" by itself should not have caused the problems you're describing.
    – cjc
    Feb 2, 2012 at 15:30
  • My host started the server, I posted a detailed answer about this. I checked the files now and it was just around 20 folders changed, mostly in root, but NOT many in sub-directories. So my command did SOME damage but still it was not able to change too many. But yes, a different user other than root should not be able to cause that kind of problems.
    – adrianTNT
    Feb 2, 2012 at 18:01
1

The issue was fixed, a data center technician started it and said:

the machine was halted in the BIOS on an error, waiting for intervention.

I am waiting for more info but it was probably a booting warning because the /boot directory was set to another user than root:root

Now I got in ssh and ran find / -user 'teamspeak' to see the files with wrong user set, it was:

/mnt
/lib
/lost+found
/root
/etc
/lib64
/opt
/sbin
/var
/var/tmp/yum-teamspeak-6jBpFg
/usr
/boot
/home
/home/teamspeak
/home/teamspeak/.viminfo
/home/teamspeak/.bashrc
/home/teamspeak/.bash_profile
/home/teamspeak/.bash_logout
/home/teamspeak/.bash_history
/srv
/selinux
/tmp
/bin
/media

These are not many changed files/folders and result seems to include sub-directories too. So I compared them to another machine with same OS (CentOS 6), they were all supposed to be root:root , I changed them back, I did a reboot and it started nicely.

Pfew :)

Improve this answer
5
  • So, you were able to change the ownership of /root /bin /boot and so on, while running chown as user "teamspeak"? You have other permission problems, as this should not be possible. Look at the permissions on "/" with ls -ld /. On my CentOS5 box, I see ther perms as 755. You must have had them set to 777. /boot, in another example, is set to 755 also. Check the permissions on these directories as well as ownership, since something is wrong.
    – cjc
    Feb 2, 2012 at 18:03
  • Result of ls -ld / is this: dr-xr-xr-x. 24 root root 4096 Feb 2 18:31 / If this looks ok then maybe (just maybe) I was logged as root when I initially set the folders to "teamspeak:teamspeak", if that was the case then I am sorry to cause confusions. But then, if I was logged as root at that time, then I think many more files would have been changed. All I remember was that I seen over 30 lines of "failed to change ..." and I pressed CTRL+C to stop it.
    – adrianTNT
    Feb 2, 2012 at 18:10
  • As cjc said, a non superuser shouldnt be able to change hardly any of those folders that you listed (I.e. lost+found is 700 with root being the owner... no other user should be able to change that..). Odd ...
    – Safado
    Feb 2, 2012 at 18:13
  • You wouldn't have gotten the "failed to change" messages if you were root. It would have just seemed to take longer than expected, while your system was getting nuked. The 555 perms on / are also a little odd, since I have it as 755 on my CentOS box. Very strange.
    – cjc
    Feb 2, 2012 at 18:18
  • Well if permissions look strange to you, I will add some iptables rules to limit access to SSH and FTP, and I am the only user on this server so hopefully I will not have security issues.
    – adrianTNT
    Feb 2, 2012 at 18:32
0

If you don't have a backup the only solution that comes into my mind is to reinstall a server and never run that command again :D

You can still boot from the CD, mount the disk and recover the files you need.

Improve this answer

You must log in to answer this question.

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