How to Safely Clean .cagefs/tmp in CloudLinux CageFS

Is It Safe to Delete .cagefs/tmp in CloudLinux CageFS?

It is generally safe to remove stale temporary data from .cagefs/tmp when that data meets the server's cleanup criteria, but deleting the directory itself is a different operation. The same is even more true for deleting the entire .cagefs directory.

A typical storage alert starts with something simple: an account reaches its quota, an administrator runs du, and several gigabytes appear under /home/USER/.cagefs/tmp. From the outside it looks like an oversized cache. From inside CageFS, however, the user sees an isolated /tmp backed by that directory. Applications may still be writing there.

Before removing anything, establish whether the problem is really temporary data and whether CageFS itself is healthy:

du -sh /home/USER/.cagefs/tmp
findmnt -T /home/USER/.cagefs/tmp
stat /home/USER/.cagefs/tmp
cagefsctl --user-status USER

The first command measures the directory. findmnt shows the filesystem and mount context for the path. stat exposes ownership, permissions and timestamps. The CageFS status check confirms whether the account is enabled in CageFS instead of assuming that every unusual directory state is merely a storage problem.

For routine work, clean the temporary data without dismantling the CageFS structure around it.

What Is Stored in .cagefs/tmp, and Why Can It Grow So Large?

/home/USER/.cagefs/tmp is the physical storage behind the user's isolated CageFS /tmp. It can therefore contain far more than disposable text files: PHP and application temporary files, uploads, locks, sockets or socket links, CLI working files, archive fragments and data created by cron jobs can all appear there.

The first useful check is not just how large the directory is, but what is making it large:

du -sh /home/USER/.cagefs/tmp
du -xah /home/USER/.cagefs/tmp | sort -h | tail -n 30
find /home/USER/.cagefs/tmp -xdev -type f | wc -l

The first two commands show total size and the largest visible objects. The file-count check adds another dimension. An 8 GB directory containing three large abandoned archives is a different problem from an 8 GB directory containing hundreds of thousands of session, cache or temporary files.

That difference also matters when storage consumption is not yet dramatic. A directory with a huge number of tiny files can put pressure on the filesystem's inode pool even when the byte count still looks reasonable. If writes fail while df -h shows free space, check df -ih before assuming the disk-space numbers are wrong.

You can inspect individual candidates with:

stat /home/USER/.cagefs/tmp/path-to-file
file /home/USER/.cagefs/tmp/path-to-file

A regular temporary archive might produce output similar to:

$ file /home/USER/.cagefs/tmp/export.tmp
/home/USER/.cagefs/tmp/export.tmp: gzip compressed data

$ stat /home/USER/.cagefs/tmp/export.tmp
  File: /home/USER/.cagefs/tmp/export.tmp
  Size: 4294967296
  Access: (0600/-rw-------)
  Modify: 2026-08-28 02:14:17
  Change: 2026-08-28 02:14:17
  Access: 2026-09-09 03:12:06

The dates above are only an example of what to inspect. A file may have an old modification time but a much more recent access time. That matters later when you compare it with an age-based cleanup rule.

Do not infer purpose only from a filename. A strangely named file may be harmless leftover data, while a familiar-looking sess_*, lock file or socket may still belong to an active process.

How CageFS Maps a User's /tmp to .cagefs/tmp

Inside CageFS, the application works with its own isolated /tmp; outside the cage, the administrator sees the backing data under the user's home directory. That is why removing files from .cagefs/tmp affects what the user and applications see in their CageFS temporary area.

The temporary directory is also part of the user's storage usage. An account can therefore exceed its quota while the server still has substantial free filesystem capacity. Those two numbers describe different limits and should always be checked separately.

Do PHP Sessions Always Live in .cagefs/tmp?

No. PHP sessions may use CageFS /tmp, but their actual location depends on the active PHP configuration, handler, selected PHP version and control-panel integration. Alt-PHP installations can also have per-version session directories under paths such as .cagefs/opt/alt/phpNN/var/lib/php/session.

