This question could be all around but I have tried most answers and permission 777. But, still no luck.
/etc/apache2/sites-available/mysite.conf
<VirtualHost *:80>
ServerName www.mysite.com
ServerAdmin mymail#mail.com
DocumentRoot /var/www/html/wordpress
ErrorLog ${APACHE_LOG_DIR}/mysite_error.log
CustomLog ${APACHE_LOG_DIR}/mysite.log combined
</VirtualHost>
/etc/vsftpd.conf
listen=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
dirmessage_enable=YES
use_localtime=YES
xferlog_enable=YES
connect_from_port_20=YES
chroot_local_user=YES
secure_chroot_dir=/var/run/vsftpd/empty
pam_service_name=vsftpd
rsa_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
allow_writeable_chroot=YES
I set permission 777 to /usr/share/wordpress and /var/lib/wordpress.
The update creates a directory in wp-content/update inside the site directory. Linux does not set permissions automatically of child directories to those of the parent. Therefore wp-content/upload will not necessarily have 777 permissions.
Try change permissions of wp-content/update to 777. If this works it means that the owner of the WordPress folders is not the the user trying to update the site.
What worked for me was to add my ftp client to the group that the owner of the WordPress process. (How do I know which linux user Wordpress uses for plugin installation) to find the owner. and then set all directories to 775 permissions and files to 665 in the site directory.
chmod 775 $(find -type d)
chmod 665 $(find -type f)
You need to give write permissions to the relevant directories. Ideally, you should do it only for the relevant file or folder and then revert the permissions back so as to not leave your site vulnerable.
You can fix this using the following commands from the command line (assuming that you are in the WordPress root folder):
# cd wp-content
# chmod -R a+w plugins
# chmod -R a+w themes
# chmod -R a+w upgrade
The safest solution is to add Apache to the same group as the owner of the WordPress installation and change all group permissions to writeable.
A more detailed solution can be found at: http://techzog.com/wordpress/fixing-unpacking-package-could-not-create-directory-error-wordpress/
Related
I've just started to learn Linux Command Line. The setup I am on is AWS Lightsail bitnami Wordpress. I work with wordpress primarily.
I'm still confused about file permissions in Linux. Why do I have permissions denied when I sign in as the owner?
Whenever I have to ftp, overwrite, edit files and folders, I have to change the permissions settings for each affected folders and files manually via SSH.
More often than not, at the end of the day, I lost track of which folders and files' permissions I have edited and need to reset to default. I find this a chore and I believe there is a better way.
I wonder if there are lines of command that can
give me full access to all directories, folders, subfolders and files at once?
change the permissions for directories, folders, subfolders and files at once?
reset the permissions of all edited files to default/original all at once?
To check the permission of the file
sudo stat TARGETFOLDER
To change the permission of the file
sudo chmod 777 TARGETFOLDER
Bitnami Engineer here,
We configure the permissions of the WordPress' files by setting bitnami as the user owner and daemon as group owner of the files. This configuration allows you edit the files using the bitnami user and the webserver can use the daemon group to do the same. However, if you make changes to the application using the web interface (install plugins or themes), those new files are owned by daemon:daemon (the Apache and PHP-FPM services use that user and group so they generate the files using those permissions configuration) and you won't be able to edit them unless you use the command line and sudo. In that case, you can run the following commands to be able to edit those files using the bitnami user
sudo chown -R /opt/bitnami/apps/wordpress/htdocs
sudo find /opt/bitnami/apps/wordpress/htdocs -type d -exec chmod 775 {} \;
sudo find /opt/bitnami/apps/wordpress/htdocs -type f -exec chmod 664 {} \;
sudo chmod 640 /opt/bitnami/apps/wordpress/htdocs/wp-config.php
You can learn more about this here
https://www.youtube.com/watch?list=PLGgVZHi3XQNn4x0DU7Qj1r_inej3xEUda&v=nKfle7O0vN8&feature=emb_title
1 and 2, you can try chmod -R option.
3. i think it can not. you should restore it. maybe it help.
I'm currently having a problem with XAMPP and WordPress on my Mac. I've downloaded the latest XAMPP version and installed it on my Mac.
After moving WordPress into the htdocs folder, I've got an error in the Dashboard because of missing write permissions.
After searching for some minutes, I've tried to give everyone access to the htdocs folder via the Finder. But that don't helped. So I've tried this here:
https://www.zigpress.com/2018/03/19/resolving-permissions-issues-in-xampp-on-mac-high-sierra/
So I've entered my local Mac user name (johnnymarten, found out via whoami) and the group staff. The problem is, that the Apache Server don't starts anymore now and I'm getting this error message here:
INFO: Starting "apache"
ERROR: Failed to start "apache": cannot start
service: AH00543: httpd: bad user name johnnymarten
I'm coming from Windows and I don't get this done. I'm at lease done with this. Do you have any idea what I can do?
Xampp runs as root. Reset file permissions to get it to start.
1) reset directory: sudo chown -R root:admin /Applications/XAMPP
2) on my Xampp 2 directories are different:
sudo chown -R daemon:daemon /Applications/XAMPP/xamppfiles/logs
sudo chown -R daemon:daemon /Applications/XAMPP/xamppfiles/temp
3) Make a new directory for WordPress and let everyone use it.
mkdir new_dir
chmod 777 new_dir
4) Add directory to httpd.conf
<Directory "/new_dir">
Options ExecCGI FollowSymLinks
AllowOverride All
Require all granted
RewriteEngine On
RewriteBase /
</Directory>
Load WP in /new_dir
Restart Apache.
I've setup a domain through apache virtual hosts and set the permissions on the public_html directory as $USER:$USER. I also have wordpress installed in public_html/wp
When trying to add a local image to the media part of the site, wordpress threw an error saying it did not have permission to create the required folder to store the image. The directories are set to 755 and files to 644 so I assumed it was the ownership that needed to change. So I ran
sudo chgrp -R www-data /var/www/virtual-host-site.dev/*
So my ownership looked like $USER:www-data however, this still didn't give wordpress rights, so I tried
sudo chown -R www-data:www-data /var/www/virtual-host-site.dev/*
which fixed the problem. But then as a user, I have no write access to the directories. I thought adding $USER to the group www-data
sudo usermod -a -G www-data $USER
would give $USER rights like www-data, but this doesn't seem to be the case.
How do I keep my folders as 755 and files as 644 while allowing both $USER and wordpress write access to the application directories?
Thanks.
So I resolved this by changing my dev directory to www-data:www-data and changing my themes folder to $USER:www-data with the command
sudo chown -R $USER:www-data wp/wp-content/themes
I am trying to upload a file in wordpress using the Media > Add New -- Option but when I click upload I get the following error:
Unable to create directory wp-content/uploads/2012/11. Is its parent
directory writable by the server?
I have Wordpress 4.3.1 installed.
Thank you
EDIT:
I am on a shared server with: host=i686-redhat-linux-gnu and Apache. I changed the permissions to 755 and 777 of wp-content/uploads but I get the following error:
“my_file.jpg” has failed to upload due to an error Unable to create
directory wp-content/uploads/2012/11. Is its parent directory writable
by the server?
Any ideas?
You need to set folder permissions for /uploads/ and possibly for /wp-content/ , too.
Typically, both folders should be 755. You may have to temporarily raise /uploads/ to 777 and upload an image (this will also force the server to change the folder permissions and user to the correct settings), but change it back to 755 right away.
It's easiest to set permissions with an FTP client. See Filezilla and FTP Clients « WordPress Codex.
And see Changing File Permissions « WordPress Codex for the correct Wordpress permission settings:
From the codex.wordpress: Typically, all files should be owned by your user (ftp) account on your web server, and should be writable by that account. On shared
hosts, files should never be owned by the webserver process itself
(sometimes this is www, or apache, or nobody user).
Any file that needs write access from WordPress should be owned or
group-owned by the user account used by the WordPress (which may be
different than the server account). For example, you may have a user
account that lets you FTP files back and forth to your server, but
your server itself may run using a separate user, in a separate
user group, such as dhapache or nobody. If WordPress is running as the
FTP account, that account needs to have write access, i.e., be the
owner of the files, or belong to a group that has write access. In the
latter case, that would mean permissions are set more permissively
than default (for example, 775 rather than 755 for folders, and 664
instead of 644).
ssh in and navigate to the wp-content folder and type in these 2 lines:
sudo chown -R www-data uploads/
sudo chmod -R 755 uploads/
or you can use the static and full path:
sudo chown -R www-data /var/www/wp-content/uploads/
sudo chmod -R 755 /var/www/wp-content/uploads/
Do not change it to permissions 777 because that is simply insecure
I had the same problems last week. After trying all proposed solutions with no success, it occurred to me that we had SElinux enabled on the server. In my case, and maybe for many other people, SElinux was responsible of the error message:
Unable to create directory wp-content/uploads/2013/04. Is its parent directory writable by the server?
My solution is based on the one proposed here: http://doc-ok.org/?tag=selinux which could be more suitable to other people's needs.
In my case, my wordpress directory resides in my home folder on the server, to which I have ssh access. Otherwise you will have to ask your administrator.
Anyway, this is my solution.
chgrp -R apache wordpress #change wordpress with your base directory for wp..
#alternatively, chown the whole directory to apache
chmod -R 774 wordpress/wp-content #if chown by apache, the permissions can be more restrictive
In my case not only the folder ownership / group ownership had to be changed to apache. Also the SElinux label of wp-content directory had to be changed to either httpd_sys_rw_content_t or httpd_sys_content_t:
chcon -Rv --type=httpd_sys_content_t wordpress/wp-content
This did the trick for me.
More information on SElinux can be found for example at:
wiki.centos.org/HowTos/SELinux
and
fedoraproject.org/wiki/SELinux
The /wp-content/uploads directory needs to be writeable by your webserver. Assuming that you are using Apache on Linux, and that it is running as user apache (change to your appropriate user) one quick fix for this would be to run the following command from your web root.
chown -R apache.apache wp-content/uploads
chmod -R 755 wp-content/uploads
I faced the same issue and I found a better solution:
go to cpanel > phpmyadmin
select database
open wp_options table
make sql query SELECT * FROM wp_options WHERE option_name LIKE '%upload_path%'
change the path
this should fix it.
sudo chown -R www-data:www-data wp-content/uploads
Do not change the permissions to 755 if it's not necessary.
If it still doesn't work try:
chmod -R 755 wp-content/uploads
this works for me, after many weeks headache
sudo chown -R apache uploads
sudo chmod -R 755 uploads
assuming you're in wp-content
for those who stumbled on selinux permission issue, here are the steps i made to fix them. We need to allow the following selinux boolean variables to allow installing of wordpress plugins from wordpress admin console using FTP. They are httpd_can_network_connect and ftpd_full_access. They can be activated by
setsebool ftpd_full_access on
setsebool httpd_can_network_connect on
also wp-content folder should be write permissible for the ftp user used for uploading.
I'm hosting a wordpress site on ec2 and I'm trying to update my theme through the admin screen. Its asking me for Hostname and ftp username and password. Is ec2-xxx.compute-1.amazonaws.com:22 my hostname? I tried along with ec2user and root for my ftp username but no luck. What am I doing wrong?
Skip the FTP info altogether and just change the permission of the directory structure where Wordpress is installed.
VIA SSH
sudo chown -R apache:apache path/to/wordpress
sudo makes sure you execute as the root user
chown will change the owner of the directory
-R will make it recursive, so it changes all files and directories within
apache:apache is user:group
And then the path to wordpress. Could be /var/www/html/sitename.com or if you navigate to the folder where Wordpress is installed, you can use a period (.) to tell it to change the current directory.
This will make is so that you can't copy files via sftp though, so it is good to change at least the themes directory back to the ec2-user:ec2-user user and group.
So this changes back to your ssh/sftp user:
sudo chown -R ec2-user:ec2-user path/to/wordpress
You can assign the folders to the ftp user and the apache group and then make them group writable as well. This will allow you to ftp into the directory, and allow everything to be auto updated within Wordpress.
// Set the wp-contents into the apache group and then make files group writable
sudo chgrp -R apache wp-content
sudo chmod -R g+w wp-content
// This makes new files created in wp-content and all of its sub-directories group-writable.
sudo chmod g+s wp-content
Then add this to wp-config.php to force Wordpress to update when only applying this wp-content:
define('FS_METHOD', 'direct');
You can also apply to the whole Wordpress install to auto update Wordpress and not just plugins/themes. If you do this, I would recommend putting your wp-config.php file one directory above your Wordpress install though, so you can lock it down separately.
EDIT: Whenever I am having permission troubles on EC2, I go to site root directory, and paste these lines in. I apply it to the whole Wordpress install these days:
sudo find . -type d -exec chmod 0755 {} \;
sudo find . -type f -exec chmod 0644 {} \;
sudo chown -R ec2-user:apache .
sudo chmod -R g+w .
sudo chmod g+s .
I use something similar on my Mac as well.
In your wp-config.php under directives add this line:
define('FS_METHOD', 'direct');
You can simply solve this problem by doing this via ssh:
sudo chown -R apache path/to/wordpress
then
sudo chmod -R 755 path/to/wordpress
Your hostname would be ec2-107-20-192-98.compute-1.amazonaws.com.
Your username will be the username you use to SFTP to the instance normally - ec2user for some instance types, ubuntu for Ubuntu AMIs, etc. EC2 generally doesn't use passwords, preferring SSH keys, so you'll have to set a password for your account by doing passwd on the commandline.
Try adding FTP credentials to wp-config.php: http://codex.wordpress.org/Editing_wp-config.php and http://codex.wordpress.org/Editing_wp-config.php#WordPress_Upgrade_Constants
That should make WP admin stop asking for FTP details. But depending on how you've set up permissions via the command line, may have to go to the command line to edit files like wp-config.php . And you may not have sufficient permissions to upload and for WP to unzip a theme.
As per other answers, I use SFTP with a server of ec2-xx-xxx-xx-xx.compute-1.amazonaws.com username of ec2-user
ec2-107-20-192-98.compute-1.amazonaws.com:22 represents both the hostname and the ssh port. (SSH is normally on port 22, though it can run on any port.)
Try just ec2-107-20-192-98.compute-1.amazonaws.com in the hostname field.
I'm still skeptical of a webpage asking for a username and password. Seems a bit silly to me, since you should just use SFTP to directly upload whatever content you want using your SSH identity key instead of a password.
You could simply use 127.0.0.1 as hostname and check FTP in Wordpress ftp settings.
To resume what has been said:
user is the same you actually use to SSH/SFTP
password needs to be set/updated logging in via SSH and typing
sudo passwd your-user-name