Understanding symlinks and hosting directory access

Identify who owns the link and target and why the application uses it. Back up configuration before changing a deployment layout. Do not assume a link grants access that the account would otherwise lack.

1. Use File Manager or an authorised read-only shell listing to distinguish the link from a real directory. Record its target path.
2. Check that the target exists and belongs within the permitted account scope. A broken link can survive after a deployment folder is renamed or removed.
3. Review the application’s supported directory layout and the provider’s symlink policy. Shared-hosting isolation can intentionally prevent cross-account targets.
4. If a target path changed, update the deployment configuration through its supported process rather than copying arbitrary links from another server.
5. Test both direct application behaviour and web requests through the linked path. Keep private storage inaccessible to public HTTP requests.

Use an authorised hosting-account terminal to inspect the suspected symbolic link. Replace current with the actual link path. These commands display the link and its target text; they do not change it or grant access to a directory outside your account.

ls -ld /home/CPANEL_USER/public_html/current
readlink /home/CPANEL_USER/public_html/current

Read the result: The long listing identifies the item as a symbolic link and shows its destination. A relative destination is interpreted from the directory containing the link, not from whichever directory your shell currently uses. A dangling target or a target blocked by hosting isolation can explain an access error.

Compare the target with the intended release directory and ownership before changing deployment settings. A valid symlink does not override the destination's permissions, open_basedir rules or web-server symlink policy. Ask support to confirm permitted use if the design crosses account or filesystem boundaries.

The link should resolve to the intended permitted location and expose only the data the application requires. Confirm the apparent folder is not unexpectedly pointing to another site’s release.

If the server refuses to follow a link, do not disable global protections or broaden another account’s permissions. Use an approved directory layout or ask support about a suitable deployment design.

Removing only the symbolic link leaves its target in place. Recursively deleting contents reached through a link is a different operation. File tools and command options vary, so inspect the object and avoid recursive cleanup commands until you know exactly which real directory they will affect.

• Moving an addon domain to a new document root
• Why can I see a file but not edit or delete it?
• Deploying a cPanel Git repository with .cpanel.yml
• Adding an SSH public key to a cPanel account

• cPanel: Symlink Race Condition Protection
• cPanel: File Manager

• cPanel Terminal