Repeated wrong permissions on App Service WordPress wp-content directory

Question

Repeated wrong permissions on App Service WordPress wp-content directory

Phil Huhn 0

I am running WordPress App Service on Linux. When I am in WordPress admin console on the Plugin panel, I get the following message:

/var/www/wordpress/wp-content is write-able. When finished installing the plugin, change the permissions back to the default: chmod 755 /var/www/wordpress/wp-content. Permissions are currently 777.

I am able to navigate to >_ SSH </> Application and change the permissions on the wp-content directory.

cd /var/www/wordpress
ls -l
chmod 755 wp-content
ls –l

The first listing, “ls -l”, shows the changed permissions (755) but the next listing shows the initial permissions (777) on the directory. I don’t understand what is happening. How to get the permission change to stick?

Abhinaba Das 115 Reputation points Microsoft External Staff Moderator

2026-07-12T18:28:13.7166667+00:00

Thank you for contacting us about the WordPress issue. We have begun looking into it and will share our suggestions with you as soon as possible. If you have any additional details or concerns in the meantime, please let us know. We appreciate your patience while we work on this
Praneeth Maddali 12,670 Reputation points Microsoft External Staff Moderator

2026-07-13T02:11:20.58+00:00
Hi @Phil Huhn

Thanks for the clear explanation and the exact commands you ran — that helps a lot.

This is expected behavior on Azure App Service for Linux with WordPress. Your wp-content directory sits on the platform’s persistent storage — a dedicated Azure Files share mounted into the container. On this mount, the permission mode is controlled by the storage layer itself, which is why your chmod 755 appears to work temporarily but immediately reads back as 777.

You don’t need to force it to 755. The warning in the WordPress admin (and plugins like W3 Total Cache) is generic advice meant for traditional LAMP servers. On App Service it is safe to ignore. The 777 permission here is not a security risk — the storage share is private to your app, and access is only possible through authenticated channels (Kudu/SSH/FTP).

The managed WordPress image intentionally keeps wp-content writable so plugin/theme installs, uploads, and auto-updates continue working across restarts and scale-out. This is tied to the setting WEBSITES_ENABLE_APP_SERVICE_STORAGE=true.

Quick Recommendations:

Continue managing plugins and themes through the WordPress dashboard — it works normally despite the warning.

Avoid scripting recurring chmod or startup commands — they won’t persist and may interfere with updates.

For additional hardening (this doesn’t affect the 777), add to your wp-config.php: define('DISALLOW_FILE_EDIT', true);

Keep WordPress core and plugins updated, and monitor logs via App Service > Monitoring > Log stream if needed.

Reference :

https://learn.microsoft.com/en-us/azure/app-service/wordpress-faq

https://learn.microsoft.com/en-us/azure/app-service/reference-app-settings?tabs=kudu%2Cdotnet

https://learn.microsoft.com/en-us/archive/blogs/waws/things-you-should-know-web-apps-and-linux#you-cannot-change-permissions-on-the-home-directory-when-persisting-storageapplies-to-web-app-for-containers

Kindly let us know if the above helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.
Praneeth Maddali 12,670 Reputation points Microsoft External Staff Moderator

2026-07-15T10:15:44.1066667+00:00

Hi @Phil Huhn

just following up to see if your issue has been resolved or if you had a chance to review my earlier comment?
Phil Huhn 0 Reputation points

2026-07-18T20:57:08.2066667+00:00

In my case, the /var/www/wordpress/wp-content folder is configured via WordPress plugin W3 Total Cache (in the CDN section) and the contents are stored in a Microsoft Azure Storage blob space. As I understand it, the Azure blob storage space can be shared by multiple servers and is controlling the permission. In the Azure Portal the blob storage container points to the wp-content folder. I've added the Access Control rule of Azure Container Storage Owner and selected all 3 users. Unfortunately, the Access Control rule hasn't worked and the chmod command didn't hold.
Praneeth Maddali 12,670 Reputation points Microsoft External Staff Moderator

2026-07-21T05:42:04.61+00:00
Hi @Phil Huhn

