cphorde and .cagefs in cPanel: What They Are and Whether You Can Delete Them

Why Are .cphorde and .cagefs Showing Up in My cPanel Home Directory?

If .cphorde or .cagefs appears directly under /home/USERNAME/, its presence alone does not indicate a compromised account. Linux hides names beginning with a dot by convention, and hosting software uses many such directories for account-specific configuration and runtime data.

The first useful check is the full path. A service directory under the account home is one thing; a similarly named directory unexpectedly placed under a website's document root is another. Before looking at timestamps or scanning individual files, establish exactly where the directory lives.

pwd
ls -lad ~/.cphorde ~/.cagefs 2>/dev/null
realpath ~/.cphorde 2>/dev/null
realpath ~/.cagefs 2>/dev/null

For a normal cPanel account, the paths you are investigating will usually resemble:

/home/USERNAME/.cphorde
/home/USERNAME/.cagefs

That is different from finding something such as:

/home/USERNAME/public_html/.cphorde
/home/USERNAME/public_html/.cagefs

A directory under public_html sits inside the web application tree. Do not assume it is legitimate merely because its name resembles a known system directory. Check who owns it, what it contains, and how recently the files changed.

In cPanel File Manager, these directories may remain invisible until Settings → Show Hidden Files (dotfiles) is enabled. FTP and SFTP clients can have a similar option, so a user may work with the same hosting account for years before noticing them.

Once the location is confirmed, identify which subsystem created the folder. That distinction matters because .cphorde and .cagefs have very different cleanup rules.

What Is .cphorde, and Why Can It Still Exist After Horde Was Removed?

If your cPanel Webmail offers Roundcube but the account still contains .cphorde, that does not mean Horde is secretly running. On older cPanel systems, .cphorde stored per-account Horde data, including an SQLite database commonly named horde.sqlite. cPanel removed the Horde webmail interface in cPanel & WHM version 108, but filesystem leftovers can survive an upgrade, account transfer, or restoration from an older backup.

cPanel also migrated Horde calendars and contacts toward Roundcube during the version 108 transition. An old .cphorde on a current server is therefore normally a legacy-data question, not proof that Horde remains an active webmail client.

What Files Can Be Stored in .cphorde?

Do not guess from the directory name. Inspect it:

ls -lah ~/.cphorde
du -sh ~/.cphorde 2>/dev/null
find ~/.cphorde -maxdepth 2 -type f \
-printf '%TY-%Tm-%Td %TH:%TM %s %p\n' 2>/dev/null | sort

On a legacy account you may encounter horde.sqlite. Its presence tells you that Horde-related data existed for the account; it does not tell you whether any of that data is still needed. Check the current Webmail environment, Roundcube contacts and calendars, backups, and the history of the account before removing anything.

The size also matters. If the directory is only a few megabytes, deleting it will not solve a serious quota problem. In that case, the risk of losing useful data is larger than the disk-space benefit. If it is unexpectedly large, inspect individual files instead of treating the whole directory as a single disposable object.

Why Is .cphorde Still Present If Webmail Uses Roundcube?

Software removal and account-data removal are separate events. A server can stop providing Horde while old per-user files remain in home directories. The account may also have been migrated from another cPanel server, restored from an older archive, or preserved through several major upgrades.

A common edge case is an account restored from a historical backup onto a newer server. The new server may have never provided Horde at all, yet the backup can bring the old .cphorde tree with it. In that situation the directory tells you something about the account's history, not the current server configuration.

One version-specific detail matters for old migration guides: cPanel's Horde calendar/contact export scripts existed only during the older transition period and were later removed. If you find an old guide that depends on such scripts, check the installed cPanel version before following it.

What Is .cagefs, and Why Does CloudLinux Create It?

You run du and discover that .cagefs is one of the largest hidden directories in the account. Before deleting anything, check whether the user is actually inside CloudLinux CageFS. The directory can contain active runtime data, and its mere presence does not tell you whether CageFS is currently enabled.

.cagefs belongs to CloudLinux CageFS, the filesystem isolation layer commonly used on shared hosting servers. It is not a standard cPanel feature: a cPanel hosting server may run with or without CloudLinux CageFS, including on plain AlmaLinux, Rocky Linux, or another supported operating system.

CageFS gives each hosting account an isolated view of parts of the filesystem. Some writable paths visible to the user inside that environment map to real storage underneath the user's .cagefs directory.

What Is Stored in .cagefs/tmp?

Each CageFS user can have a private /tmp. On the real filesystem, that location can be:

/home/USERNAME/.cagefs/tmp

