Permission denied error when unpacking droplet


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.


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","...


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


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


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.


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.