PrestaShop File Permissions: The Correct Setup

Understanding Linux File Permissions

Every file and directory on a Linux server has three sets of permissions: one for the owner, one for the group, and one for others (everyone else). Each set controls three actions: read (r), write (w), and execute (x). These permissions are represented numerically using octal notation, where read equals 4, write equals 2, and execute equals 1. The values are added together for each set, producing a three-digit number like 755 or 644.

For example, a permission of 755 means the owner can read, write, and execute (7 = 4+2+1), while the group and others can only read and execute (5 = 4+0+1). A permission of 644 means the owner can read and write (6 = 4+2+0), while the group and others can only read (4 = 4+0+0). Understanding this system is fundamental to running a secure and functional PrestaShop store.

Beyond the numeric permissions, every file has an owner and a group associated with it. On a web server, the web server process (Apache or Nginx) runs as a specific user, typically www-data on Debian/Ubuntu or apache/nobody on CentOS/RHEL. The web server needs to read your PrestaShop files to serve them, and it needs write access to certain directories for uploads, caching, and configuration.

Correct Permissions for PrestaShop Directories and Files

The general rule for PrestaShop is straightforward: directories should be 755 and files should be 644. This gives the owner full control, while the group and others can read (and execute/traverse in the case of directories) but cannot modify anything. The web server user should be the owner of all PrestaShop files, or at minimum belong to the group that owns them.

To set these permissions across your entire PrestaShop installation, connect to your server via SSH and run:

find /var/www/html/prestashop -type d -exec chmod 755 {} \;
find /var/www/html/prestashop -type f -exec chmod 644 {} \;

Replace /var/www/html/prestashop with the actual path to your PrestaShop installation. The first command finds all directories and sets them to 755. The second finds all files and sets them to 644.

However, certain directories require write access by the web server. These directories need special attention because PrestaShop writes to them during normal operation:

• /var/cache/ — Smarty compiled templates and Symfony cache
• /var/logs/ — Application log files
• /upload/ — Customer file uploads
• /download/ — Virtual product files
• /img/ — Product images, category images, CMS images
• /modules/ — Module installation and updates
• /themes/ — Theme cache files
• /translations/ — Translation export files
• /config/ — Configuration files (parameters.php)
• /app/config/ — Symfony configuration
• /app/Resources/translations/ — Symfony translations

If the web server user is the owner of these files (which is the recommended setup), then 755/644 permissions are sufficient. If the web server runs as a different user, you may need to adjust group permissions or ownership.

Setting Correct Ownership with chown

Ownership is just as important as permissions. The chown command changes the owner and group of files. For a typical Debian/Ubuntu server running Apache or Nginx, the web server user is www-data:

sudo chown -R www-data:www-data /var/www/html/prestashop

The -R flag applies the change recursively to all files and subdirectories. On CentOS or RHEL systems, replace www-data with apache or nginx depending on your web server.

A common alternative approach is to set the owner to your SSH/FTP user and the group to the web server user. This lets you edit files via FTP or SSH while still allowing the web server to read them:

sudo chown -R yourusername:www-data /var/www/html/prestashop

In this case, directories that need write access by the web server should be set to 775 (group write) and writable files to 664:

find /var/www/html/prestashop/var -type d -exec chmod 775 {} \;
find /var/www/html/prestashop/var -type f -exec chmod 664 {} \;
find /var/www/html/prestashop/img -type d -exec chmod 775 {} \;
find /var/www/html/prestashop/img -type f -exec chmod 664 {} \;

Shared Hosting vs VPS vs Dedicated Server

The hosting environment dramatically affects how file permissions work in practice. Understanding the differences is critical to setting up permissions correctly.

Shared Hosting

On shared hosting, you typically access files via FTP or a file manager in cPanel/Plesk. The PHP execution model varies by host, but most modern shared hosts use PHP-FPM or suPHP, meaning PHP runs as your user account rather than as the global web server user. This simplifies permissions significantly: since PHP runs as your user, it can already read and write to your files with standard 755/644 permissions. You rarely need to change ownership on shared hosting because everything already belongs to your account.

