chmod Permissions for PHP Script Folders

Permissions answer a simple question: can the PHP process create a file in a directory? A listing saves but the photo does not: almost always permission denied on upload. Cache does not write: the admin panel slows down or throws warnings. It is not an "image uploader bug" until chmod and owner are checked.

On Windows in MicroServer, POSIX permissions usually do not get in the way. The pain is stronger on Linux shared hosting and VDS.

Basic scheme

• Directories: 755 (drwxr-xr-x).
• Files: 644 (-rw-r--r--).
• Database-password config: no wider than necessary; 600 or 640 if owners are correct.

777 on the whole site "so it works" is a bad habit. On shared hosting it may survive for years until a virus writes a shell into upload. Better align ownership.

What must be writable

It depends on the package, but usually:

• upload directories: upload/, uploads/, files/, images/;
• cache and temporary directories: cache/, tmp/, temp/;
• sometimes a session or runtime directory if the script writes it inside the project.

Engine PHP files do not have to be writable. The web server only needs to read them.

Owner matters more than the number

On a VDS, a PHP-FPM pool runs as www-data, nginx, or a separate site user. If the archive was uploaded as root, 755 will not help when the directory belongs to root and the group cannot write.

chown -R www-data:www-data /var/www/site
find /var/www/site -type d -exec chmod 755 {} \;
find /var/www/site -type f -exec chmod 644 {} \;

Use your actual user name; check the pool in /etc/php/*/fpm/pool.d/. In ISPmanager, the user often matches the system user of the site.

On shared hosting, the file manager creates files under your login, and PHP often runs under the same one; then 755 is enough. If PHP uses another uid, the panel may have a "fix owner" button or recommend 775 on upload.

Typical log errors

failed to open stream: Permission denied means no write permission to the directory or file.

Unable to create directory means the parent directory is not writable, or open_basedir cuts the path.

Move uploaded file failed means PHP accepted the temporary upload but could not move it to the target directory.

Read the exact path in the message. Fix that path, not the whole www.

SELinux and open_basedir

Some VDS environments have SELinux in addition to chmod. Symptoms look like permission denied even with correct 755. That becomes chcon and httpd_sys_rw_content_t context work. On shared hosting, open_basedir is more common: the script cannot write outside allowed paths. Then moving upload "one level up" fails not because of chmod.

Upload security

The upload directory must accept files, but it does not need to execute PHP. Ideally, forbid script execution in upload through Nginx/Apache config or .htaccess. Otherwise one uploaded .php disguised as an image becomes a backdoor.

Do not store password configs inside a writable directory unless necessary.

Windows and local development

In MicroServer, NTFS permissions usually do not block writing to the project folder. If it cannot write locally, check the configured path, antivirus, and that the disk is not read-only. See local server.

Connection with installation

Permissions are set after unpacking and before or after the installer, as the readme says. General order: installation. If 500 is caused by inability to write sessions/cache: 500 error. Migration while preserving uploads: script migration.

On Nginx, do not forget client_max_body_size; otherwise a large image dies before permissions are checked: Nginx + PHP-FPM.

How to identify the PHP owner

On VDS, create phpinfo or run:

ps aux | grep php-fpm

Check user/group in the pool. On shared hosting, the panel often says "site runs as user X". An archive uploaded through the panel file manager is usually already owned by X. An archive uploaded through root SSH is not.

775 vs 755

If the web user belongs to the directory owner's group, 775 on upload plus group write can work. If users are different and groups are unrelated, use a common user, ACL, or, worse, 777. On a normal VDS, aim for one uid for the pool and files.

Files inside upload are often created as 644, which is fine. The directory must allow new files.

One-command diagnosis

As the PHP user (su/sudo -u www-data), try:

touch /var/www/site/upload/test_write.txt

If it works, permissions are fine; look for a code or path error. If it does not, read permission denied and fix the owner. Do not start with chmod -R 777 /.

Cache and sessions

Besides upload, check cache and session directories. Symptoms: slow admin panel, constant logouts, warnings in logs. A session.save_path outside the project must also be writable; sometimes /var/lib/php/sessions has wrong permissions after a package update.

After restoring from backup

A tar unpacked as root restores root:root. The site looks restored, but uploads are dead. Immediately chown to the pool user. Backup checklist: backup, migration: migration.

On shared hosting, provider restore usually sets permissions itself, but not always for custom paths outside www.

Checklist

1. Who is the PHP-FPM/Apache user.
2. Who owns the upload directory.
3. 755/644 baseline, writable only where needed.
4. No PHP execution in upload.
5. Config is not 777.
6. touch test and image upload from the admin panel.

If after permission fixes the site still returns 500, read the log: the new issue may be database or syntax, not permission denied: 500 error, MySQL. Environment requirements: requirements.

Another common shared-hosting case: the file manager shows 755, but PHP runs in a mode where the file owner is another uid from the cloud pool. Then the Beget/Timeweb/ISPmanager "fix owner" button or a host-support request to align the site's UID helps. chmod 777 only hides the symptom and leaves upload executable for everyone. After ownership is fixed, return to 755/644 and upload one test file from the admin panel. Clean installation if upload directories must be created manually: installation.