Applications can write temporary data there. PHP may also create session files in a temporary directory depending on its session.save_path configuration. CloudLinux additionally supports per-user PHP session paths under .cagefs.

This is why deleting .cagefs is fundamentally different from deleting a browser cache directory. A directory named tmp does not automatically mean that every file below it is disposable at any moment.

How Does .cagefs Relate to PHP Selector and Alt-PHP?

CloudLinux can expose Alt-PHP session directories through CageFS per-user mounts. A path visible inside CageFS as something similar to:

/opt/alt/phpXX/var/lib/php/session

can have its real per-user storage beneath:

/home/USERNAME/.cagefs/opt/alt/phpXX/var/lib/php/session

That is one reason damaged permissions under .cagefs can surface as PHP Selector or application errors instead of an obvious "CageFS directory problem." The symptom may appear in PHP while the broken state lives lower in the filesystem layout.

With root access, verify CageFS instead of inferring its state from the directory name:

/usr/sbin/cagefsctl --cagefs-status
/usr/sbin/cagefsctl --user-status USERNAME

The first command checks global CageFS status. The second reports whether CageFS is enabled for that specific account. Exact wording can differ with the server configuration, but the important part is whether the user is currently included in or excluded from CageFS.

You can then inspect the top-level usage without modifying anything:

du -xhd1 /home/USERNAME/.cagefs 2>/dev/null | sort -h

What If CageFS Is Disabled but .cagefs Still Exists?

A leftover .cagefs directory does not prove that CageFS is active for the user. An account may have been disabled in CageFS after using it previously, migrated between servers, or restored from a backup containing old CageFS-related data.

A typical support mistake is to see /home/USER/.cagefs and immediately assume that every file inside it is live. Check the user status first:

/usr/sbin/cagefsctl --user-status USERNAME

If the command reports that the user is disabled or excluded, continue with read-only inspection before cleanup:

ls -lad /home/USERNAME/.cagefs
du -xhd1 /home/USERNAME/.cagefs 2>/dev/null | sort -h
find /home/USERNAME/.cagefs -maxdepth 2 -type f -ls 2>/dev/null

Also confirm that the account is not simply in a transitional state during migration, restoration, or configuration changes. The correct conclusion is not "disabled means delete it." The correct conclusion is "disabled means the directory is not enough evidence of an active dependency; now inspect the remaining data and server state."

How Can You Tell .cphorde and .cagefs Apart Before Deleting Anything?

The names look similar because both are hidden directories in an account home, but that is almost where the similarity ends. Treat .cphorde as a legacy-data problem and .cagefs as a potentially active runtime and isolation problem.

A quick read-only check for both directories is:

ls -lad ~/.cphorde ~/.cagefs 2>/dev/null
du -sh ~/.cphorde ~/.cagefs 2>/dev/null

If .cphorde is tiny and contains only historical Horde data while .cagefs contains current temporary or session files, they already require different treatment. If only one exists, that is also normal: not every modern account retains Horde data, and not every cPanel server runs CloudLinux.

Is It Safe to Delete .cphorde on a Modern cPanel Server?

On a current cPanel server, an old .cphorde can often be removed eventually, but only after you confirm that the legacy Horde data is no longer needed. Version number alone is not enough reason to run rm -rf.

Start with three read-only checks:

du -sh ~/.cphorde 2>/dev/null
ls -lah ~/.cphorde 2>/dev/null
find ~/.cphorde -maxdepth 2 -type f -ls 2>/dev/null

If you find horde.sqlite, assume it may contain legacy data until proved otherwise. Check whether required contacts and calendars are present in the current Roundcube environment and whether you have a usable backup.

When a dependency is uncertain, rename first, delete later is safer than immediate irreversible removal. After you have verified that the account no longer relies on the data, a staged test can be preferable:

mv ~/.cphorde ~/.cphorde.backup

Do this only after confirming that the destination does not already exist and that you have another backup if the data matters. Renaming does not save disk space; it is a dependency test. Continue using Webmail and verify the data that matters before considering permanent deletion.

Also be careful with old tutorials that instruct administrators to use historical Horde migration utilities. Commands available during the Horde-to-Roundcube transition may no longer exist on a current cPanel release. Use instructions that match the server version you are actually administering.

Why You Should Not Run rm -rf ~/.cagefs to Free Disk Space

If .cagefs is the largest hidden directory in the account, deleting its root is the wrong first move while CageFS is enabled. The directory can contain live temporary paths, PHP session storage and other per-user data that CloudLinux expects to find in a specific structure.