If you encounter permission errors on shared hosting, check with your host whether they use suPHP or PHP-FPM. If they use the older mod_php model, you may need to set some directories to 777 temporarily (though this is not recommended for security reasons). Most reputable hosts have moved away from mod_php precisely because of these permission complications.

VPS (Virtual Private Server)

On a VPS, you have full control. This is the most common setup for serious PrestaShop stores. You should ensure the web server user owns the PrestaShop files or, at minimum, belongs to a group that has read access. The recommended setup is:

1. Set the owner to www-data:www-data (or your web server user)
2. Use 755 for directories and 644 for files
3. Use SSH with sudo for making changes, or add your SSH user to the www-data group

To add your SSH user to the web server group:

sudo usermod -a -G www-data yourusername

Then set the group write bit on directories you need to edit:

chmod g+w /var/www/html/prestashop/themes/your-theme/

Dedicated Server

Dedicated servers follow the same principles as VPS setups. The main difference is performance: you have more resources, so you can run PHP-FPM with dedicated pools per site. Each pool can run as a different user, providing better isolation if you host multiple PrestaShop stores on the same server.

PHP Execution Models: suPHP vs mod_php vs PHP-FPM

The way PHP is executed on your server directly determines which user writes files and therefore what permissions are needed.

mod_php (Apache module)

This is the oldest and simplest model. PHP runs as part of the Apache process, meaning all PHP code executes as the Apache user (typically www-data or apache). The problem is that files created by PHP (cache, uploads, etc.) are owned by the web server user, not your account. This can make FTP management difficult and creates security concerns on shared hosts because all sites run as the same user.

With mod_php, PrestaShop files should be owned by the Apache user, and permissions of 755/644 work correctly. However, this model is largely obsolete on modern servers.

suPHP

suPHP runs PHP as the file owner rather than as the web server user. This means if your files are owned by yourusername, PHP also runs as yourusername. This is more secure on shared hosting because each account is isolated. Standard 755/644 permissions work perfectly with suPHP because the PHP process and the file owner are the same user.

One important caveat: suPHP actually rejects files with permissions of 777 or files owned by other users. If you set 777 on a suPHP server, PHP will refuse to execute those files, showing a 500 Internal Server Error instead.

PHP-FPM (FastCGI Process Manager)

PHP-FPM is the modern standard. It runs PHP as a separate process from the web server, with configurable user/group per pool. On a VPS, PHP-FPM typically runs as www-data. On shared hosting with CloudLinux or similar, each account gets its own PHP-FPM pool running as that account's user.

PHP-FPM combined with Nginx is the recommended setup for PrestaShop performance. The standard 755/644 permission scheme works well. Ensure the PHP-FPM pool user matches the file owner or has appropriate group access.

Why 777 Permissions Are Dangerous

Setting permissions to 777 means anyone on the system can read, write, and execute the file. On shared hosting, this means other accounts on the same server could potentially read your database credentials from parameters.php or inject malicious code into your PHP files.

Even on a VPS where you are the only user, 777 is unnecessary and indicates a misconfiguration. If the web server cannot write to a directory with 755 permissions, the solution is to fix the ownership, not to open permissions to the world. Here is what you should do instead of using 777:

1. Check who the web server runs as: ps aux | grep -E "apache|nginx|httpd"
2. Check file ownership: ls -la /var/www/html/prestashop/
3. Fix ownership: sudo chown -R www-data:www-data /path/to/directory
4. Set correct permissions: chmod 755 /path/to/directory

If you find a tutorial or forum post recommending 777 for PrestaShop, it is outdated and dangerous advice. The only legitimate use of 777 is for /tmp directories that have the sticky bit set (shown as 1777), which is a system-level configuration, not something you apply to PrestaShop files.

Docker Considerations for PrestaShop

Running PrestaShop in Docker introduces additional complexity to file permissions. Inside the container, the web server runs as www-data with a specific UID (often 33 on Debian-based images). On the host system, your user has a different UID. When you use Docker bind mounts to mount your PrestaShop files into the container, the file ownership is determined by the numeric UID, not the username.

This means files created on the host as your user (e.g., UID 1000) will appear inside the container as UID 1000, which is not www-data (UID 33). The web server inside the container may not be able to write to these files.

