The troubleshooting guides in this section contain information on diagnosing and solving the the most common account problems you might encounter.

Troubleshooting Broken Images and Hyperlinks

How to Fix Broken Images and Links on Your Website

There are three possible reasons why your images are not showing up on your pages as expected:

  1. The image file is not located in the same location that is specified in your <IMG SRC=> tag;
  2. the image does not have the same path and/or file name as specified in your <IMG SRC=> tag;
  3. the image file is corrupt or damaged.

There are two possible reasons why a hyperlink returns a File Not Found error:

  1. The page you’re linking to does not exist in the same location as specified in your <A HREF> tag.;
  2. The page you’re linking to does not have the same file name as specified in your <A HREF> tag.

Broken links or images cannot be caused by problems on the server side. They can only be caused by incorrect HTML coding or errors in uploading image files to servers.

Getting Started – What’s the Browser Looking For?

Troubleshooting broken images and links should begin with the following step:

Position your cursor over the broken image or hyperlink and right-click your mouse. A popup menu should appear with several options.

In Google Chrome right click on the image and in the popup click Inspect Element. You will see something like this:

Broken Images

Note the URL that appears in the source.

The URL that is displayed there shows the location that your web page is telling browsers to look for the image. Write down the path, or copy and paste it into your favorite text editor so that you can refer to it later.

Next Step – Verify the Image Filename and Location

Now that you know where the image is supposed to be and what it’s supposed to be named, verify that it’s there. Using either your FTP or control panel file manager, log in to your account and navigate to the directory named in the path you’ve identified above. When you first log in to your account, you will be in your “root” or “system” directory (unless you have your client configured to automatically open in a subordinate directory.) The path represented by www.mydomain.com is your www directory, so the first place to go is to that directory. With FTP, just double-click on the directory named www. In SSH, issue the UNIX cd command. Type the command cd www and hit Enter.

Continue navigating in this way until you reach the subdirectory in which your image is supposed to be found. Once you’re there, try to locate your image file. FTP clients will automatically display all the files located in the current directory. In SSH, to get a directory listing, type ls -a and hit Enter.

Chances are that by now you’ve discovered the problem. If the image file’s not there, either put it there or adjust your image tag so that it reflects the correct location. Here are some important things to remember:

  1. UNIX is CASE SENSITIVE. As far as Unix servers are concerned, myimage.gif, MyImage.gif, and myimage.GIF are three completely different files. Check your file name – the filename in your directory and the filename in the path included in your web page must match EXACTLY. If they don’t, change one or the other so that they do.
  2. The case sensitivity issue holds true with directory names, too. MyImageDir and myimagedir are treated as two distinct directory names. Make sure the directory names match, too.

If It Still Doesn’t Work

If the system path of the image file matches the URL of the browser path *exactly*, and the image still doesn’t show, then the image file may be damaged or corrupt. Make sure the image loads on your local computer (try it out in your browser) and then upload it again – make sure to upload images in BINARY mode (Fetch users: Set your Binary mode to “Raw Data”.)

For WordPress Users

There is a plugin for WordPress that alerts you of broken links and images. It’s very simple simple and handy. See here.

Cannot Connect to Your Newly Created Hosting Account? Here is Why.

Cannot Connect to Your Newly Created Hosting Account? Here is Why.

Connecting to your web hosting account from your local computer involves your ISP, a series of outbound routers, a series of inbound routers, and your web host’s servers. Often, as many as 12 – 24 individual computers are involved in the transmission of data between your computer and your account on hosting servers.

Of those 12 – 24 computers, only one is ours. While it’s easy to blame your hosting company for every problem the internet experiences, in the overwhelming majority of cases the problems do not originate with them, and there’s nothing they can do to fix them.

The information below describes the process in more detail and may assist you in locating the source of the problem.

Note: The Internet is not 100% reliable and it probably never will be. You can increase the reliability of your own access to the Internet by maintaining two or more separate ISP accounts, each of which is preferably connected to the Internet by a different backbone. If you’re having trouble connecting with one account, switch to an alternative and see if the problem improves. That’s an expensive solution, but if reliable access is important to you, it may be worth the added cost.

The information below applies to general connectivity issues (browser, FTP, SSH, and e-mail). If your problem is specifically with e-mail only, please see the E-mail Troubleshooter.

Cannot find server or DNS Error

