How to Reset File and Folder Permissions on Cloudways

Cloudways lets you reset file and folder permissions from the Application Settings panel in under a minute, without SSH. Common triggers for a permissions reset include a 403 Forbidden error, a “Permission Denied” message, or WordPress plugins and themes failing to update. The dashboard reset restores all files in your public_html directory to the correct defaults.

This guide covers the dashboard method step by step, plus the SSH command alternative for users who prefer the terminal, how to check current permissions before running a reset, and how to fix a single file without touching the entire site. There is also a section on files that should have different permissions from the reset defaults, specifically wp-config.php and .htaccess.

How to Confirm the Problem Is a Permission Error

Before running a reset, confirm you are dealing with a permissions issue rather than something else:

• Browser shows a 403 Forbidden error: the page returns a 403 status code and text like “403 Forbidden” or “Access Denied.” This is the most common sign of a permissions problem on a web-accessible folder.
• WordPress shows “Permission denied” during a plugin or theme update: the update process cannot write to wp-content/plugins or wp-content/themes because those directories are not writable.
• Server logs show a permissions error: in the Cloudways error log (Application → Monitoring → Logs), look for entries like Permission denied: access to /home/master/applications/yourapp/public_html/ or client denied by server configuration. The error log will identify the exact file or directory causing the problem before you run a full reset.

If the browser shows a 500 error rather than a 403, check the PHP error log first, 500 errors are usually PHP fatal errors rather than permissions issues.

What Causes Permission Errors on Cloudways?

There are several common triggers:

• A plugin or theme changed permissions incorrectly: some plugins temporarily modify file permissions during installation and fail to restore them, leaving files or directories in an unusable state.
• A developer restricted permissions: if you took over a site from another developer, they may have tightened permissions in a way that blocks your updates or file access.
• The site was compromised: malware sometimes changes file permissions to prevent removal of infected files or to maintain access after a cleanup.
• An incomplete or interrupted file transfer: uploading files via FTP with incorrect transfer settings can leave files with wrong permission bits.

If you are not sure which file is causing the error, view the application logs on Cloudways first. The error log will show the exact file path and the specific permission error before you run a full reset.

What Are the Default Cloudways Permissions?

When you run a reset, Cloudways sets every file and folder in your public_html webroot to these values:

• Directories: 774: owner can read, write, execute; group can read, write, execute; others can read only. The execute bit on directories means “can enter and list contents.” This is the standard for web-accessible folders on a managed server where the web server process runs as the group user.
• Files: 664: owner can read and write; group can read and write; others can read only. This is correct for PHP files, images, CSS, JavaScript, and most WordPress assets.

Only files and folders within the webroot (public_html) are affected. Server configuration files outside this directory are not changed.

How to Check Current File Permissions on Cloudways

Before running a reset, it can help to see which permissions are currently set and confirm they are wrong. There are two ways to check without changing anything:

Via SSH

SSH into your server and navigate to your application directory:

ls -la /home/master/applications/your-app/public_html/

The output shows each file and directory with its permission string. A correctly-set directory shows drwxrwxr-x (774). A correctly-set file shows -rw-rw-r-- (664). If you see drwxr-xr-x (755) on the uploads directory, WordPress cannot write new uploaded files to it, which causes the “Unable to create directory” error.

Via SFTP Client

Connect to your server using FileZilla, Cyberduck, or WinSCP with your Cloudways SFTP credentials. Navigate to the application’s public_html directory. Right-click any file or folder and choose “File Permissions” or “Properties”, the SFTP client shows the current octal permission value and lets you confirm whether it matches the expected defaults.

How to Reset File and Folder Permissions (Dashboard)

You need to be the account owner or have full application access to run this reset.

Step 1 - Log In

Log into your Cloudways account using your credentials.

Step 2 - Select Your Application

Click Servers in the top menu and select the server where your application is deployed. Click the www button and choose your application from the list.

Step 3 - Application Settings

