# Deploy: OSError: [Errno 13] Permission denied

**URL:** https://discourse.roots.io/t/deploy-oserror-errno-13-permission-denied/15399
**Category:** trellis
**Created:** 2019-04-26T22:45:15Z
**Posts:** 2

## Post 1 by @strarsis — 2019-04-26T22:45:15Z

So I set up a new staging Ubuntu Server 18.04.2 LTS system on Hyper-V and  
successfully provisioned it as `trellis` system with `ansible`.

**However, deploying a site to it results in an error message very early during deploy:**

```
MODULE FAILURE
Traceback (most recent call last):
File "/tmp/ansible_oJ2ASV/ansible_module_deploy_helper.py", line 529, in
<module>
main()
File "/tmp/ansible_oJ2ASV/ansible_module_deploy_helper.py", line 491, in
main
changes += deploy_helper.create_path(facts['releases_path'])
File "/tmp/ansible_oJ2ASV/ansible_module_deploy_helper.py", line 352, in
create_path
os.makedirs(path)
File "/usr/lib/python2.7/os.py", line 157, in makedirs
mkdir(name, mode)
OSError: [Errno 13] Permission denied: '/srv/www/example.com/releases'
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: OSError: [Errno 13] Permission denied: '/srv/www/example.com/releases'
fatal: [staging-1]: FAILED! => {"changed": false, "module_stdout": "", "rc": 1}
```

**I found similar issues on the internet, so I list them here:**

> [@Rmtree failed: [Errno 13] Permission denied at Finalize the deploy](https://discourse.roots.io/t/rmtree-failed-errno-13-permission-denied-at-finalize-the-deploy/11123/4):
>
> I’ve run into this a few times before - if a prior deploy failed, Ansible will be unable to remove it (the release folder) during a subsequent deploy. Looking at the path referenced, I’d guess your deploy on 12/09/2017 @ 22:27:49 didn’t complete, but the folder is still there. SSH into the machine, and run rm -rf /srv/www/mysite.com/releases/20171209222749/ - you should also run rm -rf /srv/www/mysite.com/releases/20171212123959/ since the deploy failed on that too, so eventually you’ll run i…

[https://discourse.roots.io/t/trellis-bin-deploy-sh-deploy-error/9213](https://discourse.roots.io/t/trellis-bin-deploy-sh-deploy-error/9213)  
[https://discourse.roots.io/t/trellis-aws-and-provision/5496/6](https://discourse.roots.io/t/trellis-aws-and-provision/5496/6)  
[https://github.com/roots/trellis/issues/908](https://github.com/roots/trellis/issues/908)  
[https://imwz.io/roots-trellis-errors/](https://imwz.io/roots-trellis-errors/)

**So from what I learned from these discussions is that this kind of error can happen:**

- **When provisioning hadn’t ran yet, either never had, or for the site to be deployed.**  
However, the initial provisioning including that site in config, ran successfully.
- **Ownership and permissions of /srv and its subfolders are somehow off.**  
These look correct for me, also I can manually create the directory `/srv/www/example.com/releases` as user `web`, hence ansible should be able, too.
- **In some rare cases something went wrong with the provisioned server and  
the only way fixing is to completely recreate it from scratch.**  
This I did after the first occurence of this issue and  
I can do this repeatedly with the same error as result.

**I can reproduce this issue each time with a new VM from scratch:**

- Create new minimal Ubuntu Server 18.04.2 LTS system (with OpenSSH server) on Hyper-V.
  - Disable IPv6 in Ubuntu because it caused many issues, also for other users.  
So we are using only IPv4 here.

- Install `ansible` tested with `trellis`,  
Installed the `ansible` package available on Ubuntu workstation (`ansible 2.4.3.0`).
- Clone [trellis](https://github.com/roots/trellis) from GitHub: `git clone https://github.com/roots/trellis`
  - Set up some example site in `group_vars/staging/wordpress_sites.yml`

- Run (initial) provisioning, it should complete just fine.
- Now try to deploy the example site,  
it should fail very early during deploy with the error shown above.

**How can I find out the reason for (and hopefully fix) this strange issue?**

---

## Post 2 by @strarsis — 2019-04-27T18:24:30Z

For devs that encounter this issue in the future:

In `hosts/staging` `ansible_user=admin` was set for the host,  
this caused the issue. This also seems to be a bug because not a single source of truth is used for the username, or at least the username can be partly influenced by `ansible_user`.

---

## Post 3 by @system — 2019-06-07T22:45:15Z

This topic was automatically closed after 42 days. New replies are no longer allowed.