Thank you for the additional information and for explaining your W3 Total Cache configuration.

Based on what you've described, the Azure Blob Storage container configured through W3 Total Cache is separate from the local /var/www/wordpress/wp-content directory permissions on Azure App Service. The wp-content directory is hosted on App Service persistent storage, and its permissions are managed by the underlying storage layer. As a result, changes made using chmod are not retained and the directory may continue to appear as 777, which is expected behavior on this platform.

It's also important to note that assigning the Storage Blob Data Owner role or modifying Azure Storage access controls affects access to Blob Storage resources only. These permissions do not control or modify Linux filesystem permissions within the App Service container, which is why the RBAC changes did not affect the chmod behavior.

Since W3 Total Cache uses Azure Blob Storage for CDN or offloaded content, while the local wp-content directory remains managed by App Service storage, the two permission models operate independently. Therefore, the behavior you're seeing does not indicate a problem with your Azure Storage configuration. [Repeated w...rosoft

As an additional WordPress security best practice, you may consider adding the following setting to your wp-config.php file to prevent file editing from the WordPress Admin portal:

define('DISALLOW_FILE_EDIT', true);

Reference :

https://learn.microsoft.com/en-us/azure/app-service/wordpress-faq

https://learn.microsoft.com/en-us/archive/blogs/waws/things-you-should-know-web-apps-and-linux

https://learn.microsoft.com/en-us/azure/app-service/reference-app-settings?tabs=kudu%2Cdotnet

If you are experiencing any actual functional issues such as plugin installation failures, upload failures, cache write errors, or CDN synchronization problems, please let us know and share the specific error message or screenshot so we can investigate further.

Kindly let us know if the above helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.

1 answer

Your answer

Abhinaba Das 115 Reputation points Microsoft External Staff Moderator

2026-07-12T18:28:13.7166667+00:00

Thank you for contacting us about the WordPress issue. We have begun looking into it and will share our suggestions with you as soon as possible. If you have any additional details or concerns in the meantime, please let us know. We appreciate your patience while we work on this
Praneeth Maddali 12,670 Reputation points Microsoft External Staff Moderator

2026-07-15T10:15:44.1066667+00:00

Hi @Phil Huhn

just following up to see if your issue has been resolved or if you had a chance to review my earlier comment?
Phil Huhn 0 Reputation points

2026-07-18T20:57:08.2066667+00:00

In my case, the /var/www/wordpress/wp-content folder is configured via WordPress plugin W3 Total Cache (in the CDN section) and the contents are stored in a Microsoft Azure Storage blob space. As I understand it, the Azure blob storage space can be shared by multiple servers and is controlling the permission. In the Azure Portal the blob storage container points to the wp-content folder. I've added the Access Control rule of Azure Container Storage Owner and selected all 3 users. Unfortunately, the Access Control rule hasn't worked and the chmod command didn't hold.

Answer 1

On WordPress on Azure App Service for Linux, the filesystem under /var/www/wordpress is managed by the platform/container image. Certain paths can be reset or re-applied by the runtime, so manual chmod changes on core WordPress directories like wp-content may not persist.

To avoid permission issues, rely on the default App Service configuration and WordPress’ own plugin/theme installation mechanisms rather than forcing 777 or repeatedly changing permissions. If the environment is reporting wp-content as writable and then reverting to 777, that behavior is controlled by the image/startup scripts and cannot be permanently overridden by a simple chmod in SSH.

For plugin-related or “critical error” issues, use the recommended troubleshooting flow instead of changing directory permissions:

Enable WordPress debugging in wp-config.php to see detailed errors.
Use App Service → Monitoring → Log Stream and WordPress debug logs to identify plugin/theme problems.
Temporarily disable plugins/themes by renaming their folders under wp-content if needed.
Verify PHP version and other configuration in App Service → Configuration → General Settings to ensure compatibility with plugins.

If the permission behavior is breaking the site (for example, causing critical errors), follow the WordPress-on-App-Service troubleshooting guidance and, if necessary, redeploy or roll back to a known-good state rather than trying to persist manual permission changes.

References: