Screwed up! Changed all files owner & group on server

[duncan]

I was careless with manually changing the owner & group for some files, and accidentally changed everything on the system by using "/" while logged in as root.

I immediately changed everything back to root:root, thinking that might be better. I then ran the DA user/group update script.

User HTML files work, but PHP files show a system error. I am sure more things are screwed up than just that.

What do I do?? ANY advice is greatly appreciated.

 

[duncan]

If it helps, for the PHP "Internal error", the following is being thrown:
SecurityException in Application.cpp:181: Do not have root privileges. Executable not set-uid root?

Any ideas on how to fix that one?

 

[duncan]

I got PHP working by reinstalling it, and now I just have to fix DNS. The nameservers are not responding, even though named is running fine. No errors appear in the syslog. Any ideas?

 

[zEitEr]

Hello,

To fix permissions on directadmin related files including homedir, mail, etc you might want to use this script:

# /usr/local/directadmin/scripts/set_permissions.sh

DirectAdmin File Permission/Ownership script

Usage:
  /usr/local/directadmin/scripts/set_permissions.sh all

  /usr/local/directadmin/scripts/set_permissions.sh da_files
  /usr/local/directadmin/scripts/set_permissions.sh user_homes
  /usr/local/directadmin/scripts/set_permissions.sh mysql
  /usr/local/directadmin/scripts/set_permissions.sh email
  /usr/local/directadmin/scripts/set_permissions.sh logs
  /usr/local/directadmin/scripts/set_permissions.sh etc_configs

internal:
  /usr/local/directadmin/scripts/set_permissions.sh maildir <user> <path/Maildir>
  /usr/local/directadmin/scripts/set_permissions.sh set_user_home <user>

Note, you might need to chgrp to access, since the script might not support that group.

Then, you might need to use find to list all files which use chowned to another owner & group, an change the owner back. You might need to check with another VPS/dedicated server, which has correct permissions.

Note, if you need somebody's hands to do it for you, I'm as well as others here available for this kind of job. If you want to fix it yourself feel free to ask more questions.

 

[duncan]

Hi Alex,

Thanks for the reply, it's much appreciated.

I got the problem sorted out last night, likely just before your message. Although named was running fine, the issue turned out to be it's .db zone files which could not be read. I had to overwrite the permissions on them and then restart, which fixed that issue.

Everything is now running seemingly normal. Certainly not something I'd like to repeat at any time in the future

Duncan

 

[Suurbier]

Why don't you run the set_permissions script to make sure everything is fine, it can't hurt your system

 

[scsi]

If you did this in / I wouldnt be suprised if you find alot more problems down the road. I wouldnt know of any easy fix except to build a new box or reinstall.

 

[duncan]

One Remaining Problem: SpamAssasin

It looks like one problem that is remaining is SpamAssasin. It's running, does not show any errors in the logs, but messages are not being run through it (checking the headers).

I tried reinstalling SA, but the problem persists. Any ideas??


P.S. scsi - yep, that's exactly what I did "/" instead of "*" - a very unfortunate mental lapse


UPDATE:
I checked exim.conf and uncommented the SpamAssassin section, and now it's working. I'm not sure if this is recommended or not? I had re-installed Exim during the mess, so I'm not sure if this is a new configuration file, or if it's not supposed to be uncommented or not. I am using CustomBuild, if that matters.
Thanks in advance!

 

[zEitEr]

so I'm not sure if this is a new configuration file, or if it's not supposed to be uncommented or not. I am using CustomBuild, if that matters.

SA section by default in /etc/exim.conf is commented. So you've done the right thing.