Overview

When you run the WHM Security Advisor (or cPanel Security Advisor) on a server running CloudLinux OS, you may encounter the following warning:

“Apache Symlink Protection: Problems with CloudLinux sysctl settings” or “Apache Symlink Protection CloudLinux sysctl Error”

This error indicates that the kernel-level symlink protection feature — known as SecureLinks in CloudLinux — is either not active, incorrectly configured, or pointed at the wrong Group ID (GID) for the Apache user. As a result, Apache’s symlink protection is not functioning as intended, leaving your server potentially exposed to symlink-based attacks.

This knowledgebase article provides a complete, step-by-step resolution guide — covering root cause analysis, configuration changes, verification, and troubleshooting — so your server passes the Security Advisor check and remains protected.

What Triggers This Warning?

The WHM Security Advisor performs a series of automated checks against your server’s configuration. The symlink protection check specifically validates that:

• The CloudLinux kernel parameter `fs.enforce_symlinksifowner` is set to `1` (enabled).
• The CloudLinux kernel parameter `fs.symlinkown_gid` is set to the correct Group ID (GID) of the user account that Apache runs under (typically `nobody` on cPanel servers).

The warning is triggered when one or both of the following conditions exist:

• `fs.enforce_symlinksifowner` is `0` or missing | SecureLinks protection is completely disabled
• `fs.symlinkown_gid` is set to the wrong GID | Protection runs but does not apply to Apache requests
• The sysctl config file is missing entirely | Settings revert to defaults (off) after reboot
• Settings exist in file but were never applied | Kernel is running stale/old values

How Apache Symlink Protection Works on CloudLinux

What Is a Symlink Attack?

A symbolic link (symlink) is a file that points to another file or directory. On shared hosting environments, a malicious user could create a symlink pointing to a sensitive file (such as another user’s `wp-config.php` or `/etc/passwd`) and then use Apache to read that file through a web request — bypassing normal file permission controls.

How CloudLinux SecureLinks Addresses This

CloudLinux SecureLinks is a kernel-level feature that prevents symlink traversal attacks by enforcing the following rule:

Apache is only allowed to follow a symlink if the symlink’s owner matches the owner of the directory in which the symlink resides.

This protection is enforced at the kernel level (not the application level), making it much harder to bypass. It is activated through sysctl kernel parameters:

• `fs.enforce_symlinksifowner` — Turns the protection on (`1`) or off (`0`).
• `fs.symlinkown_gid` — Specifies the GID of the process (Apache/`nobody`) that the protection applies to.

When the GID in the sysctl setting does not match the actual GID Apache is running as, the kernel protection is effectively blind to Apache’s requests — even if `enforce_symlinksifowner` is enabled.

Prerequisites Before You Begin

Before proceeding, ensure you have the following:

• Root SSH access to your server (or access to WHM Terminal).
• Your server is running CloudLinux OS (this fix does not apply to standard CentOS/AlmaLinux without CloudLinux kernel).
• You have a recent backup or snapshot of your server (always recommended before modifying kernel parameters).
• You are comfortable running basic Linux shell commands.

To confirm CloudLinux is installed and running, execute:

uname -r

The output should contain `lve` in the kernel name, for example:

5.14.0-284.30.1.el9.cloudlinux.x86_64

If `cloudlinux` does not appear, SecureLinks may not be available on your system.

Step 1 — Verify the GID for the “nobody” User

CloudLinux’s SecureLinks protection is applied to a specific Group ID (GID). On most cPanel servers, Apache runs as the system user `nobody`. However, the GID for `nobody` can differ between distributions and server configurations.

Never assume the GID is 99 – Always verify it first.

Connect to your server via SSH as root and run:

id nobody

Expected Output

uid=99(nobody) gid=99(nobody) groups=99(nobody)

What to Look For (Field | Meaning)
`uid=99` – User ID of nobody
`gid=99` – Group ID — this is the value you need
`groups=99` – Groups the user belongs to

In this example, the GID is 99. Write this number down — you will use it in the next step.

Note: On some systems (particularly those running AlmaLinux 8/9 or RHEL 9-based CloudLinux), the GID for `nobody` may be `65534` instead of `99`. Always use the value returned by the `id nobody` command on your specific server.

Step 2 — Update CloudLinux sysctl Settings

The sysctl configuration for CloudLinux is stored in a dedicated file. You need to add or update two specific kernel parameters in this file. Edit or Create the Configuration File – CloudLinux uses a dedicated drop-in configuration file for its kernel settings:

nano /etc/sysctl.d/90-cloudlinux.conf

If this file does not exist on your server, you can create it — or fall back to the main sysctl configuration file:

Add or Update These Two Lines

Inside the file, ensure the following two lines are present:

fs.enforce_symlinksifowner = 1
fs.symlinkown_gid = 99

Important: Replace `99` with the GID value you obtained from the `id nobody` command in Step 1, if it was different.

Save and Exit the file:

• In nano: Press `CTRL + O` to save, then `CTRL + X` to exit.

• In vim: Press `ESC`, then type `:wq` and press `Enter`.

Step 3 — Apply the Changes Without Rebooting

After saving the file, you must instruct the running kernel to reload and apply the new sysctl settings. This does not require a server reboot.

sysctl -p /etc/sysctl.d/90-cloudlinux.conf

Expected Output

fs.enforce_symlinksifowner = 1
fs.symlinkown_gid = 99

If you see the values echoed back as shown above, the settings have been applied to the live kernel successfully.

If You Edited `/etc/sysctl.conf` Instead

Use this command to apply all sysctl settings from the main config file:

sysctl -p

Step 5 — Re-run the WHM Security Advisor

Once the sysctl settings are verified, return to WHM and re-run the Security Advisor to confirm the warning has been resolved.

Steps in WHM

1. Log in to WHM at `https://your-server-ip:2087`.
2. In the left sidebar search box, type Security Advisor.
3. Click Security Advisor from the results.
4. Click Run Security Advisor.
5. Wait for the scan to complete and review the results.

The warning “Apache Symlink Protection: Problems with CloudLinux sysctl settings” should no longer appear. If it does, please seek assistance from your server administrator or hosting provider. Even if still, you need further assistance, then feel free to contact myglobalHOST and we will be more than happy to assist.