So, I've copied the install tree of a site I'm developing to another machine. After updating settings.php to the proper db and base_path, and making sure that the file permissions for /sites/default/files/ are set to 755 (chmod -R 755 files), the file settings page (Configuration -> Media -> File System) insist that "The directory sites/default/files exists but is not writable and could not be made writable." I've experimented with 777 permissions to no avail. Any thoughts?
Change ownership of the files directory to apache, or whatever your web user is.
chown -R apache.apache files
If you don't have access to change ownership for some reason, then making all files recursively writable should work.
chmod -R a+w files
Related
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 have read several ways to solve the problem of permissions in WordPress to install themes and plugins from the WordPress administration.
As I understand the problem is that the owner of the folder where WordPress is installed must be the user who manages the web server (read postdata). In my case with Apache and AWS, www-data.
However, by changing the owner to www-data (even just changing the group to this user), I lose SSH access to the server. In this case I had to ask the administrator of the entire server to access from its user and restore the owner and permissions of the folder.
I am using Amazon Web Services with Ubuntu 16.0.4 LTS where I have access to a main user and the installation of WordPress is located at the root of the user, i.e. /home/myuser/
I am accessing via SSH with a .pem key and with myuser#publicdns
What can I do?
Thank you so much.
PD: WordPress in this guide says that the owner always has to be the ftp web server owner (i.e. myuser) and never the webserver, I agree.
I hate having to answer my own question but maybe I can help others solve problems easily and fast. This is what worked for me:
BEFORE DOING ALL OF THIS YOU SHOULD TAKE NOTE OF ALL PERMISSIONS, OWNERS AND GROUPS OF ALL THE FOLDERS & FILES WE ARE CHANGING HERE BECAUSE YOUR WEBSITE MAY FAIL AFTER CHANGING THESE SETTINGS. ALL HOSTS HAVE DIFFERENT CONFIGURATIONS.
As long as you don't exit the session, you may be able to return all the changes you have made with sudo privileges.
If your WordPress installation is in the root folder of the user, eg: /home/myuser/
Take note of permissions, owners and groups:
With ls command and the -a -l flags you can see all files using long listing format. Do this being in /home and /home/youruser/ paths.
cd /home
ls -al
cd /home/youruser
ls -al
Copy the output and save it in some text file.
Prevent losing SSH access:
The owner of the folder must be the user you are accessing with.
sudo chown youruser /home/youruser/
I also have set the group of the folder myuser.
sudo chgrp youruser /home/youruser/
Set the permissions of this folder with 751 (I think the important thing here is that the owner has full access)
sudo chmod 751 /home/youruser/
The permissions for the hidden folder .ssh must be 700 for top folder, 600 for files inside the folder and the owner & group must be youruser
sudo chmod 700 ~/.ssh/
sudo chmod 600 ~/.ssh/*
sudo chown -R youruser ~/.ssh/
sudo chgrp -R youruser ~/.ssh/
Solve Plugins & Theme installation problems:
I'm still unsure if this solution is right for site security. However, I think you can apply this fix and then return the changes. The website should run smoothly in both cases.
I have changed permissions for folders and files via sftp in Nautilus. If you are using .pem key remember to add the key using ssh-add path/to/your/key.pem
then connect to the server sftp://youruser#yourpublicdns
Make multiple click in folders wp-content, wp-admin, wp-includes and do Right click -> Properties (or Ctrl + I), change to permission tab and click in the "Apply permissions to Enclosed files" button on the bottom of the window, set:
Files
Owner: Read and Write
Group: Read only
Others: Read only
Folders
Owner: Create and delete files.
Access to files.
Access to files.
This will apply the changes to files and folders inside these three folders selected. Depending on the speed of your internet and how much files do you have, this may take some minutes to finish.
Make multiple click in remaining files and do Right click -> Properties (or Ctrl + I), change to permission tab and set
Owner: Read and Write
Group: Read and Write
Others: Only Read
AND LAST
Change the owner and the group of all the WordPress installation files, i.e. all the files inside /home/youruser
sudo chown -R www-data wp*
sudo chgrp -R www-data wp*
This make changes for all the files that start with the "wp" word recursively. To remaining files, I have made the changes manually. There are better ways like find command but that changed hidden folders too so I decided to do manually.
Apply the corresponding changes to files to the .htaccess as well.
NOTE: Test your website. Access to it, access to your WordPress admin, try installing plugins and themes, open another terminal (DON'T CLOSE the one you were writing the commands) and try to SSH into your webserver. If you have problems use the backup and revert the process.
Hope this helps.
I am getting error accessing my admin panel. The error is due to plugin. I fixed the issue by renaming the plugin folder from cpanel and changed it back. Since then,i couldn't download any plugins and get the error
Installation failed: Could not create directory.
You need to set permission on plugin folder/directory, now the user does not have permission to create folder/directory in plugin folder/directory.
You need to set permission on wp-content and all inside folder/directory to 755.
You can set permission via terminal
sudo chmod -R 755 wp-content
wp-content should me you folder path for Linux server path should be /var/www/html/project_folder/wp-content
OR
you can set permission via FTP. Right click on wp-content folder click on permission menu and set 755 permission to the folder.
The permissions or ownership on wp-content/plugins is incorrect. That directory should have a 775 permission set.
If its already that then reapply 755 and checked “apply recursively to all directories and files.
If you use a docker container or docker-compose, you also need to give permission to the database volume.
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.
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/