The failure does not necessarily appear as an obvious filesystem error. You may instead see PHP Selector stop working, an application lose sessions, shell entry fail, or CageFS report permission and jail-entry errors.

A typical ticket looks simple: "The account is full and .cagefs is the biggest hidden directory." The directory name is not the diagnosis. Disk blocks, account quota and inodes can all produce a "no space" complaint, and they require different fixes.

Do not try to repair the tree with recursive permission changes either. A command such as:

chmod -R 777 /home/USERNAME/.cagefs

can destroy the permission model expected by CageFS. A broad chown -R is equally dangerous if you do not know the expected owner of each path.

Broken permissions or structure can surface with errors such as:

cagefs_enter: Error entering cagefs jail
Unable to create directory
Permission denied

Another common pattern is one user losing PHP Selector access after a recursive permission change while every other account on the server works normally. In that case, a server-wide CageFS operation is a poor first move. The scope is already telling you where to start.

Removing a known set of stale temporary files under an understood cleanup policy is one operation. Removing the root of a user's CageFS working tree is another.

What Should You Check When .cagefs Is Too Large or Contains Too Many Files?

When .cagefs grows, separate four different problems before changing anything: filesystem capacity, account quota, inode pressure, and application-generated temporary or session data. A "disk full" report can come from any of them.

There is no useful universal threshold such as "a 2 GB .cagefs is too large." A directory becomes a problem in context: it approaches the account quota, grows continuously, contains an abnormal file count, or holds data that an application keeps recreating.

Is the Problem Disk Space or Inodes?

Start with the underlying filesystem:

df -h
df -i
du -sh ~/.cagefs 2>/dev/null

df -h answers whether the filesystem is running out of storage blocks. df -i answers whether it is running out of inodes, which effectively limits how many filesystem objects can be created. du shows the size attributed to the directory you are investigating.

For example, suppose the filesystem holding /home is only 42% full according to df -h, but inode usage is 99% in df -i. Deleting one 5 GB backup may free blocks but will barely help the actual failure. You need to find the directory containing a very large number of files.

Compare these two cases:

• 100 MB stored in three large temporary files.
• 100 MB stored in hundreds of thousands of tiny session files.

Both consume about 100 MB, but the second case can create serious inode pressure and make file creation fail even though plenty of raw disk capacity remains.

Is the Account Quota Full or the Whole Filesystem Full?

cPanel account quota and filesystem capacity are not the same measurement. An account can receive a disk quota exceeded error while df -h still shows plenty of free space for the server as a whole.

For a cPanel user, check cPanel → Files → Disk Usage and the account's reported disk limit. For an administrator, compare the account quota in WHM with the underlying filesystem state. Where the standard quota utility is available, it can also help confirm the user's kernel-enforced quota:

quota -s USERNAME

Do not rely on that single command on every server layout; quota implementation can differ by filesystem and hosting configuration. The goal is to distinguish the layers.

This distinction also explains a confusing support case: a user may report "the server has free disk space, so why can't my account write a file?" The server can have free capacity while that individual account has reached its allowed quota.

Which Subdirectory Is Growing?

Move from broad to narrow:

du -xhd1 ~/.cagefs 2>/dev/null | sort -h
du -xhd2 ~/.cagefs 2>/dev/null | sort -h | tail -30

If .cagefs/tmp dominates, inspect the files before removing them:

find ~/.cagefs/tmp -xdev -type f -mtime +7 -ls 2>/dev/null

The -mtime +7 expression is a diagnostic example, not a deletion rule. An old file is not automatically safe to remove, and seven days has no special meaning for every PHP application.

To find unusually large files:

find ~/.cagefs -xdev -type f -size +50M -ls 2>/dev/null

If you need a file count, this is useful:

find ~/.cagefs -xdev -type f | wc -l

How Do You Find What Keeps Recreating .cagefs Files?

If .cagefs/tmp drops after cleanup and fills again shortly afterward, stop repeating the cleanup. Something is producing those files.

Build a small baseline first:

date
du -sh ~/.cagefs/tmp 2>/dev/null
find ~/.cagefs/tmp -maxdepth 1 -type f -printf '%TY-%Tm-%Td %TH:%TM:%TS %p\n' \
2>/dev/null | tail -50

Repeat the size check after the application has handled traffic, a cron job has run, or the failure has reproduced:

date
du -sh ~/.cagefs/tmp 2>/dev/null

If the directory grows rapidly, inspect the newest files and determine what they are. PHP session files point you toward session handling. Predictably named temporary exports may point toward a specific application. Files appearing on a regular schedule should make you check cron jobs.

