This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(240, 22%, 33%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESW%3C/text%3E%3C/svg%3E)
Having set up a WordPress web site using an Azure App Service, I checked the folder permissions. Looks like they need to be changed to 755, which is recommended. Tried FTP and changed permissions to 755 do not stay. Tried a WordPress plugin that can change these permissions, and while the plugin indicated successful permission change to 755, also this did not persist. As another option, signed in to my Azure subscription, as owner/global administrator, called up an SSH terminal, entered a suggested command (chmod 755 /home/site/wwwroot/wp-content), and again the change to 755 failed.
Not sure if this is the correct or complete SSH command needed? Would appreciate if someone can suggest the full and correct command that I need to enter in the SSH terminal to change each folder's permission to 755.
Or any other way to achieve this change in folder permissions.
Thank you for your help.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(153.6, 92%, 24%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
Just to clarify, are you leveraging blessed image or custom Docker image?
To make open a direct SSH session with your container,https://<app-name>.scm.azurewebsites.net/webssh/host or for using SSH support with custom Docker images.
Configure SSH in a custom container ( as outlined in the doc here) - SSH console app from the web app service.
I understand you have already tried the following cmdlet, please add -R and then check.
chmod -R 755 /home/site/wwwroot/wp-content
The -R option is used to apply the permission change recursively to all subdirectories and files within the specified directory.
Typically, to set the permissions for files/directories, you will need to create custom Docker Container with your app built into the image. For data persistence, you will need to create a symlink for the directories in their container to "/home".
Checkout these docs for more info:
Reference similar discussion thread
Open an SSH session to a Linux container in Azure App Service
App service blessed images here
Kindly let us know how it goes, I’ll be more than happy to follow-up further.
Just following-up from my previous comment, if the answer helped (pointed you in the right direction) > please click Accept Answer.
__
__
(I have converted my comment to answer). Thanks for your patience and collaboration!
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(80, 52%, 17%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EWH%3C/text%3E%3C/svg%3E)
so is there an actual solution to this or should it just be ignored? Wordpress runs as a container but no matter what you cannot do a chmod and have it set, still stays as 777 not sure if this matters or not on azure but no matter what I have tried i cannot set it to 755
Can you provide the full error
it can be probably permission error
so you can go with sudo before command
cd /home/site/wwwroot
sudo find ./wp-content -type d -exec chmod 755 {} \;
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(67.2, 17%, 16%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJD%3C/text%3E%3C/svg%3E)
I am having the same problem.
I installed WordPress on App Services and it automatically installed a plugin for me called W3 Total Cache. That plugin gives me this message when I go into it from the Dashboard.
/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.
This is something YOU gave me. So if it normally gives me that warning, then why not have a way to satisfy it which is easily comprehensible to the people who only know WordPress and conventional commodity hosting?
I have tried an FTP program, the WordPress plugin WP File Manager, and by using Kudu. All attempts have failed. An explanation as to why it is difficult or impossible to change file permissions in your cloud service would be appreciated.
Also, is this a false warning, or should I be concerned.
It might be advisable to use something besides App Services for a scaling WordPress website. I am trying to determine that for myself and for others which may use my sevices in setting up WordPress sites.
Thank you for these suggestions.
A beginner with Azure, I am not sure about the container, but I believe it is a docker container. Adding the "-R" to the command produced what appeared to be the terminal working on the change with recursion, but when completed, and I independently checked with an App Service's WP security plugin, I got the same result: wp-contents was still not set to 755.
Again as a beginner, not sure how to find the "full error" but when I tried
cd /home/site/wwwroot
I successfully CD'd to the directory, but then when I tried
sudo find ./wp-content -type d -exec chmod 755 {} ;
I got back:
-ash: sudo: not found
(I am using the Azure app service internal SSH terminal. Not sure I can install anything in it to resolve the sudo issue?)
So no success yet, but hopefully this feedback may provide additional clues to what I am doing wrong, and additional suggestions to fix it.
Best Wishes,
Additionally, <I have added multiple comments here, to provide more clarity>
Just to highlight, you can SSH into your app container and install components. However, when your app is restarted, anything that you install will be gone. Why is that? That's the way Docker works. When your app starts, App Service runs your Docker image and create a Docker container. Your app runs inside of that container, and the file system contains only what is in the Docker image. If your Docker image doesn't install a particular component, it won't be there when your container starts.
If you want to install a particular component, ensure that you do it in a Dockerfile so that the component is included in your Docker image.
Please checkout this doc section “X. Connect to the container using SSH”.
Thanks for the follow-up and additional info. Apologies for any confusion, please let us know I'll follow-up further.
I wonder if this is the problem?
You cannot change permissions on the /home directory when persisting storage.
When you persist storage with the WEBSITES_ENABLE_APP_SERVICE_STORAGE app setting, we mount a location in Azure Storage to the /home mount point. The permissions on this are 777. You cannot change these permissions, even if you attempt to do so from an initialization script or from SSH.
The setting can be changed in the CLI to false (https://learn.microsoft.com/en-us/azure/app-service/configure-custom-container?pivots=container-linux&tabs=debian#use-persistent-shared-storage):
az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=false
Then the changes in permissions may possibly be accomplished in the Azure App Service's SSH terminal. Then the settings could hopefully be reversed to true?:
az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=true
Not sure however if this would not delete the sites contents, or do other "damage" to the site, causing need to rebuild it, or worse, need to start over, recreate the site?
So, not going to try this possible (not sure it would even accomplish resetting permissions?) solution until fully learning what problematic consequences this can cause.
Any suggestions would be appreciated.
Thank you for your help.
BTW the best reading I can get about the container is that it is a standard "single container"
Thanks for the follow-up and additional info.
Yes, as you mentioned and noted in the article you linked, disabling persistent storage may cause data loss if your application relies on the storage for data persistence. Just to highlight, before making any changes, it is important to back up your data and ensure that your application can function without persistent storage.
If you need files to be persisted in scale operations or across restarts, you should add this app setting and set it to "true". If you don't require file persistence, you can set this app setting to false.
The absence of this app setting will result in the setting being "true". In other words, if this app setting does not exist in your app, you will see the /home directory mapped to Azure Storage.
Kindly let us know, I'll follow-up with you further offline.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(108.80000000000001, 33%, 20%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDM%3C/text%3E%3C/svg%3E)
Hi Ajkuma,
I would think we need to not be set to 777 for production in WordPress. Are you suggesting that if we set WEBSITES_ENABLE_APP_SERVICE_STORAGE to false, then any files that are changed by WordPress (IE: new images) will not persist across "reboots" of the App Service?
Thanks for the follow-up and additional info. Apologies for any confusion, just to provide better understand the flavor of Azure App service, you can have different flavor/version of WebApp, as follows:
1.Code + Windows – You select the Application stack and deploy your code.
2.Code + Linux (WebApp Linux) - App Service on Linux provides pre-defined application stacks on Linux with support for languages such as .NET, PHP, Node.js and others. These are blessed images, predefined by platform. Here you just deploy your code.
3.Docker Container + Linux (WebApp for Container) – custom image (code already part of the image, and not deployed separately) - container image become containers at runtime.
4.Docker Container + Windows (WebApp for Windows Container) – custom image – container image become containers at runtime.
If you haven’t done already, --Kindly checkout the process here - >>Enable diagnostics logging for apps in Azure App Service
https://docs.microsoft.com/azure/app-service/troubleshoot-diagnostic-logs#access-log-files
You can inspect the log files from Kudu console at https://yourwebsite.scm.azurewebsites.net/api/logs/docker, and fetch more details on the issue
On either (code or container ) flavor - As a best practice, you shouldn't install components using SSH because they won't persist.
I understand you’re attempting to Azure WordPress wp-content folder permission to 755, could you please share more details about your scenario/requirement.
I'll follow-up with you further.
An interesting article that focuses on the different and, with certain configuration caveats, better security model used by Azure app service containers:
One reading of this information appears to indicate that unchangeable file/folder permissions may not be the final decider of security. Instead, since it appears that only the site owner/administrator can access/upload files, folders through routes like FTPS (for example, using FileZilla), SSH, etc. which require Azure owner/administrator username and password sign-in/authentication. So, a strong password and maintaining its security may be what is needed.
Disabling FTP/FTPS in the Azure settings can be done, and does not for example, prevent adding, activating new WordPress plugins within the WordPress site. Of course the FTP/FTPS settings can be disabled/enabled in the Azure portal as needed, and more importantly owner/administrator strong passwords can be changed at routine intervals in line with best security practices, MFA enabled, and app service WordPress activity logs reviewed.
So, the unchangeable permissions may be worked around at the next higher level to prevent access/uploads.
HTH
Thanks for the follow-up. Yes, your understanding is correct. The article you shared is from one of my colleague.
While unchangeable permissions may be worked around at the next higher level to prevent access/uploads, as you mentioned, it is still important to maintain strong security practices to ensure the safety of your data. Kindly let me know if you have any other questions or concerns.
Also, please take a look at this Azure App service doc : Operating system functionality on Azure App Service -Linux apps in App Service run in their own containers. You have root access to the container but no access to the host operating system is allowed.
If the answer helped (pointed you in the right direction) > please click Accept Answer.
Thank you ajkuma for verifying my understanding. Since the app service container is set up as a standard single container I believe that the only way, instead of recreating it in another container, would be to assure that the Azure administrator sign in is secure since it would be required for anyone attempting to modify the app service WordPress files/folders. MFA, strong passwords, disabling FTPS, possibly additional steps can be taken to harden security.
I would accept your answer as "accepted" since it verified my understanding and added suggested reading, but it appears that I cannot do this for a comment. In any event, thank you for your helpful follow-up.
@Stephen Wartel , Thanks for the follow-up and additional info.
In regards to access, App Service uses port 2222 for SSH into your app's container (port is not exposed over the Internet). No matter how you use SSH in your WebApp, all SSH traffic is handled through an endpoint on port 443. If you're not using SSH, you don't have to worry about closing port 2222 because it's not exposed to the Internet.
Kudu (SCM) is the engine behind a number of features in Azure App Service. Ones with Kudu access are ones owning the site and can access Kudu/for SSH.
Please check this doc; https://github.com/projectkudu/kudu/wiki/Accessing-the-kudu-service#security
The root password must be exactly Docker! as it is used by App Service to let you access the SSH session with the container. This configuration doesn't allow external connections to the container. Port 2222 of the container is accessible only within the bridge network of a private virtual network and is not accessible to an attacker on the internet.
App Service Linux security FAQs
-- [You're correct, I have now converted by Comments' to Answer, you may Accept**.** Thanks for your valuable feedback. ]