Check the configuration used by the PHP version and SAPI that actually serves the site:

php -i | grep session.save_path

For a web application, CLI output is useful only if CLI and web PHP use the same relevant configuration. If they do not, inspect the applicable php.ini, PHP Selector settings or per-site configuration instead.

This prevents a dangerous shortcut: seeing sess_* files and deciding that every one of them is either essential or disposable. First identify the session path used by the application. Then decide what can be cleaned.

How Do You Confirm That .cagefs/tmp Is Actually Consuming the Space?

Do not start cleanup until the storage symptom has been classified. A full filesystem, an exceeded user quota, exhausted inodes and a deleted file still held open by a process can all produce some version of “there is no space,” yet deleting a few old temporary files will not solve all four.

Collect a baseline before changing anything:

df -h
df -ih
du -sh /home/USER/.cagefs/tmp
du -xah /home/USER/.cagefs/tmp | sort -h | tail -n 30
quota -u USER

df -h shows block usage for the filesystem. df -ih checks inode consumption. du measures directory data visible in the filesystem tree. The quota check tells you whether this particular account has exhausted its allocated storage even if the underlying filesystem is healthy.

An inode problem is easy to miss because the byte-based filesystem report may still look healthy. For example:

$ df -h /home
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1       220G  126G   83G  61% /home

$ df -ih /home
Filesystem     Inodes IUsed IFree IUse% Mounted on
/dev/vda1        3.1M  3.1M   12K  100% /home

There is plenty of block capacity in this example, but almost no free inodes. Deleting one 5 GB archive may reclaim bytes and still leave file creation broken. The useful next step is to find where the huge file population lives.

The reverse situation is common with account quotas. The filesystem may have plenty of room while one account is at its allocation:

$ df -h /home
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1       220G  126G   83G  61% /home

$ quota -u USER
Disk quotas for user USER:
Filesystem   blocks    quota    limit
/dev/vda1   20970000 20971520 20971520

The exact quota output differs by filesystem and control panel, but the diagnostic point is the same: a healthy df does not clear the user quota as a possible cause.

A support request can easily point in the wrong direction here. An administrator sees several gigabytes under .cagefs/tmp and assumes it caused a full server, while the filesystem measurements show that another directory is responsible. Cleaning CageFS temp may help that account and still do almost nothing for the server-wide problem.

Record the before-values. They are what let you prove whether cleanup reclaimed directory space, filesystem blocks, quota or inodes.

What Should You Check Before Removing Files from .cagefs/tmp?

Before manual cleanup, verify active processes, open files, the CageFS mount state, directory ownership and the type of data you intend to remove. A timestamp alone does not prove that a file is safe to delete.

Start with the account and directory state:

cagefsctl --user-status USER
findmnt -T /home/USER/.cagefs/tmp
ls -ld /home/USER/.cagefs/tmp
stat /home/USER/.cagefs/tmp
ps -u USER

The process list may reveal a long-running PHP command, backup, importer, exporter, cron job, Composer operation or another task that is actively using temporary storage. If the account is quiet, targeted manual cleanup becomes easier to evaluate.

Check Active Processes and Open Files Before Cleanup

Files currently used by PHP, cron, backups or another process should not be treated as ordinary stale data. For a specific suspicious file, check it directly:

lsof /home/USER/.cagefs/tmp/path-to-file
fuser -v /home/USER/.cagefs/tmp/path-to-file

No output from these commands is useful evidence that the specific file is not currently open by a visible process, but it is not a universal proof that the data is disposable. You still need to identify what created the file and whether the related task has completed.

Be careful with recursive open-file scans against a directory containing hundreds of thousands of entries. A broad lsof +D can be expensive. If you have already identified a handful of large candidates, checking those exact files is usually the cleaner diagnostic step.

