I run chown -R www-data:www-data xxx.com / by mistake...

Starry

and I press Ctrl+C as soon as possible. now many services are affected...

what should I do to fix it? I am trying to run chown one by one - -

Spencer

Nice! Im sure we have all done this before

erhwegesrgsr

@Spencer said: Nice! Im sure we have all done this before

Nah, I just rsync'd my Minecraft customer's files to a Kimsufi at 5am beig sleepy and didn't see disk space ran out on the kimsufi (stupid /home partinioning of OVH, i stored in /root) and happily wiped my main node, god, that was stupid.

Kenshin

1) Restore your backup into another folder
2) find /folder-of-backup -user username

You will then have a list of full paths owned by each of the original username. Write a simple script that parses the file and re-chown to the original user.

If you can't do it yourself, I'm sure there's some LowEndTech here that will do it for a small fee.

Starry

@Kenshin - -I didn't backup the files that in /etc /var and so on...

Kenshin

Oh boy, well then temp solution is to chown everything back to root:root then re-chown whatever you have in backup. At least you didn't chmod, that one would be worse.

perennate

Well, can't you make a script to chown it back based on the directory? Assuming you have something that can tell you which user owns which directory.

Starry

@Kenshin oh, I fix it now... so tired...

natestamm

this -> find . -type d -print0|xargs -0 chown user:user .. use 'f' over 'd' for files .. can chmod et al

FRCorey

best bet is to learn you lesson and redo your server because chowning everything as root could open a security hole.

raindog308

Only two options I can think of:

(1) restore from backup

(2) create a VM with that OS (could even be on a desktop virtualbox/vmware/etc.) and then run a script to capture the ownership of every file and directory, then play that back on your messed up VM

BTW, I always capture /etc in backups. /var maybe not, depending on the filesystem layout, but /etc is a must. It's small (megabytes) and has a ton of config info that is a pain to recreate. In general I capture everything by default and only exclude specific things:

/var/tmp
/var/lib/mysql
/var/mysql
/tmp
/dev
/proc
/sys
/etc/udev

MySQL is listed there only because I do a dump ahead of time and of course the dump directory is backed up.

I could probably add to that list - /lib, /usr/lib, /usr/bin, etc. But in the big scheme, it's better to have too much than too little.

risharde

At least it wasn't one of those rm -rf commands, glad you got through and were able to fix it after some hard work @Jylee

hostingwizard_net

Except for /home eventually, and for a given os/distro, the owner will be the same. So I would get the data from another VPS and apply it to the broken one.

erhwegesrgsr

buy a second kimsufi and drag the files over you need :-)

twain

Well now you will hopefully never do that again... sudo might have saved you there if you had to enter pass and got a chance to take a 2nd look...

Bogdacutuu

@twain said: Well now you will hopefully never do that again... sudo might have saved you there if you had to enter pass and got a chance to take a 2nd look...

Sudo doesn't ask for password every time.

jh

@Bogdacutuu said: Sudo doesn't ask for password every time.

Depends on the settings in /etc/sudoers

Bogdacutuu

@jhadley said: Depends on the settings in /etc/sudoers

since he didn't use sudo (he ran the command directly as root), I highly doubt he edited that file at all

Starry

@Bogdacutuu no, I run sudo su when I connect to my server.

dedicados

i suggest you, to run!

twain

@bogdacutuu notice I said ”if you had to enter pass”