ScaleScaleScaleScale

Tips / Nginx


13: Permission denied while reading upstream using Nginx

Today I was investigating an issue in one of my customer servers and found a permission denied error on the logs:

[crit] 26728#0: *547 open() "/var/lib/nginx/tmp/proxy/2/00/002" failed
(13: Permission denied) while reading upstream, client: 79.xx.xx.xxx, 
server: my.server.com, request: "GET /upload_photo.php HTTP/1.1", 
upstream: "http://127.0.0.1:81/upload_photo.php", host: "my.server.com", 
referrer: "http://my.website.com/index.php"

What was the problem?

My customer wasn’t able to load an entire webpage of this website, it was loading but partially.

First, check out your Nginx error logs, in my case this is what I did:

tail -f /var/log/nginx/error_log

Then I saw the (13: Permission denied) while reading upstream error, and noticed that /var/lib/nginx/tmp/proxy/2/00/0002 was having wrong permissions, along with all it’s parent folders. So, as this was a simple tmp proxy directory, I got rid of them and set the proper owner for the parent directories:

How did I fix the permission denied error?

Open the /etc/nginx/nginx.conf to find worker user of nginx, now that you know the user (it should be apache, nobody or nginx), this is what I did in my case:

chown apache.nginx /var/lib/nginx/tmp/proxy -v
rm /var/lib/nginx/tmp/proxy/* -R
chmod 777 /var/lib/nginx/tmp -v

Restarted nginx and apache just in case, and all solved 😀

Popular search terms:

  • nginx pm2 13: Permission denied
  • permission denied /var/lib/nginx/ nginx client_temp
  • [crit] 5658#0: *1 connect() to 127 0 0 1:8081 failed (13: Permission denied) while connecting to upstream
  • 13 permission denied nginx
profile

Esteban Borges

Linux Geek, Webperf Addict, Nginx Fan. CTO @Infranetworking

  • Mr. Security

    …and now your customers setup is vulnerable, because /var/lib/nginx/tmp is world-writable.
    Do not chmod 777!

  • admin

    Hey, you are right on that. If you have a way to get it working without using chmod 777, please share it with us!

  • Ron

    You’re going to want to set the directory and all subdirectories to be owned by the same user that nginx runs as. In my case:

    chown -R nobody.nobody /var/lib/nginx

  • Hello ;

    # chown -R www-data.www-data /var/lib/nginx
    # chmod 0750 -R www-data.www-data /var/lib/nginx

    Note: User can be different (depending of the nginx source (debian package, nginx package,compilation from sources…)

    Should do the job 😉

  • chmod was not necessary for me. My folder is set to 700.
    chown was all I needed
    Reference: http://serverfault.com/a/823292/215790

  • Justin R Hill

    DO NOT chmod 777

    DO NOT DO IT

    YOU WILL HAVE A BAD TIME IN THE FUTURE AND HATE YOUR PAST SELF

    chmod 744 or chmod 774 is more reasonable. Even chmod 755 or chmod 775 is more reasonable, but anything ending in 2, 3, 6, or 7, that means anyone – any process! – on your computer has zero barrier to edit or even delete your file. It’s not even a security thing, it’s something you can do by mistake, it’s a ticking time bomb.

    • Олег Деник

      correct decision:
      > chown -R apache:apache /var/lib/nginx
      (if your nginx server runs owned by apache user)

      or (if runs by nginx user):
      > chown -R nginx:nginx /var/lib/nginx

      see your configuration files before 😉