permissions - How to revert mass ownership change?

I
accidentally executed the chown someuser * -R while I was at
/ on my server.
I thought maybe by issuing
chown root * -R would somehow fix it. But it seems that there
are some problems.
For example now the DirectAdmin is acting weird when I try
to login. It
says:

Unable to determine Usertype
user.conf needs to be
repaired

Is there
any way that I can fix the
situation?

Update:
I thought maybe of fixing the problem by writing a shell script which checks every
file's group and sets the user accordingly, as it is my knowledge that usually all the
files have same values for user and group.

class="post-text" itemprop="text">

class="normal">Answer

That is
unfortunate!

What the latter command you issued
did was change the ownership of all files to root. So, any files that were set up as
suid (set UID, so that they run with the privileges of their owner) will run with root
permissions, and also users will not own their home directories. Be very careful of
this. Consider using ls to search for such files, as this could be a serious security
issue if your users had any suid shell scripts or
whatnot.

You are presented with a
difficult situation; you must now determine who should own what files, and manually
assign it. In some cases it will be easier to rebuild then do this, especially if you
have backups of your configuration (I assume you backed up your data). If you don't,
back it all up now, so you have a reference when rebuilding. However, if you don't mind
a little inaccuracy, there are a few simple
rules:

• A user should own
  all the files in their home directory. For each user, chown -R username
~username.


• A service that changes its own
  files should typically be owned by the user the web application runs as. While you can
  configure this, if you are using apache that user is usually called apache. For each
  such application's webroot, chown -R apache
/path/to/webroot.


• Similarly, files and
  directories that will be changed by a service (eg. upload directories) should be owned
  by the user the service runs as. For each of them, chmod -R username
/path/to/filesystem/object.


• SSL private keys
  belonging to system services should usually be owned by root (and only readable by the
  owner). Where they are stored differs widely, but in all cases you or your predecessor
  put them there. Locate them, and chown root somefile.key for
  each.


• Applications which have config files on which read
  permission is restricted to the owner, but read those files after dropping root, must
  own those files (this sounds like your DirectAdmin user.conf, possibly, if it is what it
  sounds like). chown username
/path/to/file.

Notwithstanding
this, you should consider restoring users' home directories from backup, as they may
have set all kinds of permissions and have all kinds of things in there. Doing this
would help avoid the security risk mentioned in the
beginning.

You cannot infer the owner from the
group. For instance, files in a user's home directory often have the ownership
username:users. Additionally, many files have a particular
owner who can edit them, and a particular group who can read and execute them, and no
permissions for other users. This would also cause odd behaviour, or simply fail (groups
do not need to correspond to users).

Good luck!
If you choose to not rebuild, from now until forever, if you find odd errors about a
file being corrupt or having incorrect permissions, you will have to check
ownership.