If an active import, backup or long-running script owns the file, wait for that operation to finish or stop that specific workload cleanly. There is rarely a good reason to stop the entire Apache, PHP or database stack just because one account has temporary files to inspect.

Verify the Mount, Owner, and Permissions of .cagefs/tmp

Cleanup will not repair a broken CageFS mount or incorrect directory ownership. If .cagefs/tmp already has an abnormal owner, mode or mount state, establish that first instead of deleting more data.

findmnt -T /home/USER/.cagefs/tmp
stat /home/USER/.cagefs/tmp
ls -ld /home/USER/.cagefs/tmp
cagefsctl --user-status USER

If the result differs from a known-good CageFS account on the same server, investigate why. Do not guess a permission mode from a random forum post, and do not use chmod 777 as a generic repair. A mount problem is not fixed by widening permissions.

How Do You Clean Stale CageFS Temporary Files with cagefsctl --tmpwatch?

For normal stale CageFS temporary data, CloudLinux provides cagefsctl --tmpwatch. The command runs the configured age-based cleanup immediately instead of waiting for the scheduled CageFS cleanup job.

cagefsctl --tmpwatch

It does not mean “empty every CageFS /tmp.” Only files that match the configured cleanup rules qualify. An old modification timestamp by itself does not prove that a file should disappear.

Does cagefsctl --tmpwatch Clean One User or All CageFS Users?

cagefsctl --tmpwatch runs CageFS temporary-file cleanup for all users, not only the account you happen to be troubleshooting. This scope matters on a shared hosting server.

Suppose only /home/USER/.cagefs/tmp is under investigation. Measuring that account before and after cagefsctl --tmpwatch is useful, but the cleanup command itself is still server-wide. It can remove qualifying stale temporary files from other CageFS accounts at the same time.

Check the Current CageFS tmpwatch Retention Before Running It

Confirm the server's current policy rather than assuming it still uses the default. CageFS normally cleans temporary files according to how long they have remained unaccessed, and administrators can change that period.

A standard way to set the cleanup command is:

cagefsctl --set-tmpwatch='/usr/sbin/tmpwatch -umclq 720'

Here 720 is the age threshold in hours. It corresponds to 30 days. The setting is server-wide, so shortening it changes the policy used for CageFS temporary cleanup rather than changing one customer's account.

Inspect the active configuration and the options supported by the installed package:

grep -E 'tmpwatch|tmpwatch_dirs' /etc/cagefs/cagefs.ini
cagefsctl --help

The effective configuration may contain the tmpwatch command in the common CageFS settings. A configuration fragment can look like this:

[common]
tmpwatch=/usr/sbin/tmpwatch -umclq 720

Use the server's actual file as the authority. Do not assume that a value copied from another host is appropriate or that every package generation serializes configuration in exactly the same way.

CageFS can also include additional directories in automatic cleanup through tmpwatch_dirs. For example:

tmpwatch_dirs=/dir1,/dir2

Those paths refer to directories inside CageFS. Their physical per-user data lives under the corresponding $USER_HOME/.cagefs/... paths. This is worth checking before changing policy, because a server may be cleaning more than the standard CageFS /tmp.

Alt-PHP session directories may also participate in CageFS cleanup. That is another reason not to lower retention aggressively until you know where applications store sessions and temporary work data.

Why Can an Old File Survive tmpwatch?

An old-looking file can remain because the cleanup decision is not based solely on when the file was last modified. If a backup scanner or another maintenance process accesses it, the file can remain outside the stale set even though its content has not changed for weeks.

Compare its timestamps:

stat /home/USER/.cagefs/tmp/path-to-file

A suspicious pattern is an old Modify time combined with a recent Access time. That still does not prove which process touched the file, but it explains why looking only at mtime can send the investigation in the wrong direction.

Run cagefsctl --tmpwatch and Verify What Changed

Measure the affected account before and after the server-wide cleanup:

du -sh /home/USER/.cagefs/tmp
quota -u USER

