To solve these issues display in process of installing Drupal as:
Go to your "drupal" folder and make permission 777
Then open "sites" folder and make it 777
Choose "default" folder and make it 777
Open "files" and choose "setting.php" to change permission to 777
You are giving public right to execute read and write files in your directories. Clearly not a good idea.
Check this link for more infos on what to do in production environnement (it also explains basic chmod values wich you seem to not be understanding) : https://www.drupal.org/node/244924
Some normal permissions would be 0644 for files and 0755 for directories. Then i.e. settings.php since there is no need for it to be writable you should fully forbid writing.
If only 0777 "solves" your issue, maybe problem are not permission values but file owner. It happens that you upload files with one (FTP) account Apache is running website with some other, which is not allowed to write over first one. So changing file owner could solve the issue.
After every WordPress release appears on my admin panel, my website .htaccess file becomes chmod 444 or 777 and overwrite my htaccess settings. I try to change the chmod and edit it from ftp and from the console. But It keeps returning to chmod 444 or 777. The work-around solution is that i have to update wordpress from the administration panel, then I can change the .htaccess chmod to 644 and edit it without any problem.
Please help me resolve this issue.
Thank you,
The proper way to upgrade WP is via the admin panel....
If you download the installation and do it all manually, then you need to check the umask for your user... which applies the permissions for new files.. actually there could be other reasons why the permissions change to 444, but the real solution is to upgrade via admin panel
Solved the issue by renaming wp-admin to wp-admin_old and wp-includes to wp-includes_old . Then I uploaded latest and fresh folders from the official website: https://wordpress.org/. DO NOT FORGET TO DELETE 'wp-admin_old' & 'wp-includes_old'! Because they have a hidden backdoor that keeps changing your wordpress settings. That's why renaming them then deleting them is the only way to get rid of malware.
This probably happened due to an infection, which may have changed more than the core Wordpress files. Simply updating the wp-includes directory may not permanently solve the problem: https://wordpress.stackexchange.com/a/191570/20963
I succesfully set up a VPS LEMP-stack with Wordpress. When I am trying to install plugins from the WP backend, I am prompted with the following message:
To perform the requested action, WordPress needs to access your web server.
Please enter your FTP credentials to proceed. If you do not remember your
credentials, you should contact your web host.
When I enter my SFTP-account details, which I am using to access the server with FileZilla, I get the following error message:
Failed to connect to FTP Server 192.XXX.XXX.X:21
I read various tutorials, which suggest to install a FTP server, in particular vsftpd and then to store your FTP-User-details in the wp-config.php to avoid further authentication requestst. The problem I see is that, FTP is considered as severly unsecure and I would like to avoid hard-coding my user details into my WP-installation.
What is the safest, recommended way to deal with this problem?
I don't know if it is the safest method or not. But pasting this code in wp-config.php once solved my problem:
define('FS_METHOD', 'direct');
sudo chown -R www-data:www-data wp_site_root
sudo chmod -R g+rw wp_site_root
solved my problem.
Remember to set files and directories permission in this way:
chown -R www-data:www-data /var/www
find /var/www/ -type d -exec chmod 755 {} \;
find /var/www/ -type f -exec chmod 644 {} \;
define('FS_METHOD', 'direct');
adding the above given command on the wp-config file will resolve that issue paste it below
define( 'WP_DEBUG', false );
#MrNerdy,
I should have also elaborated on the fact that there should be some other folders you'll want to give permissions to. Read the documentation on it here to understand exactly what you should do regarding security: http://codex.wordpress.org/Changing_File_Permissions
Also, be careful to only install trusted plugins. I've seen dozens of sites hacked because of badly coded plugins / themes, etc. Good luck.
For me it was bitnami related settings issue. This post helped me. There could be multiple reason:
Permission issue on the files and folders.
The FS_METHOD should be
"direct" in wp-config.php file.
Remove FTP configuration from wp-config.php if you are
migrating from bitnami to manage it on your own.
If anyone is running into this issue using MAMP Pro.
Make sure you're running the server as the user that has permission for the root wordpress directory.
Under SETTINGS > Ports look for "Run server as" and in the drop down choose the same system user that has permission to access the root wp folder.
Add this line to wp-config.php:
define('FS_METHOD', 'direct');
Then change the permission If you're using an ec2 instance.
cd /var/www/html/wordpress
if your'e using shared hosting then remove some files in your server and try again. it will work. its because your disk quota may be exceeded.
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 urgently need some advice as to why I have to change all files I want to edit to 777? I think there maybe sound thing wrong with the apache user not being the owner. I can only edit any file if I set 777 so anyone can edit it. Any help much appreciated.
cheers
You shouldn't have to. Often this comes down to the group being incorrect. My wp-content is owned by the user apache and the group apache on a standard Slackware Linux installation.
File permissions are 664 on these. For me, I do:
chown -R apache.apache wp-content
chmod -R o-w wp-content
chmod -R gu+rw wp-content
This web page on the wordpress.org website seems to be addressing your issue exactly: http://wordpress.org/support/topic/file-permissions-avoiding-777
This isn't really a thing that can be controlled from wordpress, but seems to have some relation to the way your hosting company configures its servers.