Bamboo + docker = Could not remove working directory for plan

Hey guys,

I'm running a docker container as a docker task in order to run tests against a branch of code. The docker container simply runs while mounting the working dir as /data (default) then generates artifacts in that mounted dir that bamboo access directly (thanks to the mount). This works great. The problem comes when bamboo tries to erase the working dir it says it does not have the correct permissions :

19-Sep-2016 10:40:28
Finished publishing of artifact Job artifact: [JUnit], pattern: [**/junit.xml] anchored at: [build/logs] in 1.408 ms

19-Sep-2016 10:40:28
Running post build plugin 'npm Cache Cleanup'

19-Sep-2016 10:40:28
Running post build plugin 'Clover Results Collector'

19-Sep-2016 10:40:28
Running post build plugin 'Docker Container Cleanup'

19-Sep-2016 10:40:28
Could not remove working directory for plan 'REXM-DEV6-UT': /var/atlassian/application-data/bamboo/xml-data/build-dir/REXM-DEV6-UT/build/logs: Operation not permitted

19-Sep-2016 10:40:28
Finalising the build...

Anyone know what could be the cause of this? I'm guessing it's somehow related to the volumes not being removed or something? 

 

Any help would be appreciated.

Cheers.

4 answers

1 accepted

The big problem of docker is that a root in a container is a root on the host. So any files created in docker is owned by root and cannot be removed by a bamboo agent if it is run not as root. Solution: run chown -R $UID:$UID.

Thanks for the info. In theory if the files in the container were generated with different permissions would that bleed out into the host? Say either have a user in the container with the same user name as bamboo. Or perhaps 777 rights on generated files?

Our solution was a bit different, and more of a hack:

Let's say the uid and gid of the bamboo user on the agent host (not the container!) is 1000.  We have our own internal docker registry from which we pull images from to generate containers from.  In there, one of the statements in the Dockerfile looks like:

...
RUN groupadd -g 1000 bamboo
RUN useradd --gid bamboo --create-home --uid 1000 bamboo
...
USER bamboo

Then, when the container runs, it runs as the image's "bamboo" user (which is really run as UID 1000), which matches the UID of the "bamboo" user that's running the agent itself.

Things get a little bit sticky if you have a lot of agent hosts, though - you'll need some way to manage that the UID of the bamboo user is "always" the same on each host.  Otherwise, that breaks down.

That having been said, this is probably the wrong approach - You should probably be mounting RO the local working directory (xml-data/build-dir/XXX), assuming that you need to copy something into there, like the source code, then, as part of the build, copy those contents to another directory on the container only, run the build from there, and make extensive use of the "docker copy" command when done.  You would then flag artifacts that you care about for the build, and specifically "docker copy" those artifacts back to the agent, then remove the docker container.  This assumes, of course, that you're not deploying the container itself as an artifact (we don't).

Suggest an answer

Log in or Sign up to answer
Atlassian Community Anniversary

Happy Anniversary, Atlassian Community!

This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.

Read more
Community showcase
Renan Battaglin
Published May 18, 2017 in Bamboo

FAQ: How to Upgrade Bamboo Server

Bamboo 5.9 will no longer be supported after June 12, 2017. What does this mean? As part of our End of Life policy, Atlassian supports major versions for two years after the first major iteratio...

1,321 views 0 5
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you