cagefsctl --tmpwatch

du -sh /home/USER/.cagefs/tmp
quota -u USER
df -h
df -ih

If the directory shrinks and quota usage falls as expected, the stale-file policy removed data relevant to the account. If little changes, do not immediately assume tmpwatch failed. The remaining files may not meet the age/access criteria, may belong to active workloads, or the storage problem may be elsewhere.

At that point, stop repeating the same cleanup command and investigate the files that survived.

When Is Manual Cleanup of One User's .cagefs/tmp Justified?

Manual cleanup makes sense when a specific account is under storage pressure, the normal policy does not remove enough data, and particular files can be identified as disposable. It is also the practical route when you need to touch one account without triggering a server-wide cagefsctl --tmpwatch run.

Inventory the files first:

find /home/USER/.cagefs/tmp -xdev -type f -printf '%s %TY-%Tm-%Td %TH:%TM %p\n'

This is an inventory command, not an exact reproduction of the CageFS tmpwatch algorithm. It gives you file sizes, timestamps and paths so that obvious candidates can be investigated. Do not turn it directly into find -delete.

A straightforward manual case looks like this: one account is at quota, the size listing reveals a multi-gigabyte temporary archive, the export or backup that created it has finished, and no process has the file open. Now there is a specific target. That is very different from deleting every object because the directory contains 50,000 files.

How Do You Verify a File Before Deleting It?

For a single candidate, walk through the same checks in a fixed order. Assume the suspected file is /home/USER/.cagefs/tmp/large-export.tmp:

stat /home/USER/.cagefs/tmp/large-export.tmp
file /home/USER/.cagefs/tmp/large-export.tmp
lsof /home/USER/.cagefs/tmp/large-export.tmp
fuser -v /home/USER/.cagefs/tmp/large-export.tmp

stat confirms that you are looking at the intended object and shows its size, owner and timestamps. file helps identify its type. lsof and fuser look for active use. Then relate the file to the application: was an export completed, did a backup finish, or is a cron job still running?

If the file is a confirmed regular temporary file, the associated work is finished and no process is using it, delete that exact path:

rm -- /home/USER/.cagefs/tmp/large-export.tmp

Immediately measure the result:

du -sh /home/USER/.cagefs/tmp
quota -u USER
df -h

Then test the related application or job. If the file came from an export function, run a small export or verify that the application opens normally. The purpose of the post-delete test is not to prove that every component of the account is healthy; it confirms that the specific cleanup did not break the workload you just investigated.

Use a Maintenance Window for Application-Sensitive Cleanup

If the temporary data belongs to an importer, backup, queue worker, upload process or long-running PHP job, cleanup is safer once that workload has stopped. The maintenance window can be scoped to one application or account; it does not have to become server-wide downtime.

Check again after the task stops:

ps -u USER
lsof /home/USER/.cagefs/tmp/path-to-file

When the owning process has gone and the file is confirmed disposable, targeted deletion becomes much easier to justify. If the purpose of the file is still unclear, leave it alone and continue the investigation instead of widening the deletion pattern.

Which .cagefs/tmp Files Should You Avoid Deleting While Applications Are Active?

Sessions, sockets, lock files, active uploads and files that are still being written deserve extra checking before manual deletion. Their presence under a temporary directory does not mean they are disposable at that exact moment.

For a suspicious object, basic filesystem tools often tell you enough to choose the next check:

file /home/USER/.cagefs/tmp/object
stat /home/USER/.cagefs/tmp/object
readlink /home/USER/.cagefs/tmp/object
lsof /home/USER/.cagefs/tmp/object
fuser -v /home/USER/.cagefs/tmp/object

If the file resembles a PHP session, confirm the session location used by the site before touching it. If it is a socket or a link to one, identify the related application or process. If it is a lock, find out what is being locked. If the file keeps increasing in size, treat it as live until you know otherwise.