This error occurs when the domain name cannot be resolved to a valid IP address. It can be caused by a number of problems, including the following:

You’ve typed the domain name incorrectly

Make sure that the domain is spelled correctly in your browser’s address bar.

You’re not connected to the Internet

It’s happened to all of us. Make sure you’ve established a valid connection to your internet service provider.

Your domain registration has expired and been deactivated by the domain registrar.

Do a WHOIS Lookup on your domain name and check the expiration date. If your domain name has expired, you need to renew it with the domain registration agency.

Your domain name is not pointing to Your Web Host’s Domain Name Server (DNS)

Make sure that the DNS information for your domain name is pointing correctly to your web host’s nameservers (ns1.yourhost.com and ns2.yourhost.com).

Your ISP’s Domain Name Server (DNS) is not functioning correctly

Run a traceroute and see if you receive an error message that says something like “Unable to resolve hostname”. Send a copy of the traceroute results to your web host’s support department for evaluation.

Our Domain Name Server (DNS) is not functioning correctly

Run a traceroute and see if you receive an error message that says something like “Unable to resolve hostname”. Send a copy of the traceroute results to support department for evaluation.

There’s a problem with an intermediate router.

Run a traceroute and see if any of there are any timeouts or failures along the route (indicated by asterisks in the time columns.) Send a copy of the traceroute results to support department for evaluation.

Our server has crashed or is down for maintenance

Run a traceroute and see if you receive an error message that says something like “Unable to resolve hostname”. Send a copy of the traceroute results to support department for evaluation.

Forbidden (You don’t have permission to access …)

This error means that the directory you’re attempting to browse is not available for one of the following reasons:

There’s no index page

You must place an appropriately-named index page in each directory if you want to browse without specifying an exact file name. Cick here for more information.

Permissions are incorrectly set

The directory and file permissions must be set to world-readable. Typical permissions for a directory are 775 (rwxrwxr-x); for HTML documents, permissions are usually 664 (rw-rw-r--). See the File Permissions Tutorial for more information.

Your account has been disabled.

You will typically see the Forbidden error if your web host has disabled your account for a policy violation or non-payment of your hosting fees. Most attempted to notify you if this were the case. Contact your support to make sure that your account is in good standing.

Internal Server Error

The Internal Server Error is usually associated with CGI scripts. If you’re receiving an Internal Server Error when browsing HTML pages, notify your web host’s support.

Reporting Connection Problems to Your Web Host

When reporting a connection problem, provide as much information as possible: The more information you provide, the faster your website host can investigate and solve the problem. Questions that they’re likely to ask before they can solve the problem for you include the following:

  • What’s your domain name?
  • What connections are affected (browsing, FTP, SSH, e-mail, or everything)?
  • What is the exact error message or result you’re encountering?
  • Can you connect to your account by numeric IP number?
  • Do you have access to a different ISP (or another computer / mobile device connected to a different ISP, or a friend or colleague who’s connected to a different ISP …), and if so does the problem occur with that connection, too?
  • Is the problem consistent, or does it work sometimes and sometimes not?
  • How long have you been experiencing the problem?
  • Is the problem software-specific (e.g., does it work okay with Chrome, but not with Firefox, or vice-versa)?
  • What is the username for the user account experiencing the problem (they’ll need this in some cases to attempt to replicate the problem or error.)
  • What are the traceroute results?
Domain Traceroute Instructions

How to Do a Traceroute to a Domain?

In many cases, you’ll need to see a traceroute from your computer to your domain in order to diagnose connection and other problems. To run a traceroute from your machine, follow the instructions below.

