Help, I created a permissions disaster with chown

Ubuntu 10.04, Drupal 7.0

:wall:
I created a Linux instance on Amazon AWS using a bitnami Linux image, and had a website up and running using Drupal. Coming from a Windows background I wanted to use a GUI to manage files because it is much faster for me, I got Gnome running on TightVNC by tunnelling through ssh. (It took me a day to find out that the PuTTY private key is in a different format than the key AWS downloads - just a warning that others might find useful.)

The files I need to update in the website folder are created as root root, and I can't drag and drop into those folders from Gnome. So, I had this great idea. I would change the ownership of the files to "me". Knowing the pitfalls of chown (and obviously not all of them) I copied the directory and all of its contents to another directory as a precaution. I spot-checked that directory to make sure the group and owner remained as root root. I thought I was safe and could easily put things back to normal.

Well, changing ownership to "me" broke the permissions and the site. When I renamed the "mysite.bak" folder back to the original name, "mysite" I still had permissions issues. Here are the commands I executed.

sudo cp -r mysite mysite.bak *** to save my original files/permissions
ls -l *** to make sure mysite.bak still had root root ownership, and it did
sudo chown -R site me *** to change ownership

Trying to access the site through http, I got a permissions error:

Warning: include_once(/opt/site/apps/drupal/htdocs/sites/default/settings.php) [function.include-once]: failed to open stream: Permission denied in drupal_settings_initialize() (line 554 of /opt/mysite/apps/drupal/htdocs/includes/bootstrap.inc).
Warning: include_once() [function.include]: Failed opening '/opt/mysite/apps/drupal/htdocs/sites/default/settings.php' for inclusion (include_path='.:/opt/site/php/lib/php') in drupal_settings_initialize() (line 554 of /opt/mysite/apps/drupal/htdocs/includes/bootstrap.inc).

Then, trying to revert back to last known good, I renamed mysite.bak to mysite.

sudo mv mysite mysite.bad *** because it didn't work
sudo mv mysite.bak mysite *** to restore to the original files/permissions

The site still didn't work, returning the same error. I have no clue what is happening here. Any help is greatly appreciated.

---------- Post updated at 10:45 PM ---------- Previous update was at 10:21 PM ----------

Ok, the settings.php file had permissions set as -rw-r-----
So I ran
sudo chmod o+r settings.php

Now I have problems accessing the mysql database:

PDOException: SQLSTATE[HY000] [2002] Can't connect to local MySQL server through socket '/opt/mysite/mysql/tmp/mysql.sock' (13) in lock_may_be_available() (line 165 of /opt/mysite/apps/drupal/htdocs/includes/lock.inc).

Run the gnome instance as root, or change your user account.

Did you create a tar backup? That preserves original permissions.

You will problably have to tink around, first, reset file ownerships to the original.
Next grant yourself group 0 (root root == uid 0 group 0). Your account should then access the files just fine. Be aware that this will affect file sharing with other accounts when you create an file in some other app. You may want two user accounts that can sudo su - [accountname] to each other. One with group 0, one without.

Before I tried any of this, I added myself to the root group.

sudo gpasswd -a me root

That didn't work, and now I think I know why, group permissions probably didn't have the access level I needed.

I didn't create a tar backup. I used the following:
sudo cp -r mysite mysite.bak

When I checked the mysite.bak folder it retained the root root user/group so I thought I was good. Obviously not.

I really don't know how to run the Gnome instance as root. AWS uses digital signatures with private keys and I can't log in using any other name.

I'll try tinking around a bit as you suggested because I will learn a bit more, but then I'll probably revert to a backup snapshot from two days ago.

Thanks for your help. I learned from you I need to create a tar backup in any future similar scenarios.

You really shouldn't.

Digital signatures and keys didn't care about the login name last I checked.

I think it is the image I used.