Common causes
- wp-content or its subfolders are owned by a different user than PHP runs as
- Folder permissions too restrictive (e.g. 555 or 644 on directories)
- Disk quota or inode limit reached on the hosting account
- Files were uploaded via SFTP as root or another user on a VPS
- An open_basedir or SELinux policy blocks writes to the path
How to fix it
- Check disk space and inodes. In cPanel check Disk Usage and the inode count in the stats sidebar; on a VPS run df -h and df -i. Clear old backups and cache folders if you are at the limit.
- Check ownership. Over SSH run ls -la wp-content. On a VPS all WordPress files should belong to the user PHP-FPM runs as (often www-data or a per-site user).
- Set standard permissions. Directories should be 755 and files 644. Never use 777, which lets any process on the server write to your site.
- Fix ownership on a VPS. Run chown -R with the correct PHP user and group on the WordPress directory, then retry the install.
- Check the upgrade folder. Make sure wp-content/upgrade exists and is writable, or delete it so WordPress can recreate it. Also verify WP_TEMP_DIR if it is set.
- Ask your host on shared hosting. If ownership is wrong on shared hosting you usually cannot fix it yourself; ask support to reset file ownership for your account.
SSH (VPS, adjust user and path)
cd /var/www/example.com
sudo chown -R www-data:www-data .
sudo find . -type d -exec chmod 755 {} \;
sudo find . -type f -exec chmod 644 {} \;
sudo chmod 640 wp-config.phpHow to stop it happening again
- Deploy files as the same user PHP runs as
- Monitor disk and inode usage, especially with backup plugins storing archives locally
- Avoid editing permissions with blanket chmod -R commands