To run a traceroute to your domain from a Windows machine, open your Command Prompt (Start – cmd.exe), and type the command: tracert mydomain.com replacing mydomain.com with your domain name. The results will look something like this:

 C:\>tracert mydomain.com
 Tracing route to hostingmanual.net [64.33.62.124]
 over a maximum of 30 hops:

   1  <1 ms  <1 ms  <1 ms  mynetworkserver [192.168.0.1]
   2 150 ms  16 ms  34 ms  gate.myisp.com [12.14.232.1]
   3  61 ms  60 ms  66 ms  sl-gw12-kc-9-1-0-TS12.sprintlink.net [160.81.94.81]
   4 109 ms  60 ms  72 ms  144.232.23.14
   5 111 ms  50 ms  54 ms  sl-bb23-fw-10-1.sprintlink.net [144.232.18.229]
   6 145 ms  67 ms  52 ms  144.232.18.30
   7 106 ms 183 ms 191 ms  177.at-2-0-0.XR1.DFW9.ALTER.NET [152.63.100.170]
   8 135 ms 105 ms 427 ms  0.so-2-0-0.XL1.DFW9.ALTER.NET [152.63.101.253]
   9 116 ms 176 ms  94 ms  0.so-0-0-0.TL1.DFW9.ALTER.NET [152.63.0.193]
  10 272 ms 158 ms 178 ms  0.so-5-0-0.TL1.CHI2.ALTER.NET [146.188.177.253]
  11 213 ms 130 ms 114 ms  0.so-2-0-0.XL1.CHI2.ALTER.NET [152.63.67.126]
  12  97 ms  79 ms 155 ms  0.so-7-0-0.XR1.CHI2.ALTER.NET [152.63.67.130]
  13 103 ms 110 ms 128 ms  193.ATM7-0.XR1.CHI6.ALTER.NET [152.63.65.26]
  14 163 ms 165 ms 209 ms  191.ATM11-0-0.GW2.CHI6.ALTER.NET [146.188.208.185]
  15 285 ms 200 ms 174 ms  UU-ds3.axxs.net [157.130.101.114]
  16 159 ms  67 ms  83 ms  209.204.202.246

 Trace complete.

Interpreting Traceroute Results

Traceroute is a tool that traces the route that packets travel across a network connection between two hosts. The route between your computer and your domain on our servers will vary from time to time as the network routers involved attempt to find the fastest and most reliable route.

The name (if available) and IP address of each gateway (router) is displayed, along with the round trip time (in milliseconds) for each of three trace packets to reach the specified gateway and return. These intervals may vary widely as a function of network load. Lost packets are indicated by an asterisk (*). There are several factors responsible for lost packets: Some gateways don’t return the appropriate message requested by traceroute. Some firewalls use packet filters which block packets used by traceroute. (If you are behind a firewall that blocks traceroute, the results show the route to your firewall, followed by a line of asterisks.) Finally, packets may be lost as a result of network congestion (heavy load). World Wide Web clients and servers normally recover automatically when a small percentage of packets are lost with no indication to the user except for slower response time.

What you want to look for in your traceroute results are any asterisks (*) or excessively high numbers in the time columns. “Excessively high” is a relative term, and depends in part upon your own Internet connection speed. For example, users connecting via a 28.8 dial up connection will tend to see higher round-trip times than cable-modem or DSL users. A general rule-of-thumb might be that times of under 350 ms are “normal”, times between 350 – 1000 ms are “moderately slow”, and any times over 1000 ms are “slow” and indicate a potential problem. Asterisks indicate that the router did not return a response at all. If a particular router did not return any times at all, then that’s a good indication of the source of your problem.

The first 2 or 3 “nodes” or “hops” represent your computer and your ISP’s server(s) and router(s). The last two nodes represent your domain and the server it resides on (which are the only two nodes that we have any control over.) All nodes in between represent “Internet backbone” routers. These routers are provided by independent companies (like AT&T, Sprint, MCI, etc.)

If the traceroute indicates that the problem may be at your domain or its server, you should contact support so that we can investigate the problem. If the problem appears to be at your ISP, you should contact their support department for assistance. If the problem appears to be somewhere in between, there’s really no one to contact, since the backbone providers do not support end users. On the other hand, they generally do an excellent job of monitoring issues on their network, probably knew about the problem long before you did, and are working hard to get it corrected.

Sending Traceroute Results

To copy the traceroute results from the Windows command prompt:

  1. Right-click your mouse and select “Mark”.
  2. Highlight the full text of the traceroute results by positioning your cursor at the beginning, holding down your left mouse button, and dragging the cursor to highlight the contents.
  3. Hit your Enter key to copy the results.

To paste the results in an e-mail or web-based form, just right-click and select “Paste”, or type CTRL-V.

Other Traceroute Options

If the command prompt option sounds like too much trouble, or if you’re using a Mac instead of a Windows machine, there are software programs available that make the process easier:

Windows Traceroute Software:

Mac Traceroute Software

Troubleshooting E-mail Problems

Troubleshooting E-mail Problems

Check your Configuration

