Ubuntu 16.04 / Apache / How to Fix Access to the javascript Folder

If a 403 Forbidden appears when accessing /javascript/ on Apache in Ubuntu, check whether the Apache alias created by the javascript-common package conflicts with the site's path. However, 403 errors can also occur due to permissions or directory listing settings, so you should check the actual file response and server settings together before taking action.

Things to Check First

This article is based on an environment using Apache 2.4 on Ubuntu. The original article covered Ubuntu 16.04 LTS, which is an old version whose standard support and general Ubuntu Pro support have ended. Verify the conditions for additional legacy support and plan to migrate to a supported version. The support schedule can be checked at Ubuntu Security Maintenance Schedule.

The issue of seeing a 403 when opening only the /javascript/ folder address in a browser and not being able to load the JavaScript files inside it are different problems. If there is no default index file in the directory and directory listing is turned off, the folder address may return 403, but individual files can still be served normally.

Check the URL and status code of the file that actually failed in the Network tab of the browser's developer tools. For example, check whether /javascript/app.js referenced by the site returns 200, 403, or 404, and also inspect the response content. Even if it shows 200, content other than the intended JavaScript file may be returned.

What is an alias conflict?

In some Ubuntu and Debian environments, the active javascript-common configuration may include aliases like the following. When this configuration is applied, the URL path /javascript can point to a directory other than the one under the site's document root.

Alias /javascript /usr/share/javascript/

For example, if Apache looks for the requested /javascript/app.js under /usr/share/javascript/, files in the original site folder may not be served. If the target file does not exist, a 404 may appear, and if access to the target is denied or directory listing is not allowed, a 403 may appear. Do not conclude an alias conflict based on the status code alone.

This alias is related to requests where the first path segment of the URL is /javascript. Not all javascript folders under other segments, like /assets/javascript/app.js, automatically match that alias. The actual mapping and priority can vary depending on virtual hosts, other aliases, redirects, and rewrite rules. You can check path matching and processing order in the Apache Alias documentation.

Check active settings and error logs

Connect to the server to verify the Apache version and virtual hosts. The following searches find relevant strings in the configuration directories, and unused settings may also appear in the results.

apache2 -v
sudo apache2ctl -S
sudo grep -R -n -i javascript /etc/apache2

If /etc/apache2/conf-available/javascript-common.conf appears in the results, check its contents and verify whether it is actually activated and linked to /etc/apache2/conf-enabled/. Also, review virtual host-specific settings and other URL rules. If the file is missing or the alias is disabled, do not assume that this setting is the cause.

ls -l /etc/apache2/conf-enabled/javascript-common.conf
sudo cat /etc/apache2/conf-available/javascript-common.conf

If you get a message that the file or symbolic link does not exist, then the installation or active state is different. Check the Apache error logs at the time of the request to see the actual path and errors found. In Ubuntu's default configuration, /var/log/apache2/error.log may be available, but log paths can differ for each virtual host.

sudo tail -n 50 /var/log/apache2/error.log

Choose a Resolution Method

If it is possible to change the file path on the site, use a path like /assets/js/ that does not overlap with the alias, and also modify the HTML script address and build settings. If there are pages, caches, or external links using the existing address, check the impact of the change and request the actual files again after deployment. Simply renaming the folder while keeping references unchanged will result in existing pages being unable to find the file.

If you need to keep the existing /javascript address, the server administrator can review the dependencies of all virtual hosts and packages before changing or disabling the alias. Disabling the javascript-common setting may also alter addresses used by other sites or packages, so first investigate the impact and prepare recovery measures. Editing the package configuration file directly can make management more complicated during package updates.

The following are options when you have confirmed that the setting is enabled and not used by other services. This command can affect the entire Apache configuration of the server. If the syntax check fails after execution, do not reload; resolve the cause or re-enable the configuration first.

sudo a2disconf javascript-common
sudo apache2ctl configtest

Reload the configuration only if the syntax check confirms Syntax OK. The service name may vary depending on the environment.

sudo systemctl reload apache2

To revert, reactivate the setting with the following commands, and reload only when the syntax check succeeds.

sudo a2enconf javascript-common
sudo apache2ctl configtest && sudo systemctl reload apache2

Check after changes and other causes

Request the exact file URL that failed before the change again, and check the status code and file content. Clear your browser cache or set your developer tools to not use the cache, then check the network requests and console errors on the page. Also, inspect other sites or packages that used the existing /javascript path.

If the alias is not the cause or 403 remains after the change, check Apache's Directory·Location access rules, file read and parent directory access permissions, symbolic link settings, and default index files and directory listing policies. Do not randomly allow all access or enable directory listing to remove the error, as it could expose files you do not intend to make public; instead, first verify the actual necessary files and policies.