Protection

The layer no profile can switch off. A file manager that can reach the Joomla root can, in principle, overwrite configuration.php or drop a PHP file into a web-served folder. Protection is what stops a misconfigured profile from becoming a remote-code-execution hole.

It has three parts, and they answer two different questions.

Protected patterns — blocking writes

An editable list of names, directory trees and globs. Matching a pattern protects the path and everything under it.

The defaults, applied before you configure anything:

configuration.php      configuration.php-*
index.php              .htaccess
.user.ini              web.config
administrator/         cli/
includes/              libraries/

That covers Joomla's entry points, its server-configuration files, and the four trees where a written file becomes executable code or breaks the CMS.

Edit the list under Configuration → Settings → Protected paths. It is Super-User-only, and it stays so even for a profile granted Manage settings.

Writes to a protected path are refused for everyone, Super Users included, until an explicit unlock exists. Reads are unaffected — you can browse administrator/, and open a template file to look at it.

Secret files — blocking reads

A separate, shorter list, and a stricter rule. These files' contents are confidential:

configuration.php      configuration.php-*
.env                   .env.*
*.key                  *.pem
.htpasswd

Below Super User these cannot be read, previewed, downloaded, copied, or extracted out inside a ZIP archive. Every route is closed, not just the direct one — a user who cannot download configuration.php cannot obtain it by selecting its folder and asking for an archive.

No setting lifts this for a non-Super-User. The unlock mechanism below governs writes; it does not make a secret file readable.

This list is not editable in the interface. It is deliberately short and deliberately fixed — it is the floor.

Per-path locks — the override mechanism

Right-click any item and use Protect (lock) or Unprotect (unlock).

• Protect (lock) marks a specific path protected even though no pattern matches it. Use it on things that matter to your site but not to Joomla — a client's signed contract, a config file your own code reads.
• Unprotect (unlock) records an override on a specific path, lifting pattern protection for that one item.

Evaluation is nearest-ancestor-explicit-wins: the closest explicit lock or unlock up the tree decides, and if there is none, the pattern list decides.

The unlock switch

Unlock overrides only count when Allow Super Users to unlock & edit protected files is on, under Configuration → Settings. It is:

• off by default — protection is absolute until you decide otherwise
• Super-User-only — not reachable through the Manage settings feature gate

Off, every unlock in the database is inert and protection is absolute for everyone. On, a Super User can unlock one path and edit it.

The intended workflow is: switch it on, unlock the one file, make the change, re-lock it, switch it back off. Leaving it on permanently is a decision, not a default.

Path resolution

Underneath all three mechanisms is one guarantee: a path cannot escape its granted root.

Every request canonicalises the requested path — resolving .. segments, following symlinks to where they actually point, and folding case on filesystems that ignore it — and then confirms the result still sits inside a root the profile grants.

That last clause matters more than it sounds. On Windows and macOS, Administrator/ and administrator/ are the same directory but different strings; a check that compares strings without folding case is bypassed trivially. Symlinks are the same problem by another route: a symlink inside a granted folder pointing at /etc is not a way out, because resolution happens before the root check, not after.

The same canonicalisation applies to every entry in an archive during extraction, which is what blocks Zip-Slip. See Archives.

Checking why something is blocked

Two places tell you.

The browser itself badges protected items with a padlock, in both grid and list view — so you can see at a glance that administrator/, libraries/ and configuration.php are locked down.

The info panel reports Writable: Yes / No for the selection. A No means something is protecting it. It does not say which mechanism, so work down the list: does the path match a pattern in Settings → Protected paths? If not, it carries an explicit lock — right-click and Unprotect (unlock) it.

Practical notes

• Add to the list, do not replace it. The defaults are the minimum for a Joomla site. Sites typically add their own upload directories' executable extensions, a .git/ folder, or a vendor tree.
• A pattern protects a subtree. Adding templates/ protects every template. That is usually what you want on a production site, and usually not what you want on a site actively being developed — profile roots are the better tool for "this developer works in templates".
• Lock changes are logged. Both lock and unlock appear in the Activity log with the user and the path — which is the point of recording them.
• Protection is not a substitute for file permissions. It governs what Next File Manager will do. Set your filesystem permissions correctly as well.