I have a server set with NGINX: https://www.nginx.com/resources/wiki/start/topics/recipes/wordpress/
Recipe
Abridged basic setup
I have deployed WP in this directory: /var/www/blog.example.com/
/var/www and /var/www/blog.example.com/ does have nginx:nginx file/dir perms.
wp-config.php - 644
wp-content - 755
wp-content/plugins - 755
NGINX is running as nginx user.
I can browse in entire WordPress site including admin. However, when I want to install a new plugin or update I got always the message:
Installing plugin: iThemes Security (before Better WP Security) 7.9.1
Downloading the installation package from
https://downloads.wordpress.org/plugin/better-wp-security.7.9.1.zip…
Decompressing…
An error occurred while installing iThemes Security: Directory could not be created
What's I am wrong?
All libraries required according to https://make.wordpress.org/hosting/handbook/handbook/server-environment/ was installed.
When I try to upgrade a theme, for example, I got 200 code "OK" from a web server, but, I don't see anything in the error_log of NGINX.
Also, I've checked the php-fpm but I don't see any updating error.
php-fpm was running as an apache user.
I've switched the user into Nginx and It's solved. :D
It looks that the issue is the 'plugins' folder writing permissions. WP downloads the zip archive of the plugin then it decompresses it to the 'plugins' folder.
This article will help:
https://secure.wphackedhelp.com/blog/fix-file-and-folder-permissions-error-wordpress/
Just adding onto #sincorchetes answer, to those who need more specific instruction:
vim /etc/php-fpm.d/www.conf
I changed the lines
user = apache
group = apache
to
user = nginx
group = nginx
Then restarted the php-fpm and nginx service
systemctl restart php-fpm
systemctl restart nginx
I am new to nginx and trying to serve static contents with nginx and getting 403 error.I have server config like this:
server {
listen 8000;
server_name localhost;
root /Users/ismayilmalik/Documents/github/nginx-express;
location / {
index index.html;
}
I have executed commands below:
chmod -R 755 /nginx-express
chmod -R 644 /nginx-express/*.*
And the folder has drwxr-xr-x rigt.What's wrong here?
Please go to your nginx error logs to get details.
Run this command to show last errors:
tail -20 /var/log/nginx/error.log
It's good to go through error logs located /var/log/nginx/***.error. I had problems similar to this once. The solution was the user nginx was running as.
If nginx is running as www then www will not have access to ismayilmalik folders unless you also grant access to /Users/ismayilmalik home folder, but that is not secure. The best solution would be to allow nginx to run as ismayilmalik if you want to access your home folder through nginx.
I solved it finally.Actually nginx had all permission to serve static content from:
/Users/ismayilmalik/Documents/github/nginx-express;
The reason was when started nginx could not create error.log file in it'sroot directory. After manually creating the file it worked fine. I am using macOs and to find logs folder executed the command below to find all enironment variables for nginx:
nginx -V
BTW before this I had changed nginx user to from nobody to admin in main config file like below.
user [username] [usergroup]
By default nginx master process runs under root and child process under nobody.
I have 2 servers
Server A and Server B
Server A compress image, and put into Server B(Running Nginx)
The file put into Server B is through SSHFS(mounted) in a folder, when I go to Server B , I see the permission of the file is "root:root"
When I try to read it via web, it give a 403 forbidden.
So I did chown -R nginx:nginx on the folder itself. However new file, are still generated as "root:root"
Server A run Apache2 , while Server B run Nginx.
How do I make sure that my file in Server B is readable by Nginx, I cannot keep on go in and do the ownership change.
Is there a way I can change my nginx.conf to be able read the "root" file in this folder at /disk1/img
OR what else can I do to resolve this.
Thanks!
I believe you're wanting to set the User and Group for SSHFS to www-data:www-data so that nginx owns it after the transfer.
Try this:
https://serverfault.com/questions/389161/how-to-set-up-sshfs-to-use-www-data
I had nginx 1.6.0 on Debian 7 (wheezy), and now I want to install nginx on Debian 8 (Jessie). The version of this new nginx is 1.6.2. I copied the old version of the configuration file nginx.conf to the new server, but when I try to start the service, It fails:
service nginx restart
output:
nginx nginx[10743]: nginx: [emerg] getpwnam("nginx") failed in /etc/nginx/nginx.conf:1
I know my problem is the first line in nginx.conf:
user nginx;
And I know too, if I changed this line to user www-data, the problem will disappear, but why is that so? I have also used nginx as a load balancer not as a webserver.
$ man getpwnam
The getpwnam() function returns a pointer to a structure containing the
broken-out fields of the record in the password database (e.g., the
local password file /etc/passwd, NIS, and LDAP) that matches the user‐
name name.
The user nginx does not exist. You can create it or you can just use www-data as the user.
I have nginx installed with PHP-FPM on a CentOS 5 box, but am struggling to get it to serve any of my files - whether PHP or not.
Nginx is running as www-data:www-data, and the default "Welcome to nginx on EPEL" site (owned by root:root with 644 permissions) loads fine.
The nginx configuration file has an include directive for /etc/nginx/sites-enabled/*.conf, and I have a configuration file example.com.conf, thus:
server {
listen 80;
Virtual Host Name
server_name www.example.com example.com;
location / {
root /home/demo/sites/example.com/public_html;
index index.php index.htm index.html;
}
location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param PATH_INFO $fastcgi_script_name;
fastcgi_param SCRIPT_FILENAME /home/demo/sites/example.com/public_html$fastcgi_script_name;
include fastcgi_params;
}
}
Despite public_html being owned by www-data:www-data with 2777 file permissions, this site fails to serve any content -
[error] 4167#0: *4 open() "/home/demo/sites/example.com/public_html/index.html" failed (13: Permission denied), client: XX.XXX.XXX.XX, server: www.example.com, request: "GET /index.html HTTP/1.1", host: "www.example.com"
I've found numerous other posts with users getting 403s from nginx, but most that I have seen involve either more complex setups with Ruby/Passenger (which in the past I've actually succeeded with) or are only receiving errors when the upstream PHP-FPM is involved, so they seem to be of little help.
Have I done something silly here?
One permission requirement that is often overlooked is a user needs x permissions in every parent directory of a file to access that file. Check the permissions on /, /home, /home/demo, etc. for www-data x access. My guess is that /home is probably 770 and www-data can't chdir through it to get to any subdir. If it is, try chmod o+x /home (or whatever dir is denying the request).
EDIT: To easily display all the permissions on a path, you can use namei -om /path/to/check
If you still see permission denied after verifying the permissions of the parent folders, it may be SELinux restricting access.
To check if SELinux is running:
# getenforce
To disable SELinux until next reboot:
# setenforce Permissive
Restart Nginx and see if the problem persists. To allow nginx to serve your www directory (make sure you turn SELinux back on before testing this. i.e, setenforce Enforcing)
# chcon -Rt httpd_sys_content_t /path/to/www
See my answer here for more details
I solved this problem by adding user settings.
in nginx.conf
worker_processes 4;
user username;
change the 'username' with linux user name.
I've got this error and I finally solved it with the command below.
restorecon -r /var/www/html
The issue is caused when you mv something from one place to another. It preserves the selinux context of the original when you move it, so if you untar something in /home or /tmp it gets given an selinux context that matches its location. Now you mv that to /var/www/html and it takes the context saying it belongs in /tmp or /home with it and httpd is not allowed by policy to access those files.
If you cp the files instead of mv them, the selinux context gets assigned according to the location you're copying to, not where it's coming from. Running restorecon puts the context back to its default and fixes it too.
I've tried different cases and only when owner was set to nginx (chown -R nginx:nginx "/var/www/myfolder") - it started to work as expected.
If you're using SELinux, just type:
sudo chcon -v -R --type=httpd_sys_content_t /path/to/www/
This will fix permission issue.
Old question, but I had the same issue. I tried every answer above, nothing worked. What fixed it for me though was removing the domain, and adding it again. I'm using Plesk, and I installed Nginx AFTER the domain was already there.
Did a local backup to /var/www/backups first though. So I could easily copy back the files.
Strange problem....
We had the same issue, using Plesk Onyx 17. Instead of messing up with rights etc., solution was to add nginx user into psacln group, in which all the other domain owners (users) were:
usermod -aG psacln nginx
Now nginx has rights to access .htaccess or any other file necessary to properly show the content.
On the other hand, also make sure that Apache is in psaserv group, to serve static content:
usermod -aG psaserv apache
And don't forget to restart both Apache and Nginx in Plesk after! (and reload pages with Ctrl-F5)
I was facing the same issue but above solutions did not help.
So, after lot of struggle I found out that sestatus was set to enforce which blocks all the ports and by setting it to permissive all the issues were resolved.
sudo setenforce 0
Hope this helps someone like me.
I dug myself into a slight variant on this problem by mistakenly running the setfacl command. I ran:
sudo setfacl -m user:nginx:r /home/foo/bar
I abandoned this route in favor of adding nginx to the foo group, but that custom ACL was foiling nginx's attempts to access the file. I cleared it by running:
sudo setfacl -b /home/foo/bar
And then nginx was able to access the files.
If you are using PHP, make sure the index NGINX directive in the server block contains a index.php:
index index.php index.html;
For more info checkout the index directive in the official documentation.