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.

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: Correct File Permissions on Cloudways

Use this table when manually checking or setting permissions via SSH on a standard WordPress installation:

Bulk-set via SSH from your app root: find public_html -type f -exec chmod 644 {} \; for files and find public_html -type d -exec chmod 755 {} \; for directories.

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.

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.