<p>Symlinks don't really have <a href="https://superuser.com/a/303063">permissions</a> themselves. </p>

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

<p>I think you have a couple options:</p>

<ul>
<li>set the permissions on that directory correctly (see the above link) after you deploy</li>
<li>change your deployment strategy a bit.</li>
</ul>

<p>If it were me, I'd tell the build/deploy script to <a href="https://craftcms.com/support/craft-storage-gitignore" rel="nofollow noreferrer">ignore</a> the <code>craft/storage</code> directory altogether. Setup your own <code>storage</code> folder that won't be touched by your deploy script (say above the releases folder) after you deploy. Then just <a href="https://craftcms.com/docs/php-constants#craft-storage-path" rel="nofollow noreferrer">tell Craft</a> to use that location.</p>

<p>What is the symlink actually pointing to? </p>

<p>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.)</p>

<p>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 <code>sudo</code> 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.</p>

<p>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 <code>usermod -a -G deploy-user www-data</code>)</p>

<p>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.</p>

<p>It's also cheap jail if you set it up properly.</p>

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

CC BY-SA 3.0
2016-04-19T13:01:02.633Z
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
CC BY-SA 3.0
2016-04-19T18:04:25.937Z
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
CC BY-SA 3.0
2016-04-18T18:05:52.417Z
2016-04-18T18:05:52.417Z
2017-03-20T10:18:35.480Z
RitterKnight
<p>I have setup a site with a symlinked dir on nginx ubuntu server.</p>

<p>When I access the root of the site I get this:</p>

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

<p>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.</p>

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

<p>Thanks,
Mark</p>

CC BY-SA 3.0
2016-04-18T17:14:15.727Z
AFAIK, permissions on symlinks should work exactly the same as "normal" files/folders. Maybe nginx is configured not to follow symlinks?
Brad Bell
<config><install><permissions>
How possible is it to set write permissions on storage folder on symlinked install?
# How possible is it to set write permissions on storage folder on symlinked install?

(Asked by: username_0 on 2016-04-18)

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

**Tags:** config, install, permissions
> **Comments:**
> **username_1**: AFAIK, permissions on symlinks should work exactly the same as "normal" files/folders. Maybe nginx is configured not to follow symlinks?  

---

## 1 answers

### Answer by username_2 on 2016-04-18. Score: 1

Symlinks don't really have [permissions](https://superuser.com/a/303063) 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](https://craftcms.com/support/craft-storage-gitignore) 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](https://craftcms.com/docs/php-constants#craft-storage-path) 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.)

> **Comments:**
> **username_0**: 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: "*******"`  
> **username_2**: 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.  

---

