I'm setting up a new website. most files are not editable by WordPress.
I am using a virtual machine on google cloud console. It's Ubuntu 18.04 LTS LAMP stack. I have tried editing permissions of the files through both Filezilla and the ssh prompt on gcloud. like it describes here. I think i have a different problem.
I am brand new and just learning so I'm sorry if the answer is obvious. I found that if I go in and manually set permissions for files to 775 in the SSH WordPress is able to edit some files. But i cannot edit permissions of some files even after i am in root
sudo su
Apart from permissions you have to change the Owner of the Files to the web server user ( most cases, especially those using apache www-data ) .
The command to do that is the below
$ sudo chown -R www-data:www-data /path/to/wordpress/
the usual path of a website on a ubuntu server is /var/www/domain.com/ but of course that depends !
Wish you the best!
change all files and folders permission as follow:
enter your public_html folder and execute this two commands
find . -type d -exec chmod 0755 {} \;
find . -type f -exec chmod 0644 {} \;
My issue was Wordpress somehow wanted to use "apache" as the user. Changing the ownership from nginx:nginx (which is what runs my web daemon) to apache:nginx worked.
I recommend trying this on ONE file and confirming with the "site health" tool to make sure it is YOUR problem before doing a global change!
chown apache:nginx ./*.php
I was getting the same error "Some files are not writable by WordPress:
wp-load.php" recently as I moved to a different host provider. The error was shown in the Site Health window from WordPress.
To fix this, all you have to do is to change the permission of the file(s). You can do this easily by using the tool called FileZilla. I use this tool for all my FTP actions.
Connect to your server and right-click on the file and select File permissions.
And finally, change the permission to 0644.
I'm running WordPress on my VPS with CentOS 7 LAMP stack.I've followed this guide to set permissions, i.e. I've run
sudo chown apache:apache -R *
to ensure that my wordpress directory is owned by apache:apache.
I've also set WordPress directory and file permissions with these commands:
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
(I had to prefix the above commands with sudo)
Normally I manage the server by logging in through SSH using myuser, where myuser belongs to the apache group and the wheel group.
I have 3 problems:
Any file CRUD command in the WordPress directory still requires me to prefix the command with sudo, or else I get a permission error. Since myuser belongs to apache and apache owns the directory, I'm confused as to why I still need to prefix the commands with sudo.
Similar to problem 1, any git command such as a git pull requires me to prefix the command with sudo or else I get a permission error.
When I try to automatically update theme files from my WordPress dashboard web interface, I get permission errors. Interestingly, I'm able to install/update plugins via the WordPress dashboard without any permissions errors.
Any ideas on what I'm missing?
Look at:What does mode_t 0644 mean?
644 means:
* (owning) User: read & write
* Group: read
* Other: read
CRUD is a write command, so you're not allowed to do that. Either you change to 664 or keep using sudo. Basically any writing procedure on the file system would not be allowed without sudo since your user is not the owner (event though he is in the group).
#fortuneRice, CentOS7 features selinux enabled by default, which is often the cause of many hard-to-understand file permission errors.
I would suggest the following:
Edit /etc/sysconfig/selinux
Change SELINUX=permissive (or whatever SELINUX is currently set to in the file) to SELINUX=disabled
Reboot your server (not just the apache web server, but the whole machine)
Disabling SELINUX completely is not a good idea, therefore if this procedure works, you should re-enable SELINUX and fix its configuration.
Configuring SELINUX can be a difficult task, so I suggest you read up on google how to do that :)
chown -R -f user:apache /path of the directory
I also faced that issue and solved this problem by changing the PHP handler.
it is important to use PHP Handler that will run as the file owner.
After I installed HTTP2 and another few features on the way, I changed the PHP handler.
I am running WHM/CPanel on my VPS, and I fixed my issue following these steps:
Under WHM > Software > EasyApache 4 > Customize
Look for the: mod_suphp under the Apache Modules tab and make sure it is enabled, and if you just turned it on to install, follow step two.
Go to the Review tab and click the Provision button to save.
Under Whm > Software > MultiPHP Manager look for PHP Handlers tab.
Choose suphp as the handler for the current PHP version.
That's it. It was the PHP handler.
Edit: I notice that suphp had a conflict with one of my user uploads directories that I am adding dynamically to images a watermark. It seems the suphp handler had permission to upload but doesn't show the pictures.
I also tried the lsapi for the PHP Handler, and it seems to work correctly with the file's permissions and attaching via the .htaccess file watermarks for images.
My configuration
- Mac OS 10.9
- XAMPP
- ProFTPD
- WordPress 3.8.3
Unlike most other posts on the internet for the same problem, I was not on some hosting website rather on a locally hosted instance on Mac.Everytime I tried to access the site, I got the error that the server was unable to locate the wp-content directory.
In macOS httpd server is executed as user "daemon".
Therefore you need to change ownership of htdocs to daemon user:
$ sudo chown -R daemon:daemon htdocs
After a few hours of tweaking around, I did the following
Delete previous installation of WordPress and install fresh copy
Set the permissions on wp-content directory via termina shell using the command chmod -R 777 wp-content. This sets the permission of all underlying files and folders as well
I went to this link and used the solution provided here - http://wordpress.org/support/topic/auto-update-failure-in-wordpress-27?replies=17#post-982487
Essentially, I added the following line at the bottom of my wp-config file - putenv('TMPDIR=' . ini_get('upload_tmp_dir'));
Vola!! it worked and I can now focus on more important things.
I installed a WordPress blog in my local system. But when I try to add plugins from admin it asks for FTP access. What do I need to configure for WordPress to be able to upload without FTP?
Try to add the code in wp-config.php:
define('FS_METHOD', 'direct');
If you are using Ubuntu.
sudo chown -R www-data:www-data PATH_TO_YOUR_WORDPRESS_FOLDER
"Whenever you use the WordPress control panel to automatically install, upgrade, or delete plugins, WordPress must make changes to files on the filesystem.
Before making any changes, WordPress first checks to see whether or not it has access to directly manipulate the file system.
If WordPress does not have the necessary permissions to modify the filesystem directly, you will be asked for FTP credentials so that WordPress can try to do what it needs to via FTP."
Solution:
In order to find out what user your instance of apache is running as, create a test script with the following content:
<?php echo(exec("whoami")); ?>
For me, it was daemon and not www-data. Then, fix the permission by:
sudo chown -R daemon /path/to/your/local/www/folder
If during installation of a plugin, Wordpress asks for your hostname or FTP details.
Then follow these steps:
Login to your server and navigate to /var/www/html/wordpress/.
Open wp-config.php and add this line after define(‘DB_COLLATE’)
define('FS_METHOD', 'direct');
If you get "Could not create directory" error. Give write permissions to your wordpress directory in recursive as
chmod -R go+w wordpress
NOTE. For security, revoke these permissions once you install a plugin as
chmod -R go-w wordpress
I changed the ownership of the wordpress folder to www-data recursively and restarted apache.
sudo chown -R www-data:www-data <folderpath>
It worked like a charm!
On OSX, I used the following, and it worked:
sudo chown -R _www:_www {path to wordpress folder}
_www is the user that PHP runs under on the Mac.
(You may also need to chmod some folders too. I had done that first and it didn't fix it. It wasn't until I did the chown command that it worked, so I'm not sure if it was the chown command alone, or a combination of chmod and chown.)
I did a local install of WordPress on Ubuntu 14.04 following the steps outlined here and simply running:
sudo chown -R www-data:www-data {path_to_your_project_directory}
solved my issue with downloading plugins. The only reason I'm leaving this post here is because when I googled my issue, this was one of the first results and it led me to the solution to my problem.
Hope this one helps to anyone!
There's a lot of similar responses to this question, but none of them fully touch on the root cause. Sebastian Schmid's comment on the original post touches on it but not fully. Here's my take as of 2018-11-06:
Root Cause
When you try to upload a plugin through the WordPress admin interface, WordPress will make a call over to a function called "get_filesystem_method()" (ref: /wp-admin/includes/file.php:1549). This routine will attempt to write a file to the location in question (in this case the plugin directory). It can of course fail here immediately if file permissions aren't setup right to allow the WordPress user (think the user identity executing the php) to write the file to the location in question.
If the file can be created, this function then detects the file owner of the temporary file, along with the file owner of the function's current file (ref: /wp-admin/includes/file.php:1572) and compares the two. If they match then, in WordPress's words, "WordPress is creating files as the same owner as the WordPress files, this means it's safe to modify & create new files via PHP" and your plugin is uploaded successfully without the FTP Credentials prompt. If they don't match, you get the FTP Credentials prompt.
Fixes
Ensure the plugin directory is writable by the identity running your php process.
Ensure the identity that is running your php process is the file owner for either:
a) All WordPress application files, or...
b) At the very least the /wp-admin/includes/file.php file
Final Comments
I'm not overly keen on specifically applying file ownership to the file.php to work around this issue (it feels a tad hacky to say the least!). It seems to me at this point that the WordPress code base is leaning towards having us execute the PHP process under the same user principal as the file owner for the WordPress application files. I would welcome some comments from the community on this.
From the first hit on Google:
WordPress asks for your FTP credentials when it can't access the files
directly. This is usually caused by PHP running as the apache user
(mod_php or CGI) rather than the user that owns your WordPress files.
This is rather normal in most shared hosting environments - the files are stored as the user, and Apache runs as user apache or httpd. This is actually a good security precaution so exploits and hacks cannot modify hosted files. You could circumvent this by setting all WP files to 777 security, but that means no security, so I would highly advise against that. Just use FTP, it's the automatically advised workaround with good reason.
For me the the process that solved, to be able to work on my localhost using Ubuntu, was:
(of course you must replace myUser by your user, whoami show it for you if you dont know)
Include myself on www-data group (to be able to access and edit files without sudo):
sudo usermod -aG www-data myUser
Set myself and this group as files owners:
sudo chown -R myUser:www-data /var/www/html
Set a major permission for the group (the group must write too):
sudo find . -type f -exec chmod 664 {} \;
sudo find . -type d -exec chmod 775 {} \;
Then add this line on config.php
define('FS_METHOD', 'direct');
The easiest way to solve this problem is add the following FTP information to your wp-config.php
define('FS_METHOD', 'direct');
define('FTP_BASE', '/usr/home/username/public_html/my-site.example.com/wordpress/');
define('FTP_CONTENT_DIR', '/usr/home/username/public_html/my-site.example.com/wordpress/wp-content/');
define('FTP_PLUGIN_DIR ', '/usr/home/username/public_html/my-site.example.com/wordpress/wp-content/plugins/');
FTP_BASE is the full path to the "base"(ABSPATH) folder of the WordPress installation
FTP_CONTENT_DIR is the full path to the wp-content folder of the WordPress installation.
FTP_PLUGIN_DIR is the full path to the plugins folder of the WordPress installation.
We had the same problem as part of a bigger problem. The suggested solution of
define('FS_METHOD', 'direct');
hides that window but then we still had problems with loading themes and upgrades etc. It is related to permissions however in our case we fixed the problem by moving from php OS vendor mod_php to the more secure php OS vendor FastCGI application.
First move to your installation folder (for example)
cd /Applications/XAMPP/xamppfiles/
Now we’re going to modify your htdocs directory:
sudo chown -R daemon htdocs
Enter your root password when prompted, then finish it out with a chmod call:
sudo chmod -R g+w htdocs
I was facing the same problem!
I've added the code below in wp-config.php file (in any line) and it's working now!
define('FS_METHOD', 'direct');
define('FS_METHOD', 'direct');
Add this to wp-config.php
If the issue still persist , you can try setting permission of plugin folder to 755
Or in linux you can set it by this command
Chmod -R 755
As mentioned by Niels, this happens because the server process user can't write to the Wordpress folder.
But here's the thing a lot of articles don't explain. It's the owner of the php process, not the nginx process. If you try to change the nginx owner, it won't solve this.
To solve it, try running ps aux to see which user owns the php-fpm process. Then check that user is the same user as the owner of the wordpress folder, or can at least write to it. If the user can't write to it, you'll need to change permissions and/or ownership of the folder; or put the two users (server owner and wordpress folder owner) in a common group which can write to the folder; or change php.ini "user" property to a user that can write to the folder.
Changing the ownership of the files worked but only after I logged out of my wordpress website and logged in again. I also restarted the Apache server, but that may not be necessary.
I'm copying a Drupal 7 installation from one machine to another. Both machines are Mac OSX running current versions of MAMP. Procedure as follows:
create sql dump file
rsync -ar path/to/source path/to/destination
chmod -R 755 destination/sites/default/files
chown -R username destination
import sql dumpfile
adjust settings.php (actually, they remain the same across environments, but just checking db connect info and $base_url.)
Everything works here, on the destination side, except that the sites/default/files directory can not be made writable[sic]. Something in the directory tree and/or permissions is changing, but I can't figure out what/how. What gives?
sites/default/files needs to be writable by the web user, or writable by all users.
all users:
chmod -R a+w destination/sites/default/files
or, make apache (or whoever your web user is) the owner
chown -R apache:apache destination/sites/default/files
Note: 755 and 777 sets everything as executable. 777 would have worked, it's just not proper. Executable permission is necessary for directories, but files generally should not be executable unless they need to be.
I personally prefer making apache the owner of the files directory and all the contents inside because that's what happens anyway when Drupal writes files.
Probably you need to run restorecon on the directory for eg:
restorecon -rv default/