Troubleshooting websites can be a daunting process at first. This page is designed to guide you through finding out your error message, and also lists common issues and solutions for a wide range of possible problems.
Finding an error message can be extremely helpful in pinpointing the cause of the issue. The following is a list of steps you can try to find an error message:
You may be receiving an error message in your browser. Read it carefully for any hints. Often times a "Permission Denied" error will include "Error Notes" that can help pinpoint the reason for failure.
Check your website's apache2 error log. Accessing them is easy. The following is a link for each type of website:
- If your website is at students.washington.edu, your error logs are at http://students.washington.edu/adm/errorlog/
- If your website is at staff.washington.edu, your error logs are at http://staff.washington.edu/adm/errorlog/
- If your website is at faculty.washington.edu, your error logs are at http://faculty.washington.edu/adm/errorlog/
- If your website is at depts.washington.edu, your error logs are at http://depts.washington.edu/adm/errorlog/
- If your website is at courses.washington.edu, your error logs are at http://courses.washington.edu/adm/errorlog/
Your error log will contain information about major server errors.
Note: The error logs will only appear if you are logged in as the NetID in question. If you are working on a website other than your personal one, you will want to open a new browser and go to the site of the error logs. Then log in with the NetID in question.
If your MySQL server is not working properly, MySQL keeps an error log that can assist in diagnosing issues.. This file should be in the following location:
- For students: ~/mysql/data/vergil01.u.washington.edu.err
- For everyone else: ~/mysql/data/ovid21.u.washington.edu.err
Scroll down to the bottom of the error log and see if MySQL is encountering any errors that it explains in further detail.
- If you are using a Content Management System such as WordPress or Drupal, they may also contain independent logging mechanisms. Consult the documentation for these systems to see if you can access these logs.
- Receiving "Permission Denied" error stating "Server unable to read htaccess file, denying access to be safe."
Your .htaccess file must be readable by the server in order for your site to work. It is recommended to keep your .htaccess file with the "644" permission. Read about changing file permissions.
- Receiving "Bad Script permissions" error.
An executable script must not be writable by certain classes of users. They must be set to permission 744 to work properly. Read about changing file permissions.
- "Server Error: The server encountered an error attempting to retrieve the requested resource. Please notify the owner of the problem." with no other explanation.
This is a case where you will want to look at your Apache Error Log as outlined earlier in this page. In this case, we will see the following error:
/hw12/d26/webtest/.htaccess: Invalid command 'requir', perhaps misspelled or defined by a module not included in the server configuration
You will will want to make sure your .htaccess file is formatted properly:
- Make sure all words are spelled correctly.
- Remove all lines that begin with "Options." Our servers do not allow .htaccess files with "Options" commands.
- Ensure that there are line breaks where there should be.
- Check general syntax.
- A .php, .cgi, or other script file does not load, or loads with a blank page.
This is where your error log can help again. In this case, this is what the error log shows:
Script /hw12/d26/webtest/index.php is writale by group or world
Executable scripts cannot be writable by anyone but your own user account. You will want to set the permissions to 755. Read about changing file permissions.
- Website Loading Slowly
Fixing a slow website is not a turnkey operation, but may require a careful analysis of your traffic, loads, and supporting site framework. In many situations, inefficient scripts, overloaded databases, or simply too many users can cause your website to load slowly. If you are using a CMS, look into a caching solution. If your site is custom-built yet relies on dynamic content, consider developing your own caching mechanism. Caching will only generate a dynamic page when necessary, and will serve a "cached" pre-rendered page to users when it determines that a full page regeneration is not necessary. It won't impact user experience, but will greatly improve load times.
- MySQL crashes (segmentation faults) when editing queries.
The version of MySQL currently installed on vergil and ovid will crash (segfault) in certain circumstances. This usually appears when a user attempts to use the directional keys and then "backspace." There is no fix at this time. We suggest writing your queries in notepad and then pasting them in MySQL for execution.
- I'm Uploading Files, but They're Not Appearing On My Website
If files you're loading aren't appearing on your website, here are a few things you can try.
- Be sure that you are uploading to your public_html folder.
- Delete the file called index.html in your public_html folder.
- Check to be sure that your files are not going into a subfolder.
- If all of these don't work, contact UW-IT for further assistance.
- Cannot Upload Files Anymore, or Files Uploaded Are Truncated
If you find that you cannot upload any more files to your web space, or that files you upload are truncated or reduced to 0 bytes, then it is possible that you have gone over your storage quota. Use the Disk Usage Viewer to confirm.
- MySQL Isn't Starting, or is Responding Slowly
A good place to start looking for MySQL errors is your MySQL error log. It can be found in your mysq-data folder in a file called either ovid21.u.washington.edu.err or vergil01.u.washington.edu.err. Scroll down to the bottom of the document to view the most recent errors.
- I deleted my public_html or student_html folder. I remade it, but it isn't working.
Your public_html folder is actually a symlink (Linux-speak for 'shortcut') that points to a special folder on one of our web publishing servers. When you delete and then re-add the public_html "folder" this link is not automatically re-created. In order to fix this issue, you must do the following:
- Rename or delete your current public_html folder. Make sure no folder or file exists called "public_html"
- Deactivate your relevant web publishing service at https://uwnetid.washington.edu/manage/?service
- Activate that service again. As part of the activation it should re-recreate your public_html folder.
- I added a large list of NetIDs to my .htaccess, and now my site is broken.
When using Pico, it will automatically "wrap" long lines. When this occurs, the format of the .htaccess format is broken and the site will refuse to load. You will want to edit the file with the "-w" flag.
pico -w path/to/file/to/open
This should cause the file to save normally.
- I changed the port for MySQL, now it isn't working.
In order to successfully change your MySQL port, you must restart your MySQL server. Use the following commands:
~/mysql/bin/mysqladmin -u root -p shutdown
Your MySQL server should now be using the updated port. Run ps uxww to verify.
- iWeb Isn't Uploading to My Site.
iWeb does not correctly follow symbolic links, which breaks the direct uploading capabilities of this software. You will want to save the files on your computer and then move the files to public_html manually.
- Where To Get Help
- If you've read through this document and your website is still in a non-functional state, try searching online for others with similar issues. If you can't find anything, you can contact UW-IT or email email@example.com. While we cannot fix every problem, we may be able to spot something on our end that isn't working or give you pointers on where to look for a solution.