Permission denied error when unpacking droplet


Kyle Havlovitz (kyhavlov)
 

I'm getting the following error when pushing an app (dea logs):
{"timestamp":1443390480.7652702,"message":"\"cd /home/vcap/ && tar zxf /tmp/dea_ng/droplets/6ed0ecb3edbc2822ced1d2fb54b6d62b67a86aa8/droplet.tgz\" exited with status 2 with data {:script=>\"cd /home/vcap/ && tar zxf /tmp/dea_ng/droplets/6ed0ecb3edbc2822ced1d2fb54b6d62b67a86aa8/droplet.tgz\", :exit_status=>2, :stdout=>\"\", :stderr=>\"tar: ./logs: Cannot mkdir: Permission denied\\ntar: ./logs: Cannot mkdir: Permission denied\\ntar: ./logs/staging_task.log: Cannot open: No such file or directory\\ntar: ./tmp: Cannot mkdir: Permission denied\\ntar: ./staging_info.yml: Cannot open: Permission denied\\ntar: .: Cannot utime: Operation not permitted\\ntar: Exiting with failure status due to previous errors\\n\"}","log_level":"warn","source":"Container","data":{},"thread_id":69954816652080,"fiber_id":69954833634360,"process_id":26381,"file":"/opt/cloudfoundry/dea_next/lib/container/container.rb","lineno":80,"method":"run_script"}

I'm not sure what's causing this or the permissions needed and for what component here. Any help would be much appreciated.


Amit Gupta
 

The DEA is trying to run a script in the warden container to untar the droplet. For some reason, the user executing the script and the file system permissions in the container in the /home/vcap directory are not what they're supposed to be. I believe you are deploying and running all the Cloud Foundry components in a non-standard way. You may wish to try a more standard deployment, and look at the differences in users and file system permissions between the standard deployment and your deployment, and reverse-engineer what would need to be fixed in your deployment to get things to work. Here's a blog post, at the end it talks about how you can get a session into a warden container (http://andypiper.co.uk/2014/02/17/getting-inside-cloud-foundry-for-debug-and-profit/). Alternatively you can look at the startup scripts used in the standard deployments, e.g. (https://github.com/cloudfoundry/cf-release/blob/master/jobs/dea_next/templates/dea_ctl.erb).

Since you've configured all your components in a very idiosyncratic manner, it's hard to say generally what you need to fix to get all the permissions right.


Rohit Kelapure <rkelapure@...>
 

On Mon, Sep 28, 2015 at 7:03 PM, Amit Gupta <amitkgupta84(a)gmail.com> wrote:

The DEA is trying to run a script in the warden container to untar the
droplet. For some reason, the user executing the script and the file
system permissions in the container in the /home/vcap directory are not
what they're supposed to be. I believe you are deploying and running all
the Cloud Foundry components in a non-standard way. You may wish to try a
more standard deployment, and look at the differences in users and file
system permissions between the standard deployment and your deployment, and
reverse-engineer what would need to be fixed in your deployment to get
things to work. Here's a blog post, at the end it talks about how you can
get a session into a warden container (
http://andypiper.co.uk/2014/02/17/getting-inside-cloud-foundry-for-debug-and-profit/).
Alternatively you can look at the startup scripts used in the standard
deployments, e.g. (
https://github.com/cloudfoundry/cf-release/blob/master/jobs/dea_next/templates/dea_ctl.erb
).

Since you've configured all your components in a very idiosyncratic
manner, it's hard to say generally what you need to fix to get all the
permissions right.
--
Pivotal CF Architect
rkelapure(a)pivotal.io
cell: 9197242524


Kyle Havlovitz (kyhavlov)
 

Looking into this more, it seems like the cause is that the /home/vcap directory is owned by root instead of vcap. I can't figure out what would cause this, though.

From: Rohit Kelapure <rkelapure(a)pivotal.io<mailto:rkelapure(a)pivotal.io>>
Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Date: Tuesday, September 29, 2015 at 10:12 AM
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Subject: [cf-dev] Re: Re: Permission denied error when unpacking droplet

How to login into a warden container :
http://cloud.rohitkelapure.com/2015/09/debugging-dea-issues-on-cloud-foundry.html

On Mon, Sep 28, 2015 at 7:03 PM, Amit Gupta <amitkgupta84(a)gmail.com<mailto:amitkgupta84(a)gmail.com>> wrote:
The DEA is trying to run a script in the warden container to untar the droplet. For some reason, the user executing the script and the file system permissions in the container in the /home/vcap directory are not what they're supposed to be. I believe you are deploying and running all the Cloud Foundry components in a non-standard way. You may wish to try a more standard deployment, and look at the differences in users and file system permissions between the standard deployment and your deployment, and reverse-engineer what would need to be fixed in your deployment to get things to work. Here's a blog post, at the end it talks about how you can get a session into a warden container (http://andypiper.co.uk/2014/02/17/getting-inside-cloud-foundry-for-debug-and-profit/). Alternatively you can look at the startup scripts used in the standard deployments, e.g. (https://github.com/cloudfoundry/cf-release/blob/master/jobs/dea_next/templates/dea_ctl.erb).

Since you've configured all your components in a very idiosyncratic manner, it's hard to say generally what you need to fix to get all the permissions right.



--
Pivotal CF Architect
rkelapure(a)pivotal.io<mailto:rkelapure(a)pivotal.io>
cell: 9197242524


Aliaksei Makarevich <snork.mitzumi@...>
 

I have the same problem with Stacks. Changing permissions manually to openworld RW don't change a thing. Has anyone else faced such issue?

{"timestamp":1445792695.6604235,"message":"run (took 1.328794)","log_level":"debug","source":"Warden::Container::Linux","data":{"handle":"192u2he1nqp","request":{"handle":"192u2he1nqp","script":"cd /home/vcap/ && tar zxf /var/vcap/data/dea_next/droplets/3c3efe6dcad047fafda0495897069a0867277e5a/droplet.tgz"},"response":{"exit_status":2,"stdout":"","stderr":"tar: ./staging_info.yml: Cannot open: Permission denied\ntar: ./logs: Cannot mkdir: Permission denied\ntar: ./logs: Cannot mkdir: Permission denied\ntar: ./logs/staging_task.log: Cannot open: No such file or directory\ntar: ./tmp: Cannot mkdir: Permission denied\ntar: .: Cannot utime: Operation not permitted\ntar: Exiting with failure status due to previous errors\n","info":"#<Warden::Protocol::InfoResponse:0x007fc470870be0>"}},"thread_id":70240825357100,"fiber_id":70240831615120,"process_id":17093,"file":"/var/vcap/data/packages/warden/88b0ad837f313990ce408e50cd904f7025983213.1-358cd8f2e7dedc2e0f4d86f7234b1bc21e82314d/warden/lib/warden/container/base.rb","...


Noburou TANIGUCHI
 

I am not sure at all but it might be related umask.

What is the umask of the user you deployed your CF (I assume you are talking
about a private CF).

I've been feeling there's an implicit assumption in the cf deployment with
bosh and cf-release that umask is 022 (or 002; Ubuntu default).



-----
I'm not a ...
noburou taniguchi
--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-Re-Permission-denied-error-when-unpacking-droplet-tp2441p2537.html
Sent from the CF Dev mailing list archive at Nabble.com.