0

I have setup a site with a symlinked dir on nginx ubuntu server.

When I access the root of the site I get this:

/usr/share/nginx/html/releases/*********/craft/storage isn't writable by PHP. Please fix that.

In my structure I have a folder called current that gets symlinked to the new deployed site in releases and then current should point to that.

Can anyone shed some light on what might be happening here and how I can set the write permissions to the symlinked dir?

Thanks, Mark

  • AFAIK, permissions on symlinks should work exactly the same as "normal" files/folders. Maybe nginx is configured not to follow symlinks? – Brad Bell Apr 18 '16 at 17:14
1

Symlinks don't really have permissions themselves.

If I had to hazard a guess, it sounds like your deployment script isn't setting the correct permissions on the craft/storage directory, maybe because they're being recreated every time you deploy?

I think you have a couple options:

  • set the permissions on that directory correctly (see the above link) after you deploy
  • change your deployment strategy a bit.

If it were me, I'd tell the build/deploy script to ignore the craft/storage directory altogether. Setup your own storage folder that won't be touched by your deploy script (say above the releases folder) after you deploy. Then just tell Craft to use that location.

What is the symlink actually pointing to?

You could really deploy anywhere on the server too, not just in the typical nginx web root. (I prefer not to even touch the default distro locations because any update could modify your web files.)

If you want to go down the path of permissions, it gets a little murkier. I don't have a ton of experience with something like Capistrano (or whatever deployment system you're using) but your deploy user needs to have sudo permission to be able to change the permissions so your PHP user—likely the same user as the nginx user but not the same as the deploy user—can write to it.

One way around this is PHP-FPM. Setup a new fpm pool with the user/group of the deploy user then add whatever user you're running nginx as to that user's group (eg usermod -a -G deploy-user www-data)

That will let nginx read files from the deploy user but let FPM write to the folder because it owns it. Then you won't have to worry as much about after-deployment permissions.

It's also cheap jail if you set it up properly.

(If you're running Apache as mod_php with nginx in front of it, it'd be a similar setup.)

  • Hi RitterKnight, thanks for the info above. I have changed permissions with the Capistrano deploy script and that worked but now obviously its moving down the chain and not letting me access /public dir in the current folder which gives me an error 404 on the front-end but in the error log I get: 2016/04/18 12:49:22 [crit] 19336#0: *7 stat() "/usr/share/nginx/html/current/public/" failed (13: Permission denied), client: 80.87.27.52, server: ********, request: "GET / HTTP/1.1", host: "*******" – M dunbavan Apr 19 '16 at 13:01
  • What user/group is the webserver/cap user? If you do a ls -al on the public folder, that'll tell you what's up. nginx itself needs to have permission to read that tree too. You may have to do something like chmod -R 755 /usr/share/nginx/html/current/* within your capistrano script. – RitterKnight Apr 19 '16 at 18:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.