I noticed when I test my nginx config using nginx -t, it gives me a warning:
nginx: [alert] could not open error log file: open() "/var/logs/nginx/error.log" failed (2: No such file or directory)
Which makes sense, since the log path for nginx is actually set up to be /var/log/nginx/ not /var/logs/nginx.
I scanned the entire nginx config directory and there is nothing there referencing /var/logs. I'm at a loss as to where this log location could be written?
Run this command in a terminal (note: capital V):
nginx -V
Do you find /var/logs there? Your nginx might be compiled with that default file location.
[EDIT]
I guess that some of your server blocks don't have the "error_log" directive. So nginx tries the default one for them. Note that by default the error_log is always on.
To fix this issue, you can add this line on the main block (the top level) such that all child blocks can inherit the setting:
error_log /var/log/nginx/error.log;
You can create these missed files:
cd /var/log/nginx/
sudo touch error.log
sudo touch access.log
sudo chmod 750 *.log
Then trigger nginx service:
sudo systemctl daemon-relod
sudo service nginx restart
[NOTE]:
You can also disable nginx logging:
disable nginx logging (1)
disable nginx logging (2)
You have a bad compiled default. Anything nginx notices before loading the config goes to the path for the error log defined at compile time. Recompile nginx with sane path or symlink log to logs if you can't.
Related
while installing letsencrypt certificate the output error is:
nginx: the configuration file /jet/etc/nginx/nginx.conf syntax is ok
nginx: [emerg] getgrnam(“nobody”) failed
nginx: configuration file /jet/etc/nginx/nginx.conf test failed
but if I run:
nginx -t
to see if there are configuration errors in the nginx.conf file,
nginx -t return the output:
nginx: the configuration file /jet/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /jet/etc/nginx/nginx.conf test is successful
Every now and then on WordPress I also get the error:
internal server 500 error
and I don’t know if this is related to the problem I described above
My web server is (include version):
The operating system my web server runs on is (include version):
Linux lemp7-optimized-g2-1-vm 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21) x86_64
jeware lemp7 stack profile
jetware
I managed to install the certificates by inserting a line with the “user nobody nogroup;” in the nginx.conf file
After the installation I removed the line with the “user nobody nogroup;” in the nginx.conf file
sudo wget https://dl.eff.org/certbot-auto
sudo mv certbot-auto /jet/etc/letsencrypt/certbot-auto
sudo chown root /jet/etc/letsencrypt/certbot-auto
sudo chmod 0755 /jet/etc/letsencrypt/certbot-auto
sudo chmod a+x /jet/etc/letsencrypt/certbot-auto
sudo /jet/etc/letsencrypt/certbot-auto --nginx --nginx-ctl /jet/bin/nginx --nginx-server-root /jet/etc/nginx --config-dir /jet/etc/letsencrypt
this produce this output:
nginx: the configuration file /jet/etc/nginx/nginx.conf syntax is ok
nginx: [emerg] getgrnam(“nobody”) failed
nginx: configuration file /jet/etc/nginx/nginx.conf test failed
but if I run:
nginx -t
to see if there are configuration errors in the nginx.conf file,
nginx -t return the output:
nginx: the configuration file /jet/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /jet/etc/nginx/nginx.conf test is successful
every now and then on WordPress I also get the error: internal server 500 error
and I don’t know if this is related to the problem I described above
I will probably also have problems with automatic certificate renewal if I do not resolve this situation
Well I have solved the problem. Fortunately I managed to find the error in the log and I understood what happened.
“certbot-auto” installs the certificates using the user: nobody. In my system there already existed by default a user “nobody” of the group “nogroup” but has no access to nginx. user nobody
So to be able to install the certificates I had to insert a line with the directive: user nobody nogroup; inside nginx.conf.
This allowed the installation of certificates. However, this procedure has changed the permissions in the directory: /jet/tmp/nginx/
where instead of: my_ssh_user:my_ssh_group I found: nobody:my_ssh_group and with this modified setting I received the internal server 500 error on the WordPress admin panel. So the problem is not related to WordPress but to the certificate installation procedure.
After installing the certificates I removed the user nobody nogroup directive; because during the restart of nginx, a warning came up saying that this directive is not supported and therefore will be ignored.
Restoring the permissions with chmod on the directory: /jet/tmp/nginx I fixed the problem and the internal server 500 error disappeared.
Here the link of the same discussion on letsencrypt. I still doubt that the error could recur when I have to renew the certificates.
A possible solution could be to assign the ssh user of the virtual instance that does not have root permissions, root permissions by adding it to the root group.
On virtual hosts, when an instance is launched, a user ssh is created.
This user, for security reasons, does not have root permissions.
Letsencrypt by default installs the certificates on the / etc / letsencrypt folder, which has root permissions (user: root group: root).
I had to install the certificates in the folder where the ssh user can have access (user: myssh_user group: myssh_group), ie su / jet / etc / letsencrypt
Could it be that the error was caused by this?
I have an Nginx service that's configured to start automatically on my Windows 10; however, this morning, the service wouldn't start.
The error log says: nginx: [alert] could not open error log file: CreateFile() "C:\someForlderName\build\distribution\.\nginx/logs/error.log" failed (3: The system cannot find the path specified)
Looking at the path in the error log above, I do NOT have the /logs/ folder on my local system so it looks like Nginx doesn't have the proper permissions to create that folder?
I'm setup as an admin user and my service is set to Log On As - Local System Account
This only happens on Windows 10; but the service starts and works on
older Windows i.e 8.1
So does anyone know how to grant administrator's permissions to Nginx so that Nginx can create folders and files on Windows 10 ?
You need:
To install nginx/Windows, download the latest mainline version distribution (1.13.8), since the mainline branch of nginx contains all known fixes. Then unpack the distribution, go to the nginx-1.13.8 directory, and run nginx. Here is an example for the drive C: root directory: (Run cmd as administrator)
cd c:\
unzip nginx-1.13.8.zip
cd nginx-1.13.8
start nginx
Go to: http://localhost:80 -> test install
Goback to console cmd: "nginx -s stop"
Run for next time:
Config with file: "C:\nginx-1.13.8\conf\nginx.conf"
Open cmd as administrator
Run bash: "cd C:\nginx-1.13.8"
Run nginx with bash: "start nginx" . If you run with bash: "nginx", will get trouble for exit nginx.
And
nginx -s stop #fast shutdown
nginx -s quit #graceful shutdown
nginx -s reload #changing configuration, starting new worker processes with a new configuration, graceful shutdown of old worker processes
nginx -s reopen #re-opening log files
Under the directory that you run nginx.exe, try to create a directory named logs, and a file named error.log under log.
It should pass this error.
After downloading zip file, you have unzip.
Make sure that you dont have nested folder names. You have to copy your folder which has nginx.exe file in it, and paste it into C:/ folder.
While running commands, like nginx -s stop, make sure that current your working directory is same as the nginx.exe file.
enter image description here
Nginx start on default port 80, not 8080. Try localhost:80 on browser.
If you want to change port, open C:\nginx-1.16.1\conf\nginx.conf with text editor.
change port number what you want use default port.
server {
listen 80;
server_name localhost;
to:
server {
listen 8080;
server_name localhost;
I had a similar issue with starting the nginx server, but after looking at it closely and trying to run the command in different consoles, I realized it just a simple issue of a missing path.
How I solved it was to cd into the containing folder for the nginx.exe file (which actually contains error logs and all the necessary files) and then run the nginx command which started the server and fixed it for me.
So I was trying some settings of the Nginx PageSpeed module, but there was two settings that I couldn't set for some reason.
pagespeed NumRewriteThreads 2;
pagespeed NumExpensiveRewriteThreads 2;
For some reason these two settings always throw error when I try to restart or test my nginx config.
sudo service nginx restart
[FAIL] Restarting nginx: nginx failed!
When I test the file I get this:
"pagespeed" directive "NumRewriteThreads" not recognized or too many arguments in /etc/nginx/nginx.conf:40
nginx: configuration file /etc/nginx/nginx.conf test failed
My Nginx version is the following:
sudo /usr/sbin/nginx -v
nginx version: nginx/1.6.0
The settings appear in the PageSpeed docs as well, so I'm wondering if there's something I am missing to make them work.
https://developers.google.com/speed/pagespeed/module/system#tune_thread
I've entered a bug for this: ngx_pagespeed #728. I think it's just an oversight.
I am getting this error in my nginx-error.log file:
2014/02/17 03:42:20 [crit] 5455#0: *1 connect() to unix:/tmp/uwsgi.sock failed (13: Permission denied) while connecting to upstream, client: xx.xx.x.xxx, server: localhost, request: "GET /users HTTP/1.1", upstream: "uwsgi://unix:/tmp/uwsgi.sock:", host: "EC2.amazonaws.com"
The browser also shows a 502 Bad Gateway Error. The output of a curl is the same, Bad Gateway html
I've tried to fix it by changing permissions for /tmp/uwsgi.sock to 777. That didn't work. I also added myself to the www-data group (a couple questions that looked similar suggested that). Also, no dice.
Here is my nginx.conf file:
nginx.conf
worker_processes 1;
worker_rlimit_nofile 8192;
events {
worker_connections 3000;
}
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
#gzip on;
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
I am running a Flask application with Nginsx and Uwsgi, just to be thorough in my explanation. If anyone has any ideas, I would really appreciate them.
EDIT
I have been asked to provide my uwsgi config file. So, I never personally wrote my nginx or my uwsgi file. I followed the guide here which sets everything up using ansible-playbook. The nginx.conf file was generated automatically, but there was nothing in /etc/uwsgi except a README file in both apps-enabled and apps-available folders. Do I need to create my own config file for uwsgi? I was under the impression that ansible took care of all of those things.
I believe that ansible-playbook figured out my uwsgi configuration since when I run this command
uwsgi -s /tmp/uwsgi.sock -w my_app:app
it starts up and outputs this:
*** Starting uWSGI 2.0.1 (64bit) on [Mon Feb 17 20:03:08 2014] ***
compiled with version: 4.7.3 on 10 February 2014 18:26:16
os: Linux-3.11.0-15-generic #25-Ubuntu SMP Thu Jan 30 17:22:01 UTC 2014
nodename: ip-10-9-xxx-xxx
machine: x86_64
clock source: unix
detected number of CPU cores: 1
current working directory: /home/username/Project
detected binary path: /usr/local/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
*** WARNING: you are running uWSGI without its master process manager ***
your processes number limit is 4548
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 bound to UNIX address /tmp/uwsgi.sock fd 3
Python version: 2.7.5+ (default, Sep 19 2013, 13:52:09) [GCC 4.8.1]
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0x1f60260
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 72760 bytes (71 KB) for 1 cores
*** Operational MODE: single process ***
WSGI app 0 (mountpoint='') ready in 3 seconds on interpreter 0x1f60260 pid: 26790 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI worker 1 (and the only) (pid: 26790, cores: 1)
The permission issue occurs because uwsgi resets the ownership and permissions of /tmp/uwsgi.sock to 755 and the user running uwsgi every time uwsgi starts.
The correct way to solve the problem is to make uwsgi change the ownership and/or permission of /tmp/uwsgi.sock such that nginx can write to this socket. Therefore, there are three possible solutions.
Run uwsgi as the www-data user so that this user owns the socket file created by it.
uwsgi -s /tmp/uwsgi.sock -w my_app:app --uid www-data --gid www-data
Change the ownership of the socket file so that www-data owns it.
uwsgi -s /tmp/uwsgi.sock -w my_app:app --chown-socket=www-data:www-data
Change the permissions of the socket file, so that www-data can write to it.
uwsgi -s /tmp/uwsgi.sock -w my_app:app --chmod-socket=666
I prefer the first approach because it does not leave uwsgi running as root.
The first two commands need to be run as root user. The third command does not need to be run as root user.
The first command leaves uwsgi running as www-data user. The second and third commands leave uwsgi running as the actual user that ran the command.
The first and second command allow only www-data user to write to the socket. The third command allows any user to write to the socket.
I prefer the first approach because it does not leave uwsgi running as root user and it does not make the socket file world-writeable .
While the accepted solution is true there might also SELinux be blocking the access. If you did set the permissions correctly and still get permission denied messages try:
sudo setenforce Permissive
If it works then SELinux was at fault - or rather was working as expected! To add the permissions needed to nginx do:
# to see what permissions are needed.
sudo grep nginx /var/log/audit/audit.log | audit2allow
# to create a nginx.pp policy file
sudo grep nginx /var/log/audit/audit.log | audit2allow -M nginx
# to apply the new policy
sudo semodule -i nginx.pp
After that reset the SELinux Policy to Enforcing with:
sudo setenforce Enforcing
Anyone who lands here from the Googles and is trying to run Flask on AWS using the default Ubuntu image after installing nginx and still can't figure out what the problem is:
Nginx runs as user "www-data" by default, but the most common Flask WSGI tutorial from Digital Ocean has you use the logged in user for the systemd service file. Change the user that nginx is running as from "www-data" (which is the default) to "ubuntu" in /etc/nginx/nginx.conf if your Flask/wsgi user is "ubuntu" and everything will start working. You can do this with one line in a script:
sudo sed -i 's/user www-data;/user ubuntu;/' /etc/nginx/nginx.conf
Trying to make Flask and uwsgi run as www-data did not work off the bat, but making nginx run as ubuntu worked just fine since all I'm running with this instance is Flask anyhow.
You have to set these permissions (chmod/chown) in uWSGI configuration.
It is the chmod-socket and the chown-socket.
http://uwsgi-docs.readthedocs.org/en/latest/Options.html#chmod-socket
http://uwsgi-docs.readthedocs.org/en/latest/Options.html#chown-socket
Nginx connect to .sock failed (13:Permission denied) - 502 bad gateway
change the name of the user on the first line in /etc/nginx/nginx.conf file.
the default user is www-data and change it to root or your username
I know it's too late, but it might helps to other. I'll suggest to follow Running flask with virtualenv, uwsgi, and nginx very simple and sweet documentation.
Must activate your environment if you run your project in virtualenv.
here is the yolo.py
from config import application
if __name__ == "__main__":
application.run(host='127.0.0.1')
And create uwsgi.sock file in /tmp/ directory and leave it blank.
As #susanpal answer said "The permission issue occurs because uwsgi resets the ownership and permissions of /tmp/uwsgi.sock to 755 and the user running uwsgi every time uwsgi starts." it is correct.
So you have to give permission to sock file whenever uwsgi starts.
so now follow the below command
uwsgi -s /tmp/uwsgi.sock -w yolo:application -H /var/www/yolo/env --chmod-socket=666
A little different command from #susanpal.
And for persist connection, simply add "&" end of command
uwsgi -s /tmp/uwsgi.sock -w yolo:app -H /var/www/yolo/env --chmod-socket=666 &
In my case changing some php permission do the trick
sudo chown user:group -R /run/php
I hope this helps someone.
You should post both nginx and uwsgi configuration file for your application (the ones in /etc/nginx/sites-enabled/ and /etc/uwsgi/ - or wherever you put them).
Typically check that you have a line similar to the following one in your nginx app configuration:
uwsgi_pass unix:///tmp/uwsgi.sock;
and the same socket name in your uwsgi config file:
socket=/tmp/uwsgi.sock
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.