46

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?

SangminKim
  • 8,358
  • 14
  • 69
  • 125
  • Does this answer your question? [Nginx: Permission denied for nginx on Ubuntu](https://stackoverflow.com/questions/18714902/nginx-permission-denied-for-nginx-on-ubuntu) – Michael Freidgeim Dec 15 '20 at 11:34

8 Answers8

19

You might need to fire it with sudo

sudo nginx -t
T.Todua
  • 53,146
  • 19
  • 236
  • 237
  • 1
    `nginx -t` caused the error and `sudo nginx -t` did not, but *why* would I need `sudo` if this command shows that the log file is owned by www-data? `ls -lah /var/log/nginx/error.log` (output: `-rw-r----- 1 www-data www-data ...`) – Ryan Nov 14 '19 at 18:55
  • From https://unix.stackexchange.com/a/184005/48973 I see that my group has no "write" access, but I'm still confused about what to do, especially since the other almost identical server I set up recently didn't ever seem to have this problem. – Ryan Nov 14 '19 at 19:03
17

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
RicLeal
  • 923
  • 9
  • 23
  • 6
    doesn't work for me neither. error is the same `nginx: [alert] could not open error log file: open() "/var/log/nginx/error.log" failed (2: No such file or directory)`. my env is a docker container with a non-root user – Daniel Alder May 01 '19 at 12:51
  • 3
    This is seems to be the correct answer. It's just a warning, nginx still starts and return an error code of 0. There doesn't seem to be a way to prevent this "alert". – Yves Dorfsman Dec 06 '19 at 20:02
12

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

Rickard Nilsson
  • 1,393
  • 11
  • 11
  • Thanks for confirmation that nginx just didn't bother about non-root scenario and they fixed in recently. If you just play with old nginx on test system and don't want to bother with building custom version: you can just replace path inside binary `bbe -e 's,/var/log/nginx/error.log,/tmp/log_nginx_error.log,' /usr/sbin/nginx > /usr/sbin/nginx.hacked` , then add -x permission and proceed using /usr/sbin/nginx.hacked for tests – noonex Apr 29 '21 at 08:45
  • Best answer, thx alot :) – shampoo Nov 02 '21 at 19:49
  • It might also help you to make an alias for this user that looks something like this in the `.bashrc` file (or equivalent) `alias nginx="nginx -p /path/to/local/nginx/folder/ -e error.log -c nginx.conf"` this way you can just run nginx normally and the arguments you need every tim never have to be written out. – joe pelletier May 11 '22 at 14:58
0

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.

maxiaotiao
  • 1
0

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
shyam yadav
  • 214
  • 1
  • 10
  • Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Apr 12 '22 at 09:53
-1

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
Ebe
  • 1
-2

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
cantelope
  • 1,147
  • 7
  • 9
  • 17
    I am asking why `Nginx` try to access another error log file not a permission problem. Even if there is a permission problem. I think the error show error on the file I set in configuration file(`/home/Foo/log/nginx`) not `/var/log/nginx/error.log`. – SangminKim Dec 14 '15 at 03:27
  • 6
    nginx is trying to open the default error log before it reads your directive to put the log elsewhere, and the user Foo doesn't have permission to access that location. That's why you're getting the first alert. Also it appears the directory /home/Foo/run/ isn't writable, or doesn't exist. Why not just use the default locations? What are you trying to do exactly? – cantelope Dec 14 '15 at 04:14
  • If you'd like a real answer, ... scroll on down! – A.B. Carroll Oct 13 '19 at 17:27
  • This is not correct, this does not prevent nginx to emit its "alert" when it is configured to use a non-privileged directory for error_log and is run as a non-root user. The alert has no impact, nginx still starts and return an error code 0, but it unfortunately also emit this alert. – Yves Dorfsman Dec 06 '19 at 20:07
-3

Alternatively reload nginx with sudo

sudo nginx -s reload

Constantin Harabara
  • 403
  • 3
  • 8