Web Server Permission Errors
All websites hosted on Alentus servers are initially set up with several security measures that relate to file and folder permissions. The permissions have been set to prevent malicious users from tampering with your website content, as well as to prevent any files or scripts to be executed that can cause operational problems with the web server.
This document discusses the default settings for a newly created website and covers common problems you may encounter with regards to website permission settings. Before you report permissions problems to our Support team, we ask that you read this document and determine if you can resolve the problem on your own.
The following topics are discussed further in this document:
Execute Permission Errors
Read Permission Errors
Write Permission Errors
Important Notes
Execute Permission Errors
A typical EXECUTE error that might be encountered while trying to execute an ASP or Perl script might be:
HTTP 403.1 Forbidden: Execute Access Forbidden
Internet Information Services
This error is occuring because the webserver is configured with security privileges set to prevent unauthorized binary executables from running.
If this is occuring from an ASP script then it is possible you are attempting to call an executable program somewhere in your script. Normally there is no need to call executable programs from ASP scripts, as advanced application programming is usually done by instantiating a COM component from within an ASP script, rather than calling external executables.
If the error is occurring from in a FrontPage site, you may need to make changes to the site to ensure that all objects in your site are being properly referenced on the web server. A common error is to have invalid file references. Usually this turns out to be a hard-coded reference to files in C:\Inetpub\wwwroot found somewhere inside your published FrontPage site. When your site gets published to our web server, it is placed on a separate drive from drive C: and any hard-coded references to C: will cause your forms and other FrontPage functions to fail.
Another potential problem that can cause this error when using FrontPage or an ASP script is an invalid permissions setting on the webserver. If you suspect this is the case, please fill out a Problem Report in the Administration Console.
If you are seeing this error from an ASP script and cannot resolve it on your own, please fill out a Problem Report from the Administration Console and our support staff can look into it for you.
If 'execute forbidden' errors are occurring when using a Perl script, we will likely need to configure a cgi-bin folder for you, and apply the necessary Perl script mappings and permissions. If you require a cgi-bin to be setup, please contact Technical Support.
Read Permission Errors
Read errors occur when the web server does not have the necessary permissions to deliver the contents of a file to the end user. Read permission violations are usually handled one of two ways. You may be prompted for a username and password, or you may see a read access error in the browser.
A typical READ error that might be encountered is:
HTTP Error 403
403.2 Forbidden: Read Access Forbidden
This error occurs when you are trying to access a file or folder that is does not have web server READ permissions. Typically, read errors occur if you try to to view the /database or /log folders from your browser.
To prevent unauthorized access to your database files and site logs, READ privilges have been revoked on the /database and /log folders. There may also be other folders in your site that also have the web server READ privilges revoked if we have set up any password protected folders for you.
Depending on how a READ protected folder is set up on the server, you may be able to access it using your FTP username and password. If you are receiving WebTrends reports and try to access the /log folder to view them, you will be prompted for a password. This is an example of a password protected folder. Your FTP credentials will allow you access to the files inside the /log folder so you can see your WebTrends reports.
The /database is completely protected from web access. Browser requests to this folder will not be completed and an error will result. Note that your scripts still can access the /database folder. ASP scripts that contain database requests to .MDB files in the /database folder have full READ-WRITE permissions when using ODBC or other ADO database connections.
Write Permission Errors
Write permission errors are usually encountered when running ASP scripts that either save data to your database or create files on the webserver.
If you are seeing errors while trying to INSERT or UPDATE to your database, and your database file in the root folder or in a folder you have created, it is likely that your scripts do not have WRITE privilges on the database. If this is the case, you should move your .MDB files to the /database folder where your scripts have full READ-WRITE privileges. Also, the /database folder is protected against anonymous web access which prevents anonymous end users from downloading your database files.
A typical WRITE error that might be encountered while trying to create a new file or folder might be:
Microsoft VBScript runtime error '800a0046'
Permission denied
You may run into problems with file systems permissions when using the FileSystem object and other related objects. If you are receiving permissions errors, it is usually because your script is running under the webserver's IIS account (the IUSR account) which does not have permissions to make the requested modifications to the file system.
This occurs because the webserver is configured with its security privileges set to prevent unauthorized changes to your website through use of the IUSR account. Note that this does not mean you cannot change your website files. When you login with FTP, you are logging in using your own account (your FTP or FrontPage userid and password), which does have permissions to create, modify and delete files.
To allow your scripts the ability to create or update files from inside your website, we need to grant explicit WRITE permissions to the IIS web server account on the folder where the files are. Normally, we do this for a sub-folder under your root, and then your scripts can create and update files inside the new sub-folder. We normally don't do this at the root level, because it can cause major problems if there are bugs or other problems in the script.
Usually, the data files you create are static content files only. We set permissions on your writable folder to prevent scripts from being run from same folder. This is a safety precaution to help prevent unauthorized scripts from executing on the server.
Generally, you can create .html files, images and other static content, but you cannot create ASP, Perl or other scripts and then have them run from the writable folder. If you need to be able to execute generated scripts, we may allow this pending a review of your code.
In you have scripts that use the FileSystem object, you can use the Server.MapPath function to find the physical path to the your writable folder. Once you have the path, you can use it to construct the actual file and folder names for use with the FileSystem object.
The example below demonstrates how to create a new sub-folder inside your writable folder:
Dim objFSO
Dim strPath
Server.CreateObject("Scripting.FileSystemObject")
strPath = Server.MapPath("/data") & "\new_folder"
objFSO.CreateFolder(strPath)
Important Notes
We do not take any responsibility for scripts that cause problems. If your script wipes out your site or if it causes other problems that require intervention by our Support staff, you may be liable for support charges. You may also need to reload any lost content from your own backups as we cannot guarantee that the backups we have of your site would be valid if problems are not corrected immediately.
It is always a good practice to test your code locally before posting it to the webserver. Due to the nature of scripts that modify the filesystem, it is especially important that these are well tested. We ask that you do not upload untested code to the servers, as experience has shown that even the simplest code changes often have errors that will show up in production if not fully tested before deployment.