The first thing to do is verify that you have configured your e-mail client correctly. CLICK HERE for detailed instructions.

At the very least, make sure that you have your POP (Incoming) Mail Server set to yourdomain.com (where yourdomain.com is your actual domain name.) Do not prefix your domain name with http://www.,mail.pop3. or any other prefix.

Also verify that your username and password have been entered correctly. For the e-mail account yourdomain@yourdomain.com, the correct username is: yourdomain — it is not yourdomain.com.

Check your Domain Registration Status

If your domain name registration has expired, no functions associated with your domain name (e-mail, www, ftp, etc.) will work. Also, if the Domain Nameserver (DNS) information associated with your domain name is not pointing to tintagel.net nameservers, you will not be able to access any functions on our servers by domain name. You can use any WHOIS lookup to check the status of your domain name.

Check Your Redirects, MailLists, Infobots, & PlusRoamer Configuration

The most common cause of e-mail delivery failures is an incorrectly configured default redirect in your e-mail forwarding. Log in to your Web Control Panel (http://www.yourdomain.com/cgi-bin/plusmail, where “yourdomain.com” is your actual domain name) and select the E-mail Forwarding link. The first redirect listed should look like this:

default    yourdomain@yourdomain.com

The default entry must be your primary account login (yourdomain@yourdomain.com, where yourdomain.com is your actual domain name.) If you set your default redirect to a different e-mail address, your e-mail will not be delivered predictably or reliably. For example, we see a lot of entries like this:

default    myemail@aol.com

What you want is for all of your e-mail to be delivered to your AOL account. What you get is none of your e-mail being delivered anywhere. If you want your mail delivered to an e-mail account outside of our network, set up your redirects like this:

default     yourdomain@yourdomain.com
yourdomain  myemail@aol.com

Also, note that the primary login is the only POP login that can be redirected. Another common problem occurs when you set up a POP login and a redirect for the same name. This can result in mail not being delivered. Make sure that you do not have the same name duplicated in your POP users and redirects. See the E-mail Forwarding Instructions for information on correctly configuring your redirect files.

Check your MailLists and Infobots (Autoresponders). You cannot have a maillist or an infobot with the same name as a POP user. CLICK HERE for instructions on correctly configuring autoresponder/infobots, and CLICK HERE for maillist configuration instructions.

Finally, if you’ve installed PlusRoamer on your account, make sure that your PlusRoamer usernames are unique, as well. PlusRoamer accounts cannot have the same name as a POP, redirect, autoresponder, or maillist. Also, remember that the PlusRoamer admin account will receive all e-mail that would otherwise be destined for your default (mydomain@mydomain.com) e-mail address.

Relay Attempt Failed Error

You attempt to send mail, but receive an error message that looks like this:

protocol smtp; server response 550; relay attempt failed

This one’s usually easy to fix: Simply check and receive your mail before you try to send mail. In order to prevent our mail servers from being used for the transmission of SPAM (junk e-mail), we’ve configured our servers to require that no mail can be sent from a given domain’s SMTP (outgoing mail) server unless the same domain’s POP (incoming mail) server has been accessed prior to the send attempt.

At the present time, it is only necessary to have checked for new mail once during any 24 hour period. Checking the POP (incoming) mail server effectively “unlocks” the SMTP (outgoing) mail server and allows the relay to go through.

Port 25 (SMTP) Relay Blocking

Another common source of the relay error is due to your local ISP blocking relays to external SMTP servers (Port 25 Relays). ISPs do this to eliminate their network from being used to transmit spam — they simply do not allow anyone to connect to any SMTP server outside of their network. Almost all of the larger ISPS (notably, Earthlink and MSN) and more and more smaller ISPs are now blocking Port 25 Relays.

The solution to this problem is to simply substitute your ISP’s SMTP server information for your domain name in your e-mail client configuration. We recommend this configuration even if your ISP is not blocking relays, as it will generally result in more reliable SMTP connections. Mail will still appear as coming from your domain (as long as you have your From and/or Reply-to addresses configured correctly.) Your ISP can provide the information you need to set up the connection — usually mail.myisp.net or smtp.myisp.net. Contact your local ISP’s support staff to obtain the correct settings.

SSL Negotiation Failed Errors

You may see an error referring to problems with SSL, similar to one of the following:


SSL negotiation failed - negotiated key exchange length is -1

SSL negotiation failed. You have configured this personality/protocol to reject any exchange key lengths below 0. But the negotiated exchange key length is -1 Hence this established secure channel is unacceptable. Connection will be dropped. Cause (-6992).

Our mail servers do not currently support SSL connections. These errors indicate that your e-mail client is configured for this unsupported connection type. In Microsoft Outlook, uncheck the box next to This server requires a secure connection (SSL) in your Advanced properties section. See the Outlook configuration instructions for more information.

If you’re using Eudora to check your mail, review the Eudora configuration instructions, or follow these steps:

  1. Right click on your personality name to bring up the menu. Then, click “Properties”.
  2. Look toward the bottom of the box until you see “Secure Sockets When Sending”. Change that option to “Never”.
  3. Click on the “Incoming Mail” tab at the top of the box and change “Secure Sockets When Receiving” to “Never” also.
  4. Click “OK” and check mail again. The error should not return.

Firewall and Anti-Virus Software

Improperly configured firewalls and/or anti-virus software can interfere with POP and SMTP connections. Both the Norton and PC-Cillin anti-virus software packages have proven to cause sporadic and unpredictable failures with POP3 connectivity.

Try temporarily disabling any software of this nature and see if the problem disappears. If it does, you’ve identified the source of the problem. You’ll need to contact your network adminstrator or the software manufacturer for assistance with proper configuration.

After disabling any virus protection software, double-check your e-mail client configuration. Many virus protection programs will overwrite your settings (for example, they may replace the POP Server name withlocalhost and the Username with something that looks like yourdomain/yourdomain.com. These settings will not work with the virus protection disabled — you’ll need to reset your configuration to correspond to our E-Mail Configuration Instructions.

Server Errors

You could receive any number of error messages describing unavailable server, connection with the server reset, server connection timed out, etc. In some cases you can receive mail without problem, but cannot send mail.

There are all sorts of conditions that can contribute to sendmail problems, including the standard internet connection issues, which can cause timeouts when connecting to your web site via browser, POP, FTP, or telnet. (These issues are described in the Connection troubleshooter. Most of these issues are not related to our servers.

Sending mail (via SMTP) and receiving mail (via POP) are related, but essentially independent, processes. The fact that you can receive mail, but not send mail, is not as inconsistent as you might imagine.

For example, when you send e-mail, the actual destination server of the mailto address is contacted and resolved before our server allows the mail to be sent. Problems with the destination server can result in timeouts and other errors.

This process also increases the number of “hops” the process encounters, as the transmission goes from your ISP to our servers to the destination server then back to our servers to be sent. The more hops, the greater the chance for a dead or slow node, the greater the chance for a timeout error.

Running a traceroute from your connection to your domain, and to the destination server might help pinpoint the source of the problem. If the problem is related to Internet congestion or problems with intermediate routers, it will usually disappear within a short time.

America Online (AOL) customers report more problems in this area than most other users. AOL was not originally conceived or designed as an Internet service provider and most of their system protocols are not standard Internet protocols. They seem to have consistent problems sending and receiving e-mail through their own system — trying to use an AOL connection to drive Internet protocols is even less reliable. According to the latest information, AOL does not support external POP/SMTP connections — they may work or they may not. The only solution to this problem is to switch to a “true” Internet Service Provider.

Reporting E-mail Problems

If the information above does not solve your e-mail problem, please provide enough information so that we can effectively troubleshoot the issue.

IMPORTANT NOTE: If you are unable to receive mail from your account, provide an off-network e-mail address that we can reply to — if the problem is not related to a server-side issue, and the only e-mail address you provide is on the affected domain, you won’t be able to receive our response to your problem report.

At the very least, we’ll need the following information:

  1. Your domain name
  2. Username(s) for the affected E-mail account(s)
  3. Password(s) for the affected E-mail account(s)
  4. A copy of the exact error message you’re receiving
  5. A complete description of the problem and when it occurs (e.g., sending, receiving, or both?)

Other information that can be helpful includes:

  1. The E-mail client you’re using (Outlook, Eudora, etc.)
  2. The speed and type of your Internet connection
  3. If you have access to a different ISP account, does the problem occur with that connection, too?
  4. Is the problem consistent or sporadic?
  5. When did the problem start?
  6. The results of a traceroute to mail.yourdomain.com, where yourdomain.com is the name of your actual domain name