Comments for Nicholas Orr

Comment on nginx (engine X) - What a Pain in the BUM! [13: Permission denied] by Lance Fordham

Lance Fordham — Thu, 05 Jan 2012 04:09:22 +0000

I think my scenario is the same as yours.

I am running nginx under user “nginx”, and this user is in the group “nginx”.

I am running PHP as a Fastcgi process and php is running as user “website”, and this user is in the group “website”.

The website files are located in the directory “/home/website” and the “website” user is the owner of this directory.

I could execute any PHP file from any subdirectory, but I could not execute/read/write any other file from any other subdirectory other than the /home/website directory because nginx did not have access to those directories and files.

My solution is to set permissions of the subdirectories that I wish to give nginx access to, to 0711 and set the permissions to all of the files in the subdirectories to 0755. It works perfectly!

Comment on nginx (engine X) - What a Pain in the BUM! [13: Permission denied] by Saju Sukumar

Saju Sukumar — Sun, 27 Nov 2011 14:33:33 +0000

Yeah ..that worked...I was breaking my head to solve this issue...just changing the user in conf worked.... (normally its a comment with nobody as username)

as

user user_name;

Comment on nginx (engine X) - What a Pain in the BUM! [13: Permission denied] by Wguerrero42

Wguerrero42 — Tue, 11 Oct 2011 20:27:04 +0000

I am having the same issue, but this info is helpful thanks.

Comment on nginx (engine X) - What a Pain in the BUM! [13: Permission denied] by bn1

bn1 — Fri, 29 Apr 2011 05:30:23 +0000

or you just have to check if you're accessing the right path :D (thanks nginx log) ..I thought, what a jerk I am, but I was really accessing wrong path due missing “rewrite” rule, easing the “/static/” path (it was accessing “/var/www/static/some.site/static/” rather than correct one “/var/www/static/some.site/”)

Comment on nginx (engine X) - What a Pain in the BUM! [13: Permission denied] by Tower Joo

Tower Joo — Fri, 18 Feb 2011 08:32:44 +0000

Make sure the path tree to be readable by nginx, which will fix the permission issue.

Comment on nginx (engine X) - What a Pain in the BUM! [13: Permission denied] by razvan dimescu

razvan dimescu — Tue, 08 Feb 2011 12:03:50 +0000

yup, had the same problem. I solved it by changing the user that nginx was runing to the user that created the files from home. You need access starting with root “/”

Comment on Updated Scanty on CouchDB to Work w/ 0.9.0a by cigar reviews

cigar reviews — Fri, 28 Jan 2011 14:42:11 +0000

NICHOLAS Orr will follow in the path of cycling's elite when he pedals 62km from Balhannah to Strathalbyn in the Mutual Community Challenge Tour. …

Comment on nginx (engine X) - What a Pain in the BUM! [13: Permission denied] by Gabriel Koen

Gabriel Koen — Tue, 25 Jan 2011 04:15:18 +0000

Thanks, you saved me from smashing my head against the desk.

Comment on nginx (engine X) - What a Pain in the BUM! [13: Permission denied] by miko

miko — Fri, 14 Jan 2011 22:55:30 +0000

I know this is old, but I agree with Kyle, although based upon my tests the parent directories need only have the world-executable flag set (i.e. 701 would work). They don't need to be owned by nginx user.

So if I'm serving files in /var/foo/bar/baz/public, all the parent directories need to have the world-executable flag set or else you'll get permission denied errors.

Then the files in /var/foo/bar/baz/public need to be world readable (assuming the group owner is not in nginx's group, and nginx is also not the owner of the files in /public). So make them world-readable and nginx will kindly serve them to the public.

I was just playing around with a static file testing this, so before you go applying to all your sites, you probably want to test more thoroughly, but hopefully this helps out others in the future who run into this error.

Comment on nginx (engine X) - What a Pain in the BUM! [13: Permission denied] by Kyle

Kyle — Thu, 26 Aug 2010 08:46:59 +0000

The problem is that nginx requires the whole tree to be readable and not just where your root starts in nginx.conf. So “chmod -R 777 /var” would be the brute force solution.

The reason running nginx as site fixed it for you is probably because site was the owner for /var.