Identify what the server is refusing
A 403 response is an access decision; compare the exact URL with the domain's error log before changing permissions or rules.
The scope matters: a 403 on one path needs a different response from a domain-wide refusal. It does not by itself say which rule caused the refusal. A missing index file with directory listing disabled, a deliberate access rule, a file or parent directory that the web server cannot read, or a web application’s own authorisation response can all look similar in the browser. Begin with one exact failing URL, its time and whether it affects one file, one directory or the whole domain.
This guide concerns a website hosted in an account that exposes DirectAdmin. It does not assume Apache, shell access or permission to change server configuration. If DirectAdmin itself returns 403 when you sign in, report the panel URL and account error to the host; website file changes are unlikely to repair panel access.
Protect the working configuration
Record the site’s last known working time and recent deployments, redirects, security-plugin updates or document-root changes. Test a known public file and the homepage from a private browser window to avoid a logged-in application view. Note whether the response is a plain web-server error or the application’s branded page. If the failure began after a change, preserve a copy of the affected file or rule before editing it. Check that a restorable site backup exists if the repair may affect application files.
Locate the correct document root in DirectAdmin’s domain or subdomain settings. DirectAdmin supports document-root overrides, and a new subdomain may not use the folder you expect. The account’s File Manager can confirm whether an index file such as index.html or index.php exists in the actual root; it cannot prove which rule is denying access.
Read the matching domain error log
Open the domain’s error log through the panel if your account exposes it, or ask support for the entries around the failed request. DirectAdmin’s server documentation identifies domain-specific Apache logs such as /var/log/httpd/domains/example.com.error.log; that path is an administrator-side example and may differ with the web stack. Search for the exact time, hostname and URL. Avoid posting complete logs publicly, as they can contain paths, IP addresses or request details.
A log entry about .htaccess being unreadable suggests directory traversal, ownership or file-read access needs investigation. A “directory index forbidden” message points to the index file or directory listing policy. An explicit deny, authentication rule or application middleware message points to a policy decision. If the log has no matching request, confirm that DNS and any proxy route the hostname to this hosting account before changing files.
Use the evidence to choose one bounded action
For a missing index, verify the deployment path and restore the intended index file from the release or backup. Do not enable directory browsing to make an empty folder appear to work. For an access rule, identify the owner of the .htaccess, application or security rule and compare it with the last working version; revert only the confirmed recent change. A 403 protecting an admin area or private file may be correct.
For a permission error, check the named file and each parent directory in its actual path. The web process needs appropriate read access to files and traversal access to directories, but the correct ownership and mode depend on the server’s handler and isolation model. Ask support to correct account ownership if needed. Do not recursively set everything to 777, disable a security module or grant the web server broad write access. Such changes can expose customer data and hide the original fault.
For example, a 403 limited to /private/ suggests a scoped rule or directory setting. Check the matching log and intended protection before removing any access control.
Verify the repair and its boundary
Repeat the exact failing request and a known working request, then check the new response status and log. Test the homepage, a deep page and an intentionally protected path so the repair has not made private content public. If a cache or CDN is in front of the site, compare its response with the origin using a host-approved method. Remove temporary test files and record the precise file or rule changed.
If the site remains blocked, restore the saved rule or file state and send support the hostname, URL, timestamp, observed status, relevant redacted log line and recent change. The host can inspect web-server and account-level controls you cannot see; the customer or application owner remains responsible for application policy unless the agreed service says otherwise.
Common questions
Is 403 the same as a missing page? No. A normal missing resource is usually 404; a directory with no index may still return 403 when listing is disabled.
Should I remove .htaccess to test? Inspect the log and compare a saved version first. Removing it can disable redirects or access protection.
Can a file-manager permission display settle the cause? It helps, but parent directories, ownership, server rules and application responses also matter.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.