In the left navigation panel, click Application Settings. You will land on the General tab by default. If you are on a different tab, click General at the top of the settings panel to switch.

Step 4 - Reset Permissions

Scroll down to the Reset File/Folder Permissions section. Choose the user from the dropdown:

• Application user: use this if you access the site through SFTP with application-level credentials. This is the right choice for most individual site owners.
• Master user: use this if you manage multiple applications from the master SSH or SFTP account. Typically used by agencies managing several client sites on one server.

Select the appropriate user and click Reset Permissions. Cloudways processes the reset and confirms when it is complete.

Step 5 - Verify via SSH (Recommended)

SSH into your server and navigate to the application’s public_html directory:

cd /home/master/applications/your-app/public_html

Replace your-app with your application folder name. Run ls -la and check the output. Directories should show drwxrwxr-x (774) and files should show -rw-rw-r-- (664). If you see these values, the reset worked.

How to Reset Permissions via SSH (Alternative Method)

If you prefer to run the fix from the terminal rather than the dashboard, or if you only need to fix permissions on a specific subdirectory without touching the entire webroot, you can use find with chmod.

SSH into your Cloudways server, then navigate to your application directory and run these two commands:

• Reset all directories: find /home/master/applications/your-app/public_html -type d -exec chmod 774 {} \;
• Reset all files: find /home/master/applications/your-app/public_html -type f -exec chmod 664 {} \;

These match exactly what the dashboard reset does. Running them separately means you can target a subdirectory like wp-content/uploads if only that folder has a problem, without touching the rest of the site.

For the uploads directory specifically, 775 and 664 are also acceptable. The uploads folder needs to be writable by the web server process, which runs as the group user. Both 774 and 775 achieve this on Cloudways.

How to Fix Permissions on a Single File Without a Full Reset

If only one file has the wrong permissions and you do not want to reset the entire site, you can change it directly:

Via SSH

Run chmod with the exact value you need:

• Fix a single file: chmod 664 /home/master/applications/your-app/public_html/wp-config.php
• Fix a single directory: chmod 774 /home/master/applications/your-app/public_html/wp-content/uploads

Via SFTP Client

Connect with FileZilla, Cyberduck, or WinSCP. Right-click the file, choose “File Permissions” or “Properties,” and enter the numeric permission value (664 for files, 774 for directories). The client sends the chmod command on your behalf without you needing SSH access.

Special Permissions: wp-config.php and .htaccess

The dashboard reset sets every file in public_html to 664, which is correct for most files. Two files need more careful treatment:

wp-config.php contains your database credentials and secret keys. Setting it to 664 means it is readable by the group user, which on a shared or multi-application server could expose those credentials to other processes. For better security, set wp-config.php to 640 (readable only by owner and group, not by others) or 600 (owner only) after running the dashboard reset:

• chmod 640 /home/master/applications/your-app/public_html/wp-config.php

.htaccess controls Apache rewrite rules and is normally 644. The dashboard reset sets it to 664, which is fine functionally, but 644 is the more common convention. If you have strict security requirements, tighten it after the reset:

• chmod 644 /home/master/applications/your-app/public_html/.htaccess

WordPress regenerates .htaccess automatically if you save your permalink settings, so this will not break anything.

How to Fix “Unable to Create Directory wp-content/uploads” on Cloudways

If WordPress shows an error like “Unable to create directory wp-content/uploads/2026/06. Is its parent directory writable by the server?” after trying to upload a file, the wp-content/uploads folder does not have write permission for the web server user. This is a permissions issue, not a WordPress bug, and the fix takes about 30 seconds.

Quick Fix via the Cloudways Dashboard

1. Log in to your Cloudways account.
2. Go to Servers, select your server, then click your application name.
3. Open Application Settings and click the Reset File Permissions button.
4. Confirm the reset. Cloudways restores all files and folders in public_html to their correct defaults, including setting wp-content/uploads to 775 (read, write, and execute for owner and group).
5. Try uploading a file in WordPress to confirm the error is gone.

Quick Fix via SSH

