Someone else's account modified a file timestamp on your server, or you simply read a forum thread and started wondering: on shared hosting, can the account next to mine actually see my files? It is one of the most common questions hosting customers ask, and it has a precise, verifiable answer. You do not have to take a sales page's word for it — you can check it yourself from your own SSH session in under a minute.
This article explains exactly what stops one hosting account from reading, writing, or even seeing another account's files and processes on Panelica, how to verify it from your own terminal, and how the approach compares to the CloudLinux stack many hosting companies pay a separate license for.
Can other users see my files on shared hosting?
On a Panelica server, no. Every hosting account is placed in its own chroot jail with its own PID and mount namespace, its own resource limits, and its own file ownership. From inside one account's SSH or SFTP session, the rest of the server — other users' home directories, the panel's own files, the operating system itself — does not exist as far as that session is concerned. Not "permission denied." Not there.
What actually stops your neighbor from reading your files
Isolation on Panelica is not one setting you can accidentally leave off. It is five layers, applied automatically to every account the moment it is created, whether you are on the entry plan or the top one:
- Cgroups v2 — a hard ceiling on CPU, RAM, swap, disk I/O, and process count per account, enforced by the kernel itself.
- PID and mount namespaces — each account gets its own process table and its own view of the filesystem. Another account's processes and directories are not visible, not just inaccessible.
- SSH and SFTP chroot jail — every shell or file transfer session is confined to that account's home directory tree.
- Per-user PHP-FPM pool — each account's PHP processes run under their own Unix user, with
open_basedirand a restricted function list, so a PHP script cannot read another account's files even if it tries. - Unix ownership and permissions — every account has its own UID and GID, its home directory is
700, and every file it creates is owned by that account, not by a shared web-server user.
None of this is a paid add-on. It is the default state of every account Panelica creates.
Verify it yourself in your own account
You do not need root access to check this. Open a terminal from the Panelica File Manager, or connect over SSH with your own hosting account, and run these three commands:
Notice that last line: /root does not error with "Permission denied" — it errors with "No such file or directory," because from inside the namespace it genuinely is not part of the filesystem your session can see. And free -m does not show the server's full 32 GB, 64 GB, or 128 GB of RAM. Panelica runs LXCFS inside every account, so free, nproc, and similar commands report your account's own cgroup limit. This matters for more than curiosity: it is why a Node.js process, a JVM, or a PostgreSQL instance running inside your account sizes its own memory pools correctly instead of assuming it owns the whole physical machine.
Where this shows up in the panel
Isolation is not something an administrator configures per account in Panelica — it is applied automatically at creation time, but the controls are visible and adjustable from the panel:
Why a kernel exploit like PwnKit does not reach the rest of the server
CVE-2021-4034, known as PwnKit, was one of the most widely exploited local privilege-escalation bugs of the last several years, affecting a SUID binary present on nearly every Linux distribution. On Panelica, two independent controls stop this class of exploit from ever leaving a single tenant's jail:
- Every tenant's root filesystem is mounted with
nosuid,nodev, so even if a SUID binary existed inside the jail, the kernel would refuse to honor the SUID bit. - The command set available inside a restricted SSH session is an explicit allowlist, and it does not include any SUID programs in the first place.
This is not a patch for one CVE. It is a structural choice that closes an entire class of "SUID binary inside a shared filesystem" vulnerabilities before they are discovered.
CloudLinux vs Panelica: same goal, different bill
If you have run a hosting business before, you have likely evaluated CloudLinux for exactly this reason. It is a legitimate, widely used approach — and it is worth understanding what it does differently.
| Capability | CloudLinux | Panelica |
|---|---|---|
| Per-account resource limits | LVE (kernel module) | Cgroups v2 (mainline kernel) |
| Per-account filesystem view | CageFS | PID + mount namespaces, chroot jail |
| Database resource governor | MySQL Governor | Per-account cgroup limits apply to database processes the same way |
| Symlink attack protection | SecureLinks | Unix ownership + open_basedir per PHP-FPM pool |
| Kernel requirement | Custom CloudLinux kernel | Standard kernel, 9 supported distributions |
| Licensing | Per-server license fee | Included, no separate license |
The engineering goal is the same — stop one account from touching another. The difference is that Panelica reaches it with cgroups v2, namespaces, and chroot on a standard Ubuntu, Debian, AlmaLinux, or Rocky kernel, so there is no custom kernel to maintain and no separate per-server license on top of your hosting license.
Frequently asked questions
Can other users see my files on shared hosting?
On a properly isolated panel, no. Each account runs inside its own namespace and chroot jail with its own filesystem view, so another account's files are not just permission-restricted — they are not visible from inside the session at all.
What is a chroot jail and does it fully isolate an account?
A chroot jail confines a process's view of the filesystem to a specific directory tree. On its own, chroot can be escaped by a sufficiently privileged process. Panelica combines chroot with PID and mount namespaces, cgroups v2 resource limits, and per-user Unix permissions so that no single layer is the only thing standing between one account and another.
Do I need CloudLinux for real multi-tenant isolation?
CloudLinux is one valid way to get there, using a custom kernel and a per-server license. Panelica reaches the same isolation goals — per-account resource limits, per-account filesystem view, per-account database and PHP execution — using cgroups v2, namespaces, and chroot on a standard kernel, with no separate license.
How do I check my own isolation as a hosting customer?
From your own SSH or SFTP session, run ls /root (should fail with "No such file or directory"), ps aux (should list only your own processes), and free -m (should report your plan's memory limit, not the server's total RAM).
If you run a hosting business
If you resell hosting or manage servers for other customers, this is the layer that turns "shared server" into "multi-tenant hosting platform" rather than one large shared folder with separate logins. It is on by default for every account Panelica creates, it does not require a separate license, and you can show a customer the exact commands above the next time they ask whether their neighbor can read their files.