The reverse is also true: a sess_* name does not prove that a session is currently active forever. Temporary data becomes stale eventually. The decision should come from configuration, age and process state rather than filename pattern alone.

Why Can .cagefs/tmp Stay Large After tmpwatch or Manual Deletion?

You remove several gigabytes from .cagefs/tmp. du drops immediately, but df -h barely moves. That result is not a reason to run a more aggressive rm; it tells you to identify which storage metric did not improve.

Check for Deleted Files That Are Still Open

The classic pattern is a large file removed from the directory tree while PHP, a backup process or another service still has its file descriptor open. du no longer sees the pathname, but the filesystem cannot reclaim the blocks until the last descriptor is closed.

Check for deleted-open files:

lsof +L1

An illustrative line may look like this:

php-fpm  28417 USER  12w  REG  253,1  4294967296  0  1827712 /home/USER/.cagefs/tmp/upload.tmp (deleted)

The important fields are the process, PID, user, file size and (deleted) marker. On a busy server, narrow the output to the relevant account or process rather than treating every deleted-open file as part of the same incident.

Do not try to delete the pathname again; it is already gone. Determine whether the owning process can safely finish, restart or stop. When the final open descriptor closes, the filesystem can release the blocks.

Check Whether Recent Access Prevented tmpwatch Cleanup

Another common mismatch is simpler: the administrator sees a file modified weeks ago and expects tmpwatch to remove it, but stat shows recent access. A backup, scanner or maintenance job has touched the file without modifying its content.

stat /home/USER/.cagefs/tmp/path-to-file

An old mtime is suspicious, but it still does not prove that the file should match the current CageFS cleanup rule. Compare the relevant timestamps with the configured tmpwatch policy first.

If the same apparently stale files keep getting accessed, find the process responsible before reducing retention. Otherwise a shorter policy may hide the symptom for a while without explaining why those files are continuously touched.

Check Quota, Inodes, and Other .cagefs Subdirectories

A storage warning can survive a successful .cagefs/tmp cleanup because .cagefs/tmp was never the only constraint. Recheck all relevant metrics:

