In cPanel, an addon domain or subdomain files usually exist as a subdirectory of your public_html directory or your account's home directory. The exact location used is configurable by the user when the addon domain or subdomain is added to cPanel. Before adding, modifying, or removing one of these, it is important to know there is an administrative setting in WHM that directly affects the ability to control the location of files for these new “secondary” domains.
Within the Server Configuration >> Tweak Settings section of WHM, there is a setting under Domains titled Restrict document roots that implements a restriction on the creation or modification of subdomains. WHM describes this settings as:
“This option mandates that document roots for all newly-created websites must reside under the document root for the account’s primary website. This option does not apply when you transfer or restore accounts.”
When this setting is On, which is the default value for WHM installations, any subdomain root folder must either use the public_html folder of the primary domain, or a folder nested within that public_html folder.
Should Domain Root Be Restricted?
So for an example of the affects this setting has, let us consider a hypothetical situation where the primary domain for a cPanel account is demo.cozaq.com, with a cPanel username of democozaq. This domain’s web root folder location would then be /home/democozaq/public_html/. If you then added the subdomain mysub.demo.cozaq.com, the root folder for this new subdomain could be any of the following options:
But could not be any of the following:
So as you see, the subdomain folder would be restricted to being contained within the cPanel account’s primary domain public_html folder. This restriction has some implications that we consider important to understand before deciding how to configure this setting:
- In the example of using /home/democozaq/public_html/mysub/ as a subdomain folder for mysub.demo.cozaq.com, this subdomain’s content could also be potentially accessed from the URL https://demo.cozaq.com/mysub/, which may be extremely undesirable to some clients.
- Another common example of this would be if a site had a “pretty URL” structure and wanted to have an article detailing support plans or instructions at https://demo.cozaq.com/support/ but also a support portal or help center at the subdomain https://support.demo.cozaq.com/. This scenario would either not be possible, or would at least be potentially difficult to execute properly due to the subdomain’s direct accessibility from that URL.
- If an primary domain website contains a vulnerability allowing unintended reading or writing of site files, this vulnerability would then also allow reading or writing to any subdomain file folders as well. Depending on the severity of the vulnerability, this may be possible with all files within the cPanel account anyway, but there are some less severe vulnerabilities that can be “contained” by separating domain roots more completely.
- This is even more important for addon domains that may be completely unrelated to the primary domain, and thus end up harming one or both site’s search engine ranking due to being falsely identified as containing duplicate content, in addition to potentially confusing visitors to either site.
- Forcing this restriction does protect against accidentally providing access to folders not intended to be web-accessible, such as the mail, public_ftp, or logs folders by creating subdomains referencing these locations.
Note: The hosting of multi-domain site solutions, such as WordPress Multi-Domain, and allowing addon domains or subdomains to relatively include or refer to the primary domain files located in the public_html folder directly, are possible with either configuration option.
Managing Addon Domains and Subdomains
To learn how to manage addon domains or subdomains in cPanel, please refer to the Creating and Modifying Subdomains in cPanel companion article.