6

I have been getting this error

2013/03/13 13:25:07 [crit] 49299#0: *38 rename() "/var/tmp/nginx/fastcgi_temp/6/00/0000000006" to "/var/cache/nginx/microcache/8/fd/c36e398490d9b70e3c98ba094d065fd8" failed (13: Permission denied) while reading upstream

I tried other informations in Nginx and SO forums like changing the owner of folder/file, deleting the microcache folder for Nginx to create new by itself, but nothing seems to work.

My Nginx config has www as user(owner, in FreeBSD) all these folders /var/tmp/nginx/fastcgi_temp/ and /var/cache/nginx/microcache/ has www as user(owner) and wheel as group.

To test it I even gave -R 777 to those above mentioned folders and restart nginx, but error.log still says same error. Can't even think of what might possibly be wrong here, any guidance would be appreciated.

Improve this question
2
  • Great idea to willy-nilly set permissions across the board to 0777. Better install that machine from scratch now, it is probably mesed up beyond repair. Commented Mar 29, 2013 at 0:14
  • I know 0777 is not right thing, but 0777 was just for two folders under fastcgi_tmp and microcache to test, I changed it back to 766, if you read my answer below Commented Mar 29, 2013 at 1:15

6 Answers 6

Reset to default
3

I fixed this up with giving permission to its parent directories. /var/cache/nginx all had Read Only permissions, while /var/cache/nginx/microcache/ had All permissions, it worked only after I changed /var/ , /var/cache/ and /var/cache/nginx/ permission to 766. This is still weird but it works for me.

Improve this answer
2
  • 2
    May have been SELinux messing things up, that's what just happened to me. Commented Jun 1, 2016 at 20:58
  • @nmr, thanks! you should add an aswrer mentioning selinux and how to disable it. Commented Jun 1, 2018 at 18:04
1

I've had this error come up few times over last few days I've transitioned content from an old hardware server into AWS EC2 instance. To resolve, I've had to delete the /var/tmp/nginx/fastcgi_temp folder and restart nginx service. This recreates the fastcgi_temp folder and, at least for me, the problem went away after that.

Improve this answer
0

I just had this exact thing happen to me, running Amazon Linux and Nginx built from source. I fixed it by setting directory permissions as follows (you'll note I've edited the directory listing to make it more obvious which permissions you need on which directories). Note that 777 didn't work, you need 755 and these owners.

drwxr-xr-x 21 root root 4096 Dec 19 06:58 /var drwxr-xr-x 8 root root 4096 Dec 18 18:43 /var/cache drwxr-xr-x 7 nginx root 4096 Dec 18 18:45 /var/cache/nginx drwx------ 2 nginx root 4096 Dec 31 02:47 /var/cache/nginx/client_temp drwx------ 12 nginx root 4096 Dec 27 04:09 fastcgi_temp drwx------ 2 nginx root 4096 Dec 18 18:45 proxy_temp drwx------ 2 nginx root 4096 Dec 18 18:45 scgi_temp drwx------ 2 nginx root 4096 Dec 18 18:45 uwsgi_temp
Improve this answer
0

I had previously deleted the /var/cache/nginx/ folder to remove the nginx cache. Didn't cause any trouble until I rebooted. I simply went back in and created the folder again and my problem went away.

Improve this answer
0

I am facing the same issue, first check your nginx user and group from configuration file, my nginx user is nobody and the group is admin. then using this command to keep the group and user keep the same:

sudo chown -R nobody ./proxy_temp sudo chgrp -R admin ./proxy_temp

replace the path ./proxy_temp to your own path.

Improve this answer
-1

This is most likely you have two or more Nginx master process and their user permission is not the same.

Improve this answer

You must log in to answer this question.