If you prefer SSH, run these two commands after connecting to your Cloudways server:

find /home/master/applications/your-app/public_html/wp-content/uploads -type d -exec chmod 775 {} \;
find /home/master/applications/your-app/public_html/wp-content/uploads -type f -exec chmod 664 {} \;

Replace your-app with your application’s folder name (visible in Cloudways under Application Management › Application Settings). The first command sets all subdirectories to 775, and the second sets all files to 664. Together they restore the standard WordPress upload permissions without touching the rest of your site.

Why This Happens

The most common causes of this error on Cloudways:

• After a site migration: Files uploaded via a migration plugin or SFTP as a different user leave incorrect ownership. The web process cannot write to folders it does not own.
• After a cPanel-to-Cloudways move: cPanel sets uploads to 755 by default. WordPress on Cloudways needs 775 to write new files.
• After a WordPress update: Occasionally, a core update or a plugin that modifies file permissions sets uploads to 755 rather than 775.
• Fresh Cloudways install: If you created the application without enabling the one-click WordPress installer and instead moved files manually, the uploads folder may never have been set to the correct permissions.

The Cloudways dashboard reset resolves all of these in one click. If the error returns after the reset, the issue is likely a recurring process (such as a plugin or deployment script) resetting permissions back to 755. In that case, check the Cloudways application logs guide to identify what is modifying the directory after each reset.

Cloudways Permissions for WordPress Uploads and WooCommerce

The wp-content/uploads directory needs specific attention because it is the only directory in a standard WordPress installation that both the web server and WordPress itself write to regularly (image uploads, attachment files, transient caches, and plugin-generated assets all land here). Getting uploads permissions wrong causes two distinct failures:

• “Unable to create directory” error: WordPress cannot write new uploaded files because the uploads directory or a subdirectory (year/month folders) is not writable. The dashboard reset normally resolves this, but if Cloudways sets the parent directory to 774 and the uploads subfolder was manually set to 755, new uploads fail even after a reset.
• Images not showing after upload: If the uploads directory is readable but the month-based subdirectory (e.g. /wp-content/uploads/2026/06) has 700 permissions, WordPress creates it successfully but the files are unreadable by the web server, resulting in broken image icons.

Correct Permissions for wp-content/uploads

The uploads directory and all its subdirectories should be 775 or 774:

• chmod 775 /home/master/applications/your-app/public_html/wp-content/uploads

If year/month subdirectories already exist with wrong permissions, run the recursive command to fix them all at once:

• find /home/master/applications/your-app/public_html/wp-content/uploads -type d -exec chmod 775 {} \;
• find /home/master/applications/your-app/public_html/wp-content/uploads -type f -exec chmod 664 {} \;

The dashboard reset covers the full public_html tree, so it will fix uploads too, but running these targeted commands avoids touching wp-config.php and other sensitive files unnecessarily.

WooCommerce-Specific Directories

WooCommerce creates several directories inside wp-content/uploads that have additional requirements:

• woocommerce_uploads: Stores downloadable product files. This directory is protected by an .htaccess file that blocks direct browser access, but WordPress still needs write access to add new files. It should be 775.
• wc-logs: WooCommerce writes order and error logs here. If this directory is not writable, WooCommerce silently fails to log errors, making debugging difficult. Set it to 775.
• woocommerce_transient_files: Used by some WooCommerce extensions for temporary file generation (PDF invoices, export files). Needs 775 to function correctly.

After running a permissions reset on a WooCommerce store, test these specific functions: upload a new product image, download a digital product (if you sell them), and check that the WooCommerce logs are being written in WooCommerce → Status → Logs.

After Resetting: What to Test

Once the reset completes, check these to confirm the issue is resolved:

• Reload the site and confirm the 403 or Permission Denied error is gone
• Try installing or updating a plugin or theme inside WordPress to confirm write access works
• Clear the server cache (Application Settings → Varnish & Nginx → Purge Cache) to prevent visitors from seeing a cached error page

