The below is my nginx configuration file located in /etc/nginx/nginx.conf
user Foo;
worker_processes 1;
error_log /home/Foo/log/nginx/error.log;
pid /home/Foo/run/nginx.pid;
events {
worker_connections 1024;
use epoll;
}
http {
access_log /home/Foo/log/nginx/access.log;
server {
listen 80;
location = / {
proxy_pass http://192.168.0.16:9999;
}
}
}
As you can see I change log, pid files location into home directory.
When I re-start Linux it seems to work, Nginx records error logs in the file I set and pid file also.
However, when it tries nginx -s reload or the other, It tries to open other error log file.
nginx: [alert] could not open error log file: open() "/var/log/nginx/error.log" failed (13: Permission denied)
2015/12/14 11:23:54 [warn] 3356#0: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:1
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
2015/12/14 11:23:54 [emerg] 3356#0: open() "/home/Foo/run/nginx.pid" failed (13: Permission denied)
nginx: configuration file /etc/nginx/nginx.conf test failed
I know, I can solve permission error with sudo but the main issue in here is a error log file(/var/log/nginx/error.log) Nginx tries to open.
Why does it try to access another error log file?
This is old... but I went through the same pain and here is my solution.
As you can see the log is an alert, not a blocking error:
nginx: [alert] could not open error log file: open() "/var/log/nginx/error.log" failed (13: Permission denied)
It shouldn't be a problem :) Nginx just likes to check that file on startup...
Just use -p option. Something like this to launch Nginx locally works for me:
nginx -c /etc/nginx/nginx.conf -g 'daemon off;' -p /home/Foo/log/nginx
You might need to fire it with sudo
sudo nginx -t
The alert comes from the nginx initialization procedure, when it checks that it can write to the error log path that has been compiled in with the --error-log-path configure flag. This happens before nginx even looks at your configuration file, so it doesn't matter what you write in it.
Recently (2020-11-19), an -e option was added to nginx, allowing you to override the error log path that has been compiled in. You can use that option to point nginx to a user-writeable file (or maybe stderr).
See https://trac.nginx.org/nginx/changeset/f18db38a9826a9239feea43c95515bac4e343c59/nginx
Yes, Nginx just likes to check that file on startup. I copy the nginx installed directory to another place, I start it, and the pid of the new Nginx still in old place. So I suggest you to delete old directory.
You will get this alert because your user doesn't have permission to modify the log file. I just assign the permission to the Nginx log file and it worked as expected.
just use this command.
sudo chmod 766 /var/log/nginx/error.log
This simple answer is to use sudo.
So when I used sudo nginx -t
Everything turned out fine.
BTW, this had error precipitated for me when I was increasing the file upload limits in PHP.INI on Ubuntu 18.04, and I had restarted my PHP and my NGINX and thats when I tested:
2020/10/19 20:27:43 [warn] 1317#1317: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:1
2020/10/19 20:27:43 [emerg] 1317#1317: BIO_new_file("/etc/letsencrypt/live/websitename.com/fullchain.pem") failed (SSL: error:0200100D:system library:fopen:Permission denied:fopen('/etc/letsencrypt/live/websitename.com/fullchain.pem','r') error:2006D002:BIO routines:BIO_new_file:system lib)
nginx: configuration file /etc/nginx/nginx.conf test failed
Check the permissions on the directory /home/Foo/log/nginx/. It must be writable by nginx. Set permissions like so:
sudo chmod 766 /home/Foo/log/nginx
Alternatively reload nginx with sudo
sudo nginx -s reload
Related
trying to setup nginx to serve anarchistparty.org synapse homeserver reverse proxy. Nginx.conf is currently standard install, hasn’t been edited.
Sudo nginx -t gives:
nginx: [emerg] open() "/etc/nginx/sites-enabled/anarchistparty.org"
failed (2: No such file or directory) in /etc/nginx/nginx.conf:62
nginx: configuration file /etc/nginx/nginx.conf test failed
anarchistparty.org is present in sites-available and symlinked
source
Perhaps you created the symbolic link using relative paths instead of absolute paths, like the author of the source article (and I) did. In this case, the solution is to use absolute paths:
sudo ln -s /etc/nginx/sites-available/anarchistparty.org /etc/nginx/sites-enabled/
I have basic nginx set up on my Digital Ocean droplet (Ubuntu). I have only one root user. In my nginx configuration file in location I have
server {
listen 80;
server_name site.com;
root /var/www/html/site;
}
I tried to change it to
root /root/site
But it gives me 403 Forbidden error. When I change it to nginx default directory
/var/www/html/site;
everything works fine.
Why is it giving me that error? I understand that only root user has access to root directory, but why can't browser only read files from there? Is it okay to create another folder, not like "/var/www/html/23rdsquad;" somewhere on my server (not /root or /var/www) and use that instead?
Your Nginx user does't have permission to read directory /root/site, so:
Check directory permission
user#user:~$ ls -l /root/site | grep site
drwxrwxrwx 7 user user 4096 ago 17 16:56 site
Check Nginx user
user#user:~$ ps aux|grep nginx|grep -v grep
Nginx user configuration is "/etc/nginx/nginx.conf"
vim /etc/nginx/nginx.conf
Usually you have
"user www-data;"
1) Change directory permission either Nginx user.
2) Restart Nginx service
user#user:~$ sudo systemctl restart nginx
I am trying out simple changes in nginx.conf file. I tried changing the location of error log from /var/log/nginx/error.log to /path/to/directory/error.log. But when I try restarting the nginx service, the service fails to startup and when I check its status, following log shows up.
nginx: [emerg] open() "/path/to/directory/error.log" failed (13: Permission denied)
I tried changing ownership of the directory but still it fails. Any help would be highly appreciated.
Thank you
Your path directory is not owned by NGINX user which is www-data so you need to run
chown -R www-data:www-data /path/to/log/file
I want Install a Script, company Owner of this script told in my NGINX
disable_symlinks if_not_owner from=$document_root;
is enabled,
How i should Disable it? cause i opened /etc/nginx/nginx.conf and i not Found it,
In which file i can found it?
varnishlog is returning:
_.vsm: No such file or directory
Has anyone else seen this before?
It looks like varnishlog is not pointing to the correct directory, or has not access to it.
Please check the command line options of varnishd. If the deamon run with -n <instancename> argument, you have to add it to varnishlog as well.
The second thing, is to see the permissions of varnish directory.
In order to see the current directory used, you must log into root and run the command below :
$ lsof -p <PID of varnishd> | grep vsm
Once revealed, you just had to be sure the full path has read permission for your user.
In Varnish 4.1 the root cause can be due to incorrect rights for reading _.vsm file. For example:
# service varnishncsa start
* Starting HTTP accelerator log deamon [fail]
Can't open log - retrying for 5 seconds
Can't open VSM file (Cannot open /var/lib/varnish/dev-me/_.vsm: Permission denied
Varnishncsa works from varnishlog user. But /var/lib/varnish/dev-me/_.vsm can be readable from varnish group or root user only:
# ls -l /var/lib/varnish/dev-me/_.vsm
-rw-r----- 1 root varnish 84934656 Apr 15 05:58 /var/lib/varnish/dev-me/_.vsm
So you can fix this problem in the following way:
# usermod -a -G varnish varnishlog
# id varnishlog
uid=110(varnishlog) gid=116(varnishlog) groups=116(varnishlog),115(varnish)
And now you can start varnishncsa.
In our case the hostname of the server was changed.
If you do not specify an instance name, varnish uses the hostname. It was looking for a directory holding the shared memory logging configuration with the new hostname, but the instance was still running from the directory with the old hostname.
Restarting varnish solved the problem.
I just had the same error message while trying to issue varnishadm commands. Turned out that I renamed my machine without stopping varnish. There was some directory in /var/varnish/ corresponding to the machine name that varnish needed access to. "sudo service varnish restart" fixed this for me.