I’m trying to make WordPress work. I currently have this error message:
Could not create directory. /var/www/html/wp-content/upgrade/theme_name
when trying to upload a theme. This is the permissions set to /var/www/html/wp-content/upgrade/
drwxrwxr-x 3 ec2-user apache 4096 Jun 21 00:30 upgrade
chmod 777 upgrade makes the error go away. But that is not considered best practice. However, I think this should work too… why not?
I guess the web server may not be included by the above permissions. What group should I use to allow the web server to write?
(My setup is Amazon EC2, Amazon Linux AMI with httpd)
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
I don’t know anything about Amazon EC2, but you should be able to:
-
Retrieve the name of the user running Apache with a command similar to this:
ps aux | grep apache # The username should be in the first column.
-
Retrieve the groups this user is part of with the
groups(1)command:groups [USERNAME]
Method 2
You may try to use the following command-line method to find out your Apache group names:
WWW_GROUP=`ps axo user,group,comm | egrep '(apache|httpd)' | grep -v ^root | cut -d -f 2| uniq` echo Apache group is: $WWW_GROUP
To get the user, check: How to determine Apache user from the command-line?
Method 3
chmod 777 upgrade makes the error go away.
Well, in that case ls -ld /var/www/html/wp-content/upgrade/theme_name should reveal creator’s credentials, which you can use for precise access granting.
And it’s better using 1777 (as for /tmp) since at least it guarantees that only owner of a file would be able to unlink it.
Method 4
If you want a one liner for this to stuff in a test or subshell or something, this works well:
ps -ef | egrep '(httpd|apache2|apache)' | grep -v "$(whoami)" | grep -v root | head -n1 | awk '{print $1}' | groups | awk '{print $2}'
In the above, the last command selects the 2nd group, because the first is typically sys, which is not generally useful.
If you want a list of all groups that apache is in, drop the last pipe section awk '{print $2}, like so:
ps -ef | egrep '(httpd|apache2|apache)' | grep -v "$(whoami)" | grep -v root | head -n1 | awk '{print $1}' | groups
If you want the apache username, do the previous and also drop the groups pipe section, like this:
ps -ef | egrep '(httpd|apache2|apache)' | grep -v "$(whoami)" | grep -v root | head -n1 | awk '{print $1}'
I do not suggest making assumptions about the environment unless it is fully under your own control. If you need to programmatically determine the user and are not absolutely certain that it will always run in a specific environment (or are not certain that someone may have changed it to some custom name/group in their apache.conf), then it is practical to have some uniform method to check for it. You can stuff this in a .env file under some common key for localized program access, or alternately echo it into bash_profile or bashrc if you want a consistent variable to check systemwide, perhaps like this:
echo export "WEBSERVER_USERNAME=$(ps -ef | egrep '(httpd|apache2|apache)' | grep -v "$(whoami)" | grep -v root | head -n1 | awk '{print $1}')" >> ~/.bash_profile
echo export "WEBSERVER_USERGROUP=$(ps -ef | egrep '(httpd|apache2|apache)' | grep -v "$(whoami)" | grep -v root | head -n1 | awk '{print $1}' | groups | awk '{print $2}')" >> ~/.bash_profile
source ~/.bash_profile
Elsewhere: …
# chown a dir to the webserver universally
# for typical 755 directory permission
# Good for production environment web app folders
sudo chown "${WEBSERVER_USERNAME}:${WEBSERVER_USERGROUP}" /path/to/dir
# chown to your user and the webserver usergroup
# for shared 775 cli/http directory perms
# good for dev environment, localhost, or anywhere that
# you have to do a lot of cli file edits to web folders/files
sudo chown "$(whoami):${WEBSERVER_USERGROUP} /path/to/dir
or whatever else you need it for without having to look it up a million times
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0