Solutions for Docker permission issues include:

• Match UIDs: Create a user inside the container with the same UID as your host user, or change the web server to run as your UID.
• Use chown in entrypoint: Add a startup command that runs chown -R www-data:www-data /var/www/html when the container starts. This is simple but can be slow for large installations.
• Set group permissions: Add your host user and www-data to the same group (by GID), then use 775/664 permissions.
• Named volumes: Use Docker named volumes instead of bind mounts. Docker manages permissions automatically, but you lose direct filesystem access from the host.

For development environments with bind mounts, the most practical approach is to run a chown command after syncing or deploying files:

docker exec your-container chown -R www-data:www-data /var/www/html/modules/your-module/

Be aware that operations inside the container (like installing a module) may create files as www-data, while operations on the host create files as your host user. This constant UID mismatch is the most common source of permission problems in Dockerized PrestaShop setups.

Troubleshooting Common Permission Errors

"Failed to open stream: Permission denied"

This error means PHP cannot read or write a file. Check ownership and permissions of the file mentioned in the error. The most common cause is that the web server user does not own the file or directory. Fix it with:

sudo chown www-data:www-data /path/to/file
sudo chmod 644 /path/to/file

"Unable to write to cache directory"

PrestaShop's Smarty template engine and Symfony framework both write cache files. If the var/cache/ directory is not writable, you will see this error. The cache directory must be owned by the web server user:

sudo chown -R www-data:www-data /var/www/html/prestashop/var/cache/
sudo chmod -R 755 /var/www/html/prestashop/var/cache/

After fixing permissions, clear the existing cache by deleting the contents of the cache directories:

sudo rm -rf /var/www/html/prestashop/var/cache/prod/*
sudo rm -rf /var/www/html/prestashop/var/cache/dev/*

"Cannot upload image" or "Cannot install module"

Image uploads go to the img/ directory, and module installations write to the modules/ directory. Both must be writable by the web server user. Additionally, check that the upload_max_filesize and post_max_size PHP settings are large enough for your files, as these can produce similar-sounding errors.

sudo chown -R www-data:www-data /var/www/html/prestashop/img/
sudo chown -R www-data:www-data /var/www/html/prestashop/modules/

"index.php is not writable" during updates

PrestaShop's auto-updater needs write access to nearly every file in the installation. Before running an update, set ownership of the entire installation to the web server user. After the update completes, you can restore more restrictive ownership if desired.

White page after changing permissions

If you see a blank white page after changing permissions, you may have accidentally removed execute permission from directories. Directories need the execute bit to be traversed. A directory with permission 644 (no execute) is effectively inaccessible. Always use 755 for directories, never 644.

You can also check the PHP error log for more details:

sudo tail -50 /var/log/apache2/error.log
# or for Nginx:
sudo tail -50 /var/log/nginx/error.log

Permissions reset after FTP upload

Some FTP clients set their own default permissions when uploading files. Check your FTP client settings for a "default permissions" or "umask" option. Set it to create files as 644 and directories as 755. Alternatively, run the permission fix commands after each FTP upload.

Security Best Practices Beyond Permissions

Correct file permissions are only one layer of security. Consider these additional measures:

• Restrict config file access: The file app/config/parameters.php contains your database credentials. Ensure it is readable only by the web server user (640 permission), not by the world.
• Disable directory listing: Add Options -Indexes to your Apache configuration or autoindex off; to Nginx to prevent visitors from browsing directory contents.
• Protect .htaccess files: PrestaShop places .htaccess files in sensitive directories. Do not delete them.
• Remove install directory: After installation, delete the /install/ directory completely. PrestaShop warns you about this, but it is worth emphasizing.
• Set proper umask: Configure your web server and PHP-FPM with a umask of 0022 so new files are created with 644/755 permissions by default.

By understanding Linux permissions, matching them to your hosting environment, and following the guidelines in this article, you will avoid the most common PrestaShop permission problems while maintaining a secure server configuration.

For more details, read our guides: PrestaShop Security Hardening: The Complete Checklist and Choosing Hosting for PrestaShop: What Matters and What Is Marketing.