Few things create panic faster than opening your back office only to find broken product thumbnails, failing module updates, or a sudden 500 internal server error right after clearing the cache. Whenever a store owner tells me their store broke “for no reason,” nine times out of ten the underlying issue comes down to messed-up PrestaShop file permissions or broken system ownership.
When files don’t write, the instinct for many developers and agency freelancers is to run chmod -R 777 across the entire web directory. It is quick, it instantly makes the error go away, and it opens a massive security hole directly into your hosting environment. In this guide, I will walk you through setting up rock-solid file permissions for modules, cache, and images without sacrificing server security.
The Standard Rule: 755 for Folders, 644 for Files
Before touching specific directories, you need to understand the baseline standard for running PrestaShop safely on any Linux-based server (whether you are using Apache, Nginx, or LiteSpeed with PHP-FPM).
In almost every production environment, your standard file structure should follow these two rules:
- Directories:
755(drwxr-xr-x). The server owner can read, write, and execute; everyone else can only read and execute. - Files:
644(-rw-r–r–). The server owner can read and write; everyone else can only read.
Why avoid 777? Setting 777 gives read, write, and execute permissions to anyone on the server. If an attacker identifies a vulnerability in an unpatched third-party module, 777 permissions let them drop web shells, modify core files, or alter your payment gateway scripts directly. The PrestaShop 777 permissions risk is never worth the temporary convenience.
If your store cannot write files under 755 and 644, the problem is not that your permissions are too restrictive—it is that your file ownership is wrong.
Critical PrestaShop Directories and Required Permissions
PrestaShop handles a heavy mix of static assets, dynamic templates, compiled classes, and temporary downloads. Here is how permissions break down across your key operational folders:
1. The Cache Directory (/var/cache/ or /cache/)
In modern PrestaShop releases (1.7 and 8+), Symfony and Smarty write thousands of compiled PHP files, routing tables, and container definitions to /var/cache/prod/ and /var/cache/dev/. In legacy 1.6 stores, this happens inside /cache/.
These directories must be strictly writable by the web server process. Set the folder permissions to 755. When PrestaShop clears or rebuilds cache, it destroys and recreates subfolders inside this path. If your web process lacks write privileges here, your site will immediately throw a 500 error or deliver a blank white screen of death.
2. The Image Directories (/img/)
Every product picture, category banner, manufacturer logo, and regenerated thumbnail lives inside /img/. To prevent PrestaShop image directory write permissions failures when uploading new catalog assets or regenerating thumbnails:
- Ensure
/img/and all its subdirectories (like/img/p/,/img/c/) are set to755. - Individual image files (
.jpg,.png,.webp) should be644. - Block script execution inside
/img/. While PrestaShop needs to write image files here, no PHP file should ever run from this directory.
3. The Module Directory (/modules/)
When you install a module from the back office or let a module write custom configuration assets, PrestaShop extracts files into /modules/. The top-level /modules/ directory must be set to 755, and its files must be 644.
A common PrestaShop module permissions error occurs during automated module upgrades: if an existing module file is owned by a different system user (such as an FTP user or Git deployment process), the PrestaShop back office updater will fail halfway through, leaving your store with broken classes or crashed hooks.
4. Other Writable Directories
Do not overlook these paths, which also require write access for normal day-to-day operations:
/upload/and/download/— Used for customer file uploads and downloadable virtual products (755)./translations/and/app/Resources/translations/— Used by the internationalization system (755)./config/— Contains configuration files. While the directory is755, sensitive files likeapp/config/parameters.phpshould be locked down to640or600so only the web process and root can read database credentials.
Fixing Ownership Mismatches: The Hidden Root Cause
Here is an insight from years of server audits: nine out of ten permission errors in PrestaShop have nothing to do with numeric permissions. They are caused by user-group ownership mismatches.
Your web server runs as a specific system user—typically www-data on Ubuntu/Debian, nginx or apache on RHEL/CentOS, or an isolated account user under cPanel/CloudLinux. If you log into your server via SSH as root and run a CLI command like:
php bin/console cache:clear
The console command generates new cache directories owned by root:root. The next time a standard website visitor loads your homepage, the PHP-FPM process (running as www-data) tries to read or modify those root-owned cache files, fails, and serves a 500 error.
Whenever you run CLI commands or deploy code via Git, always ensure you restore ownership back to your web server user:
chown -R www-data:www-data /var/www/html/prestashop/
(Replace www-data:www-data with your server’s actual web user and group, and adjust the path to your store root.)
Step-by-Step: Applying Safe PrestaShop Permissions via SSH
If your store’s permissions are in disarray, you do not need to click through hundreds of folders in an FTP client. Connect via SSH, navigate to your PrestaShop root directory, and run this standard recovery routine:
-
Set directory permissions to 755:
find . -type d -exec chmod 755 {} + -
Set file permissions to 644:
find . -type f -exec chmod 644 {} + -
Ensure proper user and group ownership:
chown -R www-data:www-data . -
Protect critical configuration files:
chmod 600 app/config/parameters.php(orconfig/settings.inc.phpon PrestaShop 1.6)
This four-step reset instantly resolves write errors across your cache, image uploads, and module installations while locking out unauthorized write vectors.
Hardening Image and Upload Folders Against Execution
Fixing permissions is only half the battle; hardening execution paths completes your security posture. Even with 755 permissions, a compromised module might allow an attacker to upload an obfuscated .php file disguised as a .png into /img/ or /upload/.
If you are on Apache, ensure the native .htaccess file inside /img/ and /upload/ contains rules that disable script engines:
<FilesMatch ".(php|php5|php7|php8|phtml|pl|py|jsp|asp|sh|cgi)$">
Require all denied
</FilesMatch>
If you are running Nginx, Apache .htaccess rules are ignored. You must add explicit location blocks in your server configuration:
location ~* ^/(img|upload|download)/.*.php$ {
deny all;
return 403;
}
This guarantees that even if a rogue file lands in an image or cache folder, your server will refuse to execute it.
If you want to ensure your infrastructure, checkout workflows, and server configurations are optimized for maximum stability and speed, take a look at our full suite of PrestaShop development and security services.
Running into persistent server bugs, broken upgrades, or permission conflicts that break your storefront? With over 10 years of dedicated experience and more than 200 successful PrestaShop projects delivered, I can help you resolve critical issues quickly and safely. Reach out today to get expert help tailored to your store’s architecture.
Frequently Asked Questions
Why is PrestaShop showing 500 error after clearing cache?
This almost always happens when the cache was cleared via SSH using the root account, creating files owned by root that the web server user cannot modify. Fix it by running chown -R www-data:www-data var/cache/ from your store root.
Can I use 777 permissions on PrestaShop var/cache folder?
No, you should never use 777 permissions on your cache folder because it allows any process or local user to write arbitrary executable code. Instead, set the folder to 755 and assign ownership to your active web server user (such as www-data or nginx).
How do I fix image upload errors in PrestaShop back office?
Verify that your /img/ folder and all its subdirectories are set to 755 permissions and owned by the PHP process user. Additionally, ensure your server’s PHP settings for upload_max_filesize and post_max_size are large enough to accommodate the images you are uploading.