For PHP, inspect the active session path from the same PHP environment that serves the application. CLI PHP and the web server can use different configurations, so a generic php -i result does not always describe PHP-FPM or Alt-PHP handling web requests.

php -i | grep -i 'session.save_path'

Use that as a clue, then confirm the PHP version and handler used by the affected domain. If only one Alt-PHP version shows the problem, compare its session path and configuration with another version rather than assuming the entire CageFS environment is broken.

Also check scheduled work:

crontab -l

For root-level investigation, inspect the user's configured cron jobs through the server's normal cPanel/cron tooling as appropriate. Then correlate timestamps with application logs, access logs, backup jobs, import/export tasks, or scripts that use temporary storage.

A useful support test is simple: record size and file count, reproduce one application action, then measure again. If uploading a large archive, running an import, or executing a particular cron job immediately creates the files, you have moved from "the .cagefs directory is large" to a specific producer.

CloudLinux has mechanisms for cleaning old CageFS temporary files. That is different from creating an arbitrary cron job that removes everything older than a chosen age. If the files return soon after cleanup, the cleanup was cosmetic. Find the producer.

How Do You Repair a Broken .cagefs Directory Without Rebuilding the Account?

If PHP Selector starts returning errors after someone manually deleted directories or changed permissions below .cagefs, do not rebuild the entire cPanel account first. Determine whether the failure affects one user, one PHP environment, or many CageFS users, then choose the smallest repair scope that matches the evidence.

This section requires root or equivalent server-administrator access.

Start by Determining the Scope of the Failure

If only one user is broken, do not touch every CageFS mount on the server. Start with that account:

/usr/sbin/cagefsctl --user-status USERNAME

Then reproduce the original symptom. Test the thing that actually failed: PHP Selector, shell entry, the website under its configured PHP handler, or the command that originally returned a permission error.

If two unrelated users work and one does not, the evidence points toward user-specific state. If many users start failing immediately after a CageFS configuration change, the scope is different.

When Is a Per-User Remount Enough?

If the problem is limited to one account and the structure is otherwise intact, a per-user remount is a narrower operation than remounting every CageFS user:

/usr/sbin/cagefsctl --remount USERNAME

After the remount, repeat the original failing action. A successful command exit is not enough if the customer-facing symptom remains. Open PHP Selector, execute the application, enter the shell if that is the affected feature, and check whether the permission error returns.

If the remount changes nothing, do not automatically escalate to --remount-all. First ask whether the user's .cagefs structure or permissions were modified manually, whether only one Alt-PHP version is affected, or whether configuration files inside CageFS are stale.

What Does cagefsctl --sanity-check Tell You?

CloudLinux provides a consistency check for common CageFS configuration problems:

/usr/sbin/cagefsctl --sanity-check

The check can identify issues with CageFS mount points, configuration directories and the ability of test users to enter CageFS. It is useful when the scope is not obvious or after server-level CageFS configuration changes.

A failed sanity check gives you a direction; it does not make every per-user problem global. Read which test failed and investigate that component.

When Should You Use --remount-all?

A global remount is appropriate when the change itself is global, for example after modifying CageFS mount-point configuration that needs to be applied across users:

/usr/sbin/cagefsctl --remount-all

Do not interpret "the problem disappeared after --remount-all" as proof that CageFS was the original root cause. A remount refreshes state and can remove a symptom without explaining why the state became wrong.

For one broken account, a global remount is too broad as a first response. For a verified server-wide configuration change, it may be exactly the right scope.

When Do --force-update and --force-update-etc Belong in the Repair?

CloudLinux also provides update operations:

/usr/sbin/cagefsctl --force-update
/usr/sbin/cagefsctl --force-update-etc

These are administrative update operations, not harmless read-only diagnostics. --force-update refreshes CageFS content, while --force-update-etc refreshes CageFS user /etc data. Use them because the diagnosed problem requires an update, not merely because a per-user remount did not fix an unrelated symptom.

For a genuinely damaged per-user .cagefs tree with broken permissions, an administrator may need to preserve or rename the damaged directory and let CageFS recreate the required structure through the documented update and remount procedure. Preserve enough state to investigate what happened before removing the damaged tree.

What Should You Check After a CageFS Repair?

A repair is complete only when the original symptom is gone and the surrounding functions still behave normally. Test at least the layer that failed and one adjacent layer.

• If PHP Selector failed, open it and verify the expected PHP versions and extensions.
• If the website failed under PHP, request the affected page and check the corresponding error log.
• If shell entry failed, test the intended shell access for that user.
• If sessions failed, log in to the affected application and confirm that the session persists across requests.
• If the issue involved disk usage, re-run du, df -h, and df -i where relevant.
• If the repair involved a global CageFS change, test more than one account.

If the user can enter CageFS again but the original application still throws permission errors, the root problem has not been fully resolved. Follow the failing path instead of declaring success because one administrative command returned cleanly.

Are Files Inside .cphorde or .cagefs a Sign That the cPanel Account Was Hacked?

The existence of .cphorde or .cagefs is not evidence of compromise. At the same time, a legitimate parent directory does not make every file inside it trustworthy. Security analysis has to be done at the file level. This is separate from web-layer controls such as cPanel mod_security configuration, which protects a different part of the stack.

This distinction matters most with .cagefs/tmp. Temporary directories are expected to change frequently, so a recent modification timestamp is weak evidence by itself. PHP session files, temporary uploads, caches, and application-generated files can all appear there during normal use.

If something looks wrong, collect facts first:

find ~/.cphorde ~/.cagefs -xdev -type f -mtime -2 -ls 2>/dev/null

find ~/.cphorde ~/.cagefs -xdev -type f \
\( -name '*.php' -o -name '*.pl' -o -name '*.py' -o -name '*.sh' \) \
-ls 2>/dev/null

For a suspicious file, inspect metadata and file type:

stat /full/path/to/suspicious-file
file /full/path/to/suspicious-file
sha256sum /full/path/to/suspicious-file

The checksum does not tell you whether a file is malicious. It gives you a stable identifier for comparing copies, checking scanner results, or confirming whether the file changes during the investigation.

Then ask six concrete questions:

1. What is the full path?
2. Who owns the file?
3. What type of file is it?
4. When was it created or modified?
5. What legitimate application could have created it?
6. Do access, FTP, SSH, cPanel, malware-scanner, or application logs support that explanation?

A normal session object under an expected PHP session path and an unexplained executable PHP script with obfuscated content deserve completely different treatment, even if both happen to reside below .cagefs.

The same logic applies to .cphorde. A historical horde.sqlite in the expected account-home location fits the directory's legacy purpose. A recently created PHP file inside an unexpected public_html/.cphorde/ needs a different explanation.

What Should You Do Before Cleaning Up Hidden cPanel Account Directories?

Before deleting either directory, identify its purpose, current dependency, size and recovery path. With .cphorde, the main risk is discarding legacy data. With an active .cagefs, the risk is changing part of the user's runtime environment.

realpath ~/.cphorde 2>/dev/null
realpath ~/.cagefs 2>/dev/null

ls -lad ~/.cphorde ~/.cagefs 2>/dev/null
du -sh ~/.cphorde ~/.cagefs 2>/dev/null

du -xhd1 ~/.cagefs 2>/dev/null | sort -h

df -h
df -i

If you have root access and the server uses CloudLinux, add:

/usr/sbin/cagefsctl --cagefs-status
/usr/sbin/cagefsctl --user-status USERNAME

Then work through this checklist:

• Confirm the full path. A directory in /home/USERNAME/ and a similarly named directory inside public_html should not be treated the same way.
• Measure before deleting. Check whether the directory is actually responsible for the storage problem.
• Separate filesystem space, account quota and inodes. They can all produce different versions of a "disk full" complaint.
• Inspect .cphorde for legacy data. Look for horde.sqlite and confirm whether old contacts or calendars still matter.
• Back up or stage the retirement of legacy data. If the dependency is uncertain, a controlled rename and observation period is safer than immediate deletion.
• Verify CageFS status before touching .cagefs. A directory can exist even when the user is no longer enabled in CageFS.
• Find the growing subtree. A large .cagefs/tmp or PHP session path is a specific problem; the whole .cagefs directory is not.
• If files return after cleanup, find the producer. Check PHP sessions, cron jobs, imports, backups and application logs.
• Do not repair permissions by guessing. Avoid recursive 777 and broad chown commands.
• Use per-user CageFS diagnostics first when one account is affected. Escalate to global operations only when the scope is genuinely global.
• Test the original symptom after repair. A clean administrative command does not prove that PHP, sessions or the application are healthy.
• Investigate suspicious files individually. A legitimate system directory can still contain a file that should not be there.

If .cphorde contains only a small amount of verified legacy data, cleanup may save almost no useful disk space, so keeping a backup is cheap insurance. If .cagefs is large, locate the specific temporary or session subtree and determine whether it is stable or growing.

Classify first, clean second. Delete only after you know which component owns the data, whether anything still depends on it, and how you will verify that the account still works afterward.