Bitnami/EC2 WordPress插件权限配置问题咨询

I’ve helped many Bitnami WordPress users troubleshoot exactly this kind of permission problem—even when core functionality (like thumbnail generation) seems to work, those persistent error logs are a sign that the permission setup isn’t fully aligned with how Bitnami’s web stack runs. Let’s break down the correct configuration step by step:

First, Understand the Bitnami User/Group Context #

Bitnami runs its Apache/Nginx and PHP-FPM processes under the daemon user, while default file ownership is bitnami:daemon. The key here is ensuring the web process (part of the daemon group) has sufficient write access to directories where plugins need to create/modify files—without overcompromising security.

Step 1: Reset Ownership to Match Bitnami’s Default #

First, make sure all WordPress files and folders are owned by the right user and group:

sudo chown -R bitnami:daemon /opt/bitnami/wordpress

This ensures the bitnami user (your SSH/admin user) has full control, and the daemon group (which the web process belongs to) has shared access.

Step 2: Refine Permissions (Beyond Basic 755/644) #

Your current 755/644 settings are too restrictive for plugin operations—they only let the owner write, not the group. Adjust them to:

• For directories: Give read/write/execute to owner and group, read/execute to others

  sudo find /opt/bitnami/wordpress -type d -exec chmod 775 {} \;
  

• For files: Give read/write to owner and group, read-only to others

  sudo find /opt/bitnami/wordpress -type f -exec chmod 664 {} \;
  

• Double-check high-write directories (plugins, uploads, themes) individually—these are where plugins like Regenerate Thumbnails do most of their work:

  sudo chmod -R 775 /opt/bitnami/wordpress/wp-content/uploads
  sudo chmod -R 775 /opt/bitnami/wordpress/wp-content/plugins
  

Step 3: Check for Overrides in wp-config.php #

Sometimes users add hardcoded permission settings to wp-config.php that override your system-level permissions. Look for lines like these and comment them out:

// define('FS_CHMOD_DIR', 0755);
// define('FS_CHMOD_FILE', 0644);

These lines force WordPress to use stricter permissions, which can block plugin operations even if your system permissions are correct.

Step 4: Verify Write Access #

To confirm the web process can write to necessary directories, create a quick test file in your WordPress root:

<?php
require_once('wp-load.php');
$upload_dir = wp_upload_dir();
$test_file = $upload_dir['basedir'] . '/permission_test.txt';

if ($handle = fopen($test_file, 'w')) {
    fwrite($handle, 'Success! Web process can write here.');
    fclose($handle);
    echo 'Write permission verified. Test file created: ' . $upload_dir['baseurl'] . '/permission_test.txt';
    // Uncomment below to auto-delete the test file
    // unlink($test_file);
} else {
    echo 'Error: Web process cannot write to uploads directory.';
}
?>

Access this file via your browser—if it shows success, your permissions are set correctly.

Why You’re Seeing Errors (Even With Working Thumbnails) #

The Regenerate Thumbnails plugin might be successfully writing to the uploads directory (hence the thumbnails are created), but failing when trying to modify other files—like temporary cache files, plugin configuration files, or metadata files in subdirectories. The stricter 755/644 permissions block these secondary operations, leading to error logs even if the core task completes.

内容的提问来源于stack exchange，提问作者Matts