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.
