If you encounter a problem, we want to help. To do that, we need information.
When requesting help, please answer all these questions:
What exact service or services we provide are involved?
What were you (or someone else) attempting to do when the problem occurred?
What results did you expect?
What were the actual results, including any error messages?
How do the actual results differ from your expectations?
When did the problem (begin to) occur?
Be clear, complete and as specific as possible. All of these questions have simple, obvious, useless answers. Avoid them; they won't help solve your problem. Make the problem obvious with answers that lay it out for someone who isn't you to understand.
If we don't have all this information, then our initial response will probably be limited to requesting it (often by sending you a link to this FAQ entry) so we can help you.
Details on each item above:
Name each site (including a specific URL if applicable), domain, database, service, functionality, or email address you're having a problem with and how it pertains to us. E.g. "The site example which is hosted here."
A description of what happens (or happened). This may or may not be specific to you. E.g. "I was trying to upload images to the 'content' directory of the example site with SFTP." Or "All visitors to https://www.example.com/some/page started getting an error."
Be as specific as you can; it's important. E.g. "I expected the files I uploaded to appear on the site" might suggest a very different problem than "I expected to connect to the SFTP server."
Describe the problem. Never omit or paraphrase error messages. They are crucial diagnostics. Many of the error messages produced by our system are customized to include specific explanations or lists of things to check when they occur. Paraphrasing or omitting an error may hide an easy and immediate solution. Copy and paste text if you can, but take screen shots if you have to. Include anything else that provides context: output messages, configuration data, log entries, etc.
Provide a simple test an idiot could perform to tell the difference.* E.g. "The error page says 'Error' in small black letters and the correct page says 'Example.Com 24x7 Internet Plumbing: We flush the tubes!' across the top in blue."
Be as precise as possible about times, and always include the time zone. (Good: "about 7pm Eastern last night," better: "at 7:13pm Eastern last night," best: "2020-10-01 11:13:41 UTC.") If a problem reoccurs continuously, state whether you're giving the time when it first occurred or, if you don't know, when you first detected it. If the problem is intermittent, please also provide a list of times, the more recent the better. If this is covered by timestamps in log files you're providing, that's perfect.
Other general tips:
If you're asking about an error on your site, make sure you have your site's error log enabled. Then check it. There is a good chance that it will tell you exactly what the problem is.
Use the "Troubleshoot Site" action on the Site Information panel for sites we host. It can identify a lot of weird domain and DNS related issues related to sites hosted here, so it'll help us to know if you've tried that and what the result was.
If you think the problem is something we need to fix, outline the evidence supporting that. We control only a small portion of the Internet; ISPs control part, backbone carriers control others, and you control the stuff on your end. Making it clear why you think the weak link is in our portion of the chain
saves time and identifies your issue as one we need to act directly on.
Describe anything you've already done to troubleshoot the problem, and what the result was. This will also help clarify the problem, and will help you get faster help, because people won't have to retrace your steps.
*If you guessed that by "idiot" we meant "computer," you win 50 Internet points.**
As a security precaution, CGI and PHP scripts run with different user credentials than you do when you edit your files. Although the CGI/PHP user has significantly fewer privileges overall, it is possible to create a situation where an application creates files or directories that you do not have permission to access or remove via FTP or ssh. This typically happens if an application's umask is set incorrectly; the resulting files or directories will be owned by the "web" user and will not be group or world writable. (Correct umasks are 0 or 002, depending on the expected group ownership. A umask of 0 should work for most web applications, and does not compromise security on our system the way it does on some shared hosts.)
If you get stuck with web-owned files you can't access or delete, you can regain control using the "Repossess Files" action on the Site Information panel for the affected site. However, if you find yourself doing this on a regular basis, that tends to indicate your site's permissions aren't set properly.
This is a restriction imposed by Apache. It is designed to prohibit ambiguity in determining which access controls apply to the directory.
Assume your public directory contains a subdirectory called example. If you access it via /example, you have not entered that directory. That means that the .htaccess file from your public directory would be applied, but the .htaccess file inside the example directory would not. However, if you access it via /example/, then you have entered the directory and both .htaccess files will be applied.
Now, assume that your public directory's .htaccess file allows all visitors and has directory indexing enabled. Assume that your example directory's .htaccess file allows only visitors with a certain cookie set and denies directory indexing. In this case, if it were allowed, visiting /example would produce a listing of the contents of the example directory while visiting /example/ would produce an access denied error or demand for authentication.
To prevent the confusion and security issues that such conflicting behavior would create, Apache detects attempts to access directories without trailing slashes and automatically issues a redirect to the same URI with the trailing slash appended. That way, you never have to worry about the scenario in the preceding paragraph.
Although you can't stop people from typing one in by hand, make sure you don't use invalid directory URIs internally on your site because they require this extra redirect, thus making your site appear slower.
If you find that these redirects are not using the site alias that you want, for example, if they redirect you to example.nfshost.com instead of www.example.com, then you may need to adjust your site's canonical name settings.
There are a couple of possible explanations for this.
Your site may be configured to do so. WordPress, for example, may default to using the wrong name and needs to be manually informed under the General Settings in the WordPress Admin panel sidebar to use your real domain name. If the General Settings tab is unreachable, you can also change the site name from the command line with the commands:
YourPrompt$ wp option update home https://www.example.com/
You may be entering an
invalid directory URI or something else that causes the network to redirect you. In this case, the server may not be using the name you expect in the redirected URL. (This primarily afflicts sites created prior to April 6, 2008.)
If you have problems of this nature, make sure you have appropriate canonical name settings for your site.
This error (also frequently seen as "503 Service Unavailable" or "The requested website is temporarily not available due to a resource limitation.") means there are too many total simultaneous non-cacheable HTTP requests in progress for your site. This is an extremely rare condition, but the causes, in order of decreasing likelihood, are:
For sites like CMS or blog sites that generate content dynamically, a spammer, email address harvester, or lousy web spider attempts to hit all or a large number of the site's dynamic pages at once. Our system will throw up this error to dissuade the spammer and stop them from dragging the whole server down. In this case, the message will typically only appear for a few seconds to a couple of minutes; as soon as they start getting errors, they usually move on.
This message can also occur if requests for your site content hang or take an inordinately long time to complete. In such cases, they can backlog to the point where the server feels that allowing more of them to build up would just cause a death spiral. (I.e. more requests taking longer causing more requests to take even longer, wash-rinse-repeat until nothing happens at all).
Under exceptionally rare circumstances, this message can indicate that the server that hosts your site is having severe problems. Such conditions are automatically detected and we are notified, so they tend not to persist for very long.
If your site has several hundred simultaneous visitors for sustained periods of time, it's remotely possible to hit this limit even if your connections complete very quickly. In this case, and only in this case, we will raise the limit, because this limit provides your site with important protection against all the other cases.
Please be aware that while almost everyone starts out thinking #4 is the reason that applies to their situation, the cause almost inevitably turns out to be something else. A good rule of thumb is that each possible explanation above is about ten times less likely than the one above it, so the top one is 90% likely and the bottom one is about 0.09% likely.
If this message persists long enough to cause problems, the explanation is most likely the second one. In that case, the way to troubleshoot it is to identify and resolve the cause. Coding problems that can cause this include, but aren't limited to:
unconditional long sleeps
infinite loops
issuing blocking system calls that can hang indefinitely
poorly-optimized MySQL queries
anything that serializes requests (causes them to have to wait in line and get handled one at a time)
doing too much work to process a request -- CPUs are only so fast
making network connections (e.g. DNS or HTTP) to other sites or services that are down or unreachable without a reasonable timeout
Some poorly-written WordPress and Drupal plugins have been known to cause these sorts of problems under heavy loads, particularly ones that deal with statistics or running periodic scheduled tasks.
If you have a subscription membership and open a support issuewhile the problem is occurring, we can typically identify the problem URLs for you, and may be able to give you some insight as to what they are waiting for. After the fact, it may be possible for you to get some idea of what happened by looking at your site's access logs, if they were enabled.
Please keep in mind that this limit is not some nuisance we put in at random to cause problems for our members. It is a crucial protection that keeps your site (and others') safe and available. When someone says they want it removed, we hear: "My car would go a lot faster through the mountains if it didn't skid along the guardrail every time I go around those hairpin curves! Take that guardrail out!" We know from experience that if we take out the guardrails, the car won't go faster; it will fly off the side of the mountain and end in a fiery crash. You may be willing to take that risk with your site, but since ours is a shared hosting service, we can't risk letting you take others down with you. If you want the limit raised, be prepared to show us ample concrete evidence documenting both your sustained high traffic levels and the excellent performance of your highly-optimized code.
Try the "Troubleshoot Site" action on the Site Information panel. It is pretty good at detecting site problems, DNS misconfiguration, and domain registration errors.
If that doesn't work, you haven't changed anything that may have caused this, and there is nothing listed in the announcements about something wrong right now, please contact support and provide as much information as possible about your problem. Be sure to include the name of the site you are reporting trouble with!
First, we always recommend that attack-prone sites minimize their attack profile by consciously examining the use of large files. One good example of this is using graphics compression to make images smaller, or to evaluate whether that one graphic really needs a 24 megapixel click-to-zoom version.
These steps are primarily useful if your site is attacked by a large number of different addresses, or if the addresses used change rapidly. (It's also a good way to save money and ensure a fast-loading site in the far more common not-being-attacked case, including high-usage periods like getting mentioned on Reddit.)
Second, you can edit your site's IP access controls. This is the most efficient way to block access to your site in that it will have the least performance impact on legitimate visitors. However, our system IP access controls are general purpose and not specifically designed for abuse. Therefore they return a small error message to visitors, and that still takes up some bandwidth; an attacker blocked by our IP access controls would have to hit your site about 820,000 times to use a gigabyte of bandwidth.
If you're sure someone is attempting to waste bandwidth, there is a third option you can use to eliminate as much of the response as you can. Take the following steps:
Create a zero-length file called "no" in your site's public directory. (E.g. touch /home/public/no from the ssh server.) Do not skip this step!
Add the following to your .htaccess file (replace 1.2.3.4 with the IP address to block):
Affected visitors will receive an empty "OK" response. This still includes HTTP headers, but that's all. An attacker blocked by this would have to hit your site about 3,600,000 times to use even one gigabyte of bandwidth.
There is a variant of this that saves slightly more bandwidth and may fool would-be attackers into thinking they have succeeded in taking your site down. However, it carries an additional risk: It bends the HTTP standard, and if you do not set the IP address properly, search engines who see this response will also think your site is gone and remove references to it. The code for .htaccess is (again replacing 1.2.3.4 with the IP address to block):
# Do not put this in your .htaccess unless you have read the warning above.
RewriteEngine on
RewriteCond %{REMOTE_ADDR} 1.2.3.4
RewriteRule .* . [L,G]
ErrorDocument 410 "."
This returns an HTTP "410 Gone" response and one byte of content. This has the side effect of eliminating some HTTP headers. As a result, an attacker blocked by this would have to hit your site about 4,600,000 times to use up a gigabyte of bandwidth.
If you need to block more than one IP address using the latter two techniques, combine them as in the following example:
While the only way to completely protect your site from all Internet attacks is not to put it on the Internet, we hope these options will help you defend yourself in the unlikely event that your site falls victim to a bandwidth-wasting attack.
When asking for help in our forum, we strongly recommend against replacing the name of your site with example or a domain with example.com or taking similar steps to conceal the specifics of what you're asking about.
Obfuscating the details of a question or problem forces people to guess rather than investigate. Guessing is both difficult and inaccurate. When you want other people to help you, it's a good idea to make that as easy as possible. Doing so also makes it more likely that their response will actually help.
It's also frequently the case that when people obfuscate the details of what they're asking about, they inadvertently omit the information needed to resolve their problem or answer their question. This is perfectly normal; it's frequently impossible to know what information is needed to solve a problem without knowing its solution. And if someone already knows the solution to a problem, they usually don't ask for help solving it.
So, when asking for help in the forums, we recommend providing as many specific details as possible, along with following our standard troubleshooting advice. This will almost always help you answer your question or solve your problem faster and more accurately.
If you are uncomfortable posting necessary information in the forum, you may wish to look at our subscription membership which includes an option for private support.
We have no idea. We do not determine whether your address information is correct or not. (We have no way of knowing!)
When you enter your address information, our credit card processor forwards it to your card-issuing bank. Your bank sends us one of three responses:
"Yes, that's correct."
"No, that's not correct."
"We don't support address verification." (Most banks outside the US.)
If our system tells you that the information you entered isn't correct, it's because that's what your bank told us. Your bank does not tell us why it is incorrect nor do they provide the correct information (according to them).
Consequently, any questions you have about why your address was reported as incorrect should be directed to the bank that issued your card, not to us.
Should you find yourself in this situation, you should also be aware that your bank may place a temporary pre-auth hold on the funds, even though the transaction was declined. Also, if you call your bank's customer service, they will see the pre-auth hold. Many bank customer service reps will incorrectly claim that the transaction was approved without looking into it any further.
You may also encounter this issue if you use a US-based bank, but your billing address is outside the US. We have seen several cases where the banks could get the foreign address right on statements, but their address verification system could not cope with it.
If you find yourself in this situation, for whatever reason, you have a couple of options:
Use a credit card issued by a different bank.
Use the same card (or another) to pay through PayPal.
Update your address with your bank, even if it looks correct, then wait 24-48 hours. (This is a bit of a long shot, but it helped some people when their bank's internal systems were out of sync and no one at the bank would admit it.)
The above applies primarily to US-based members and those in other countries with compatible AVS implementations. The UK, for example, uses an entirely different system. For reasons we do not fully understand, certain banks in the UK falsely return that the address (or zip) is incorrect when they should return that they do not support US-style address verification. This error on their part will cause our system to reject your card no matter what you enter for your address details. This affects about 10% of our UK members.
This could happen even if you have successfully used the card online in the past. We are not only unusually strict in address verification enforcement to protect our members and ourselves from fraud, but we are also not large enough to have specialized card processing options for the UK as many huge Internet retailers (e.g., Amazon) do.
Of course, you can try contacting your bank. But bank customer service agents are rarely trained on the intricacies of address verification. (And that goes double if they're in a country that uses a different system.) There's somebody deep in the bowels of the operations department of your bank who understands what's going on, but good luck getting them on the phone; we've never had a report that a member accomplished that.
We are very sorry for the inconvenience caused to the handful of our members who run into these kinds of problems. They affect only a few, and the cause is completely beyond our control, but it's still endlessly frustrating.
This error occurs when a CGI script exits before writing a complete set of HTTP response headers (not even an empty one). It can happen for a variety of reasons:
The script may be dying before it writes any output. This can happen, for example, to perl scripts if they have a dependency that cannot be resolved.
If there is a problem with the hashbang (#!) line of the script. Uploading the script from a Windows machine in binary mode can cause this, or the path to the CGI interpreter you are using could be incorrect, for example attempting to use #!/usr/bin/python instead of #!/usr/local/bin/python.
A compiled application could be missing a shared library dependency. You can use ldd or try running the script from the ssh command line to check shared library dependencies.
There could be a system problem preventing the execution of the script.
In all cases, the best thing to do is make sure your site's error log is enabled and see what it says about the problem. If the error output says that there is a system problem preventing execution of your script, or if there is no message in the error log at all, review your options on the Support tab. Whichever option you choose, please indicate the URL of the script you're having trouble with. In many cases, it will be easier to debug a problem if you can provide a simple example at a publicly available URL.
There are a few incompatibilities between Apache 2.2 and 2.4. These are described in detail in the Apache 2.4 documentation.
In most cases, the source of compatibility problems is an .htaccess file. If it is not compatible with Apache 2.4, it will cause your site to return "500 Internal Server Error."
To narrow down the specific cause, we recommend that you enable your site's error log in the member interface (if you haven't already). Once it is enabled, access the site a few times to exercise the error, and then the error_log file in your site's logs directory should point you directly to the problem.
The most common example comes from using the Order directive to restrict access to certain content. It has been completely removed from Apache 2.4, but is still very common in example files and configs distributed with many web applications that haven't been updated yet.
To update a 2.2 .htaccess file containing something like:
Order deny,allow
Deny from all
the 2.4 equivalent of both lines would be the single line:
Require all denied
to deny all access and:
Require all granted
to allow it.
Other 2.2-specific configuration directives that have changed in 2.4 can be similarly adapted. See the Apache documentation linked above for complete details.
If you get a message similar to the following when accessing your WordPress site's control panel:
The requested URI could not be accessed.
Or, for older versions of PHP:
Warning: Unknown: failed to open stream: Permission denied in Unknown on line 0
Warning: Unknown: failed to open stream: Permission denied in Unknown on line 0
Fatal error: Unknown: Failed opening required '.../wp-login.php' (include_path='...') in Unknown on line 0
this indicates that your WordPress login page has been temporarily disabled to protect your site, your wallet (and us, other sites we host, and the Internet at large) from a hostile attacker trying to force their way into your site.
When this happened, an email was sent to you with the full details, including how to resolve the situation. You should have that email. If you don't, stop and make sure your member contact email address is up to date and that your email system is not marking messages from us as spam.
When you next need to log in to your WordPress site, all you need to do is reset the permissions of your wp-login.php script. The recommended permissions for this script are 0644. This is typically done with a command like:
YourPrompt$ chmod 644 /home/public/wp-login.php
(If your blog is not installed in /home/public, you may have to adjust this.)
You can run this command from the shell or using the "Run Shell Command" action on the Site Information panel for this site in our member interface. Just edit the permissions of the wp-login.php file and make sure that it is readable by everyone.
If you have frequent problems with this, you may wish to investigate the security options presented in the "Stopping Login Attacks" and "General Security" sections of our Advanced WordPress Configuration guide.
This indicates that something unusual happened on that page that the system thinks we need to know about.
We're committed to increasing the quality of our software, so we're constantly implementing new checks and stricter language features. So in almost every case, the "bug" is just the system letting us know that it found something that isn't technically wrong, but could be better. But sometimes, it's a real bug. Either way, we'll be automatically notified, and we'll check it out and fix it.
Most of the time, you can ignore the icon. But if you see one, it's a good indication to double check that everything happened as you expect.
Treat such a request as the world's most misleading "permission denied" error.
When WordPress fails to write to a file due to a permission error, it has some very old code that tries to work around the problem by asking for FTP information. But these days FTP is dangerously insecure and unsupported. Do not provide your NearlyFreeSpeech.NET credentials; it won't work and could potentially get you hacked.
If it happens during a media upload, review the "Enable file uploading" section of our Installing WordPress guide. It will show you how to set your site up with the permissions to make that work.
This also comes up if you attempt to have WordPress update itself over the web. Don't. It requires major security compromises that will turn the next vulnerability discovered in WordPress, PHP, your blog's theme or any active plugin into a complete takeover of your entire site. We will not assist you to do that.
To safely update WordPress and its themes and plugins, use the wp-cli command line tool, as documented in the "Upgrade WordPress" section of the Installing WordPress guide.
