# How to set file permissions on an e-commerce server

> Permissions that are too restrictive break a store's normal operation; permissions that are too permissive open an exploitable security hole. The right setting is almost always somewhere in between, never a blanket 777 applied everywhere.

- Source canonique : [https://allaux.fr/en/guides/droits-fichiers-serveur-ecommerce](https://allaux.fr/en/guides/droits-fichiers-serveur-ecommerce)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> On typical shared hosting, files are generally set to 644 and folders to 755, with a few specific folders left writable for cache, logs and uploaded files. Never use 777 in production.

## What the numbers actually mean

A file or folder permission breaks down into three rights (read, write, execute) for three categories (owner, group, others), each expressed as a digit from 0 to 7. A folder set to 755 means the owner can read, write and execute, while the group and others can only read and execute, not write. A folder set to 777, on the other hand, grants write access to absolutely everyone, including a malicious script that manages to run on the server.

On an online store, only a handful of folders genuinely need write access for the web server: cache, logs, file uploads and media folders. The rest of the code, particularly configuration files holding the database connection credentials, should never be directly writable by the web server once the installation is finished.

## Identifying the right settings

1. **List the folders the application actually writes to** — On PrestaShop, this covers var/cache, var/logs, img, upload and download in particular. The config folder only needs to be writable during installation: once that is finished, it goes back to read-only for the web server. On WooCommerce, mainly wp-content/uploads and the caches of active plugins.
2. **Restrict everything else to read-only** — The source code of the CMS, theme and modules or plugins doesn't need to be writable by the web server once deployed: a read-only permission limits the consequences of a potential intrusion.
3. **Check the file owner** — On shared hosting, files generally belong to the hosting account itself, which simplifies permission management compared with a dedicated server where several system users may be involved.
4. **Test after every change** — An overly restrictive setting generally shows up as an explicit error (unable to write to a given folder), visible in the logs once debug mode is enabled.

## Common mistakes

- Applying 777 across the whole site to quickly fix a permission error, without ever reverting to a stricter setting afterwards.
- Leaving configuration files that hold database credentials writable after installation.
- Forgetting to recheck permissions after an FTP file transfer, which can reset certain permissions depending on the client used.
- Confusing file permissions with application user rights (CMS admin accounts): these are two entirely separate permission systems.

## The special case of SSH access with several users

On a VPS or dedicated server where several system accounts can be involved (a developer, an automated deployment tool, the web server itself), file ownership becomes just as important as permissions. A file deployed by one user but that needs to be writable by another (the web server, for instance) requires either a properly configured shared group or a precise ownership adjustment depending on the folder concerned.

This is an important difference from shared hosting, where a single account generally owns all the files and the question of sharing between several system users doesn't arise in the same way.

## FAQ

### Why is 777 dangerous even temporarily?

It grants write access to any process running on the server, including a malicious script dropped through another vulnerability. Even left temporarily, it widens the attack surface for as long as it stays active.

### How can I tell if a problem genuinely comes from file permissions?

Debug mode or the error logs generally show an explicit message such as "unable to write to" or "permission denied", along with the exact path involved.

### Are permission settings the same across all hosting providers?

No, some shared hosting providers impose their own constraints or automated security measures. It's worth checking their documentation before changing permissions manually.