df -h
df -ih
quota -u USER
du -sh /home/USER/.cagefs/*
du -sh /home/USER/.cagefs/.[!.]* 2>/dev/null

The last commands are exploratory rather than cleanup instructions. Their purpose is to reveal whether another part of the user's CageFS data is large. PHP session storage, application-specific temporary data or another subtree can account for space even after .cagefs/tmp becomes small.

If inode utilization is the real limit, focus on file count rather than a few large objects. Hundreds of thousands of tiny files can stop new file creation while gigabytes of block capacity remain available.

How Do You Recover a Broken .cagefs/tmp Mount or Permissions?

After manual changes to .cagefs/tmp, the symptom may shift from storage pressure to failed PHP requests, cron errors or a user that can no longer write to /tmp. At that point, stop deleting files. Check whether the directory exists, whether ownership and mode look plausible, and whether the CageFS mount for that account is healthy.

ls -ld /home/USER/.cagefs/tmp
stat /home/USER/.cagefs/tmp
findmnt -T /home/USER/.cagefs/tmp
cagefsctl --user-status USER
cagefsctl --sanity-check

If only one account is affected, keep the repair scoped to that account. A global remount creates unnecessary disruption when the problem belongs to one user.

Remount CageFS for the Affected User

If the mount state is broken for one account, remount that user:

cagefsctl -m USERNAME

Then repeat the mount and status checks. Do not stop at a successful exit code. Test the thing that was failing: can the user actually create and remove a file in CageFS /tmp?

If the account has a usable shell, one simple test is:

su - USERNAME -c 'touch /tmp/cagefs-write-test && ls -l /tmp/cagefs-write-test && rm -f /tmp/cagefs-write-test'

If the user's shell is disabled, an administrator can execute a command inside the user's CageFS with cagefs_enter_user:

/sbin/cagefs_enter_user USERNAME /bin/sh -c 'touch /tmp/cagefs-write-test && ls -l /tmp/cagefs-write-test && rm -f /tmp/cagefs-write-test'

A successful test shows that the user can create the file, list it and remove it from the CageFS /tmp. After that, retry the PHP request, cron command or application operation that originally failed. A working test file does not prove the application is fixed, but it separates basic CageFS temporary-directory access from an application-specific problem.

If the test still fails after a user remount, rerun the structural checks rather than repeatedly remounting:

findmnt -T /home/USER/.cagefs/tmp
stat /home/USER/.cagefs/tmp
cagefsctl --user-status USER
cagefsctl --sanity-check

If several users show the same failure, the scope has changed. Investigate CageFS configuration and mount state globally before considering a broader remount.

CloudLinux also provides:

cagefsctl -M

This remounts CageFS for all users and should not be the first response to one broken account.

Repair Ownership and Permissions Without Using chmod 777

If ownership or permissions are wrong, restore the expected values for that CloudLinux and control-panel environment instead of making the directory world-writable. Compare the affected account with a known-good CageFS user on the same server:

stat /home/USER/.cagefs/tmp
stat /home/KNOWN_GOOD_USER/.cagefs/tmp

Compare owner, group, permissions and relevant mount behavior. Correct the actual deviation. Do not copy values blindly between unrelated servers where CageFS, control-panel integration or filesystem layout may differ.

If the directory structure itself was removed and a normal user-specific remount does not restore a healthy state, stop improvising directory ownership and modes. Run CageFS sanity checks and use the appropriate CageFS recovery procedure rather than rebuilding internal structure from guesses.

What Is a Safe Production Workflow for Keeping .cagefs/tmp Under Control?

A reliable production workflow is to measure the problem, verify active use, apply the appropriate cleanup scope, measure again, and investigate whatever rapidly grows back. Routine server-wide stale-file cleanup and manual per-user cleanup solve different problems and should remain separate tools.

For a new storage alert, the sequence can be kept compact:

Choose a Retention Period Based on the Workload

The tmpwatch retention period should fit the applications hosted on the server rather than an aggressive number copied from another machine. Shorter retention can recover quota sooner, but temporary directories may carry legitimate long-running jobs, uploads, sessions or application working data.

Before reducing retention, answer three questions: what file types dominate the directory, how old they are when they are still useful, and which processes create or access them. Check the active PHP session path as part of that review when PHP applications are involved.

If files are genuinely abandoned for weeks, a shorter policy may be reasonable. If they belong to jobs that legitimately run for many hours or days, shrinking the retention window can create failures that are harder to diagnose than the original disk-usage alert.

Investigate Accounts Whose .cagefs/tmp Quickly Grows Back

If an account's .cagefs/tmp returns to its previous size soon after cleanup, stop tuning retention for a moment. New data appearing immediately after cleanup is a strong sign that an application, cron task, backup, importer or another workload is actively producing it.

Take one snapshot:

date
du -sh /home/USER/.cagefs/tmp
du -xah /home/USER/.cagefs/tmp | sort -h | tail -n 30
find /home/USER/.cagefs/tmp -xdev -type f -printf '%s %TY-%Tm-%Td %TH:%TM:%TS %p\n' | tail -n 50

Repeat the same check after the directory has grown. You are looking for paths that did not exist in the first snapshot, files whose sizes keep increasing, and timestamps that line up with scheduled work.

Then compare those times with the user's processes and cron configuration:

ps -u USER
crontab -u USER -l

For example, if a fresh archive appears every time a nightly cron starts and remains after the job finishes, the real problem is no longer tmpwatch frequency. The next investigation belongs to that job: where it writes temporary data, whether it exits cleanly, and whether its own cleanup stage runs.

A similar pattern can expose a stuck importer. One snapshot shows a 300 MB work file, the next shows 2 GB, and the responsible PHP or CLI process is still active. Removing the file underneath that process treats the symptom while creating another failure. First deal with the producer.