When a Reset Won’t Fix the Problem

If permissions reset correctly but the error returns within hours or days, something is actively changing them back. This is a strong indicator of a malware infection or a misconfigured process with elevated access. In this case:

• Run a malware scan using a plugin like Wordfence or MalCare
• Check the error logs for recurring scripts executing with elevated access (look for unfamiliar file paths appearing repeatedly around the same time)
• Audit recently modified files: find /home/master/applications/your-app/public_html -mtime -1 -type f (shows files modified in the last 24 hours)
• Contact Cloudways support to inspect server-level logs and identify processes modifying your files

A one-time permission corruption from a plugin update is fixable with a dashboard reset. Recurring changes need investigation at the security level before the reset will hold. For debugging, checking the Cloudways error logs shows the exact file path causing a 403 and confirms whether permissions or something else is the cause.

Quick Reference: File Permissions on Cloudways

Cloudways uses 664 for files and 774 for directories as its defaults, which differ from the generic WordPress.org recommendation of 644/755. The reason is architecture: on Cloudways, both the web server process and the PHP-FPM process run as the group user, so group write access (the extra “4” in 664 and 774) is required for plugins and themes to install and update through the WordPress admin. If you apply strict 644/755 permissions from a generic guide, plugin updates will fail.

Bulk-set to Cloudways defaults via SSH from your application’s public_html: find . -type f -exec chmod 664 {} \; for files and find . -type d -exec chmod 774 {} \; for directories. Run chmod 640 wp-config.php separately afterward.

Cloudways File Permissions After a Site Migration

Migrations are the most common trigger for incorrect permissions on Cloudways. When you move a site from shared hosting or another VPS using Duplicator or All-in-One WP Migration, the archive preserves file ownership and permissions from the source server. Those values often do not match what Cloudways expects.

After any migration to Cloudways, run the dashboard permission reset (Application Settings > Reset Permissions) before testing the site. This reassigns ownership to the Cloudways application user and corrects numeric permissions throughout public_html. If the reset does not fix all issues, use the SSH commands above to target specific directories the dashboard reset missed. WooCommerce stores and sites with large uploads directories sometimes need a targeted fix rather than a full reset. The dashboard reset is safe to run on a live site and does not take the application offline.

How Long Does a Cloudways Permission Reset Take?

On most Cloudways applications, the dashboard permission reset completes in under 30 seconds. Larger sites with tens of thousands of files in public_html (typically WooCommerce stores with many product images or sites with years of media uploads) may take 2-3 minutes. The reset runs in the background; the Cloudways dashboard shows a spinner and then a confirmation message when it is done.

The reset does not take the site offline and does not interrupt active visitors. PHP-FPM continues serving requests while the permission change runs in the background. The only visible effect to visitors is the same as at any other moment during normal operation. You do not need to enable maintenance mode before running a permission reset.

If the reset appears to hang for more than five minutes without a confirmation, refresh the dashboard and check whether the permissions have already been applied by running ls -la /home/master/applications/your-app/public_html/ via SSH. On very large sites the API response can time out before the underlying process finishes, but the process continues running on the server regardless.

Final Word: How to Reset File and Folder Permissions on Cloudways

The dashboard reset takes under a minute and covers the entire public_html directory in one click. The SSH method gives you more precision if you only need to fix one subdirectory or want to target specific files. After running either method, manually tighten wp-config.php to 640 to reduce exposure of your database credentials. If the error returns after a reset, treat it as a security issue and investigate what is changing the permissions back. Correct file permissions are also required for PHP-type cron jobs on Cloudways, since scripts fail silently if the server user cannot read the target file.

To get started, sign in to Cloudways and navigate to Application Settings. For the broader security context including SSL, WAF rules, and other permission-denied scenarios, see our Cloudways security and SSL guide. When permissions errors produce 403 responses, the Cloudways application logs guide shows how to read nginx-error.log to confirm the exact file and permission type causing the block. See our full Cloudways review for more on what the platform includes.