New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Permission denied - /var/jenkins_home/copy_reference_file.log #177

Closed
ajohnstone opened this Issue Dec 9, 2015 · 39 comments

Comments

Projects
None yet
@ajohnstone

copy_reference_file.log owned by root and not jenkins

docker run -it \
  --env JAVA_OPTS="${JAVA_OPTS}" \
  --env JENKINS_SLAVE_AGENT_PORT=50001 \
  --name photobox-base-jenkins \
  -p 8080:8080 \
  -p 50001:50001 \
  -v `pwd`/data:/var/jenkins_home \
  jenkins

/usr/local/bin/jenkins.sh: line 25: /var/jenkins_home/copy_reference_file.log: Permission denied
-rw-r--r--  1 root    root     941 Dec  9 15:22 copy_reference_file.log
@jpthiery

This comment has been minimized.

Show comment
Hide comment
@jpthiery

jpthiery Dec 10, 2015

Hi,

Do you run your container on host which have SeLinux enable ?

Try with '--privilleged' option, it may run. This may not be an durable fix, it's just for test.

Hi,

Do you run your container on host which have SeLinux enable ?

Try with '--privilleged' option, it may run. This may not be an durable fix, it's just for test.

@carlossg

This comment has been minimized.

Show comment
Hide comment
@carlossg

carlossg Dec 10, 2015

what jenkins image version? the latest? did you docker pull?
That file is created by the same user that jenkins container runs as

what jenkins image version? the latest? did you docker pull?
That file is created by the same user that jenkins container runs as

@I12crash

This comment has been minimized.

Show comment
Hide comment
@I12crash

I12crash Dec 10, 2015

I just pulled the latest this morning, and I had the same issue. My thoughts were that since the directory I wanted to volume to was empty that caused the issues. Ran without volume and it's starting. I'm going to pull the files from /var/jenkins_home to my local directory and see how that goes. I'll report back.

docker run -p 8080:8080 -p 50000:50000 -v /opt/jenkins:/var/jenkins_home jenkins
/usr/local/bin/jenkins.sh: line 25: /var/jenkins_home/copy_reference_file.log: Permission denied

I just pulled the latest this morning, and I had the same issue. My thoughts were that since the directory I wanted to volume to was empty that caused the issues. Ran without volume and it's starting. I'm going to pull the files from /var/jenkins_home to my local directory and see how that goes. I'll report back.

docker run -p 8080:8080 -p 50000:50000 -v /opt/jenkins:/var/jenkins_home jenkins
/usr/local/bin/jenkins.sh: line 25: /var/jenkins_home/copy_reference_file.log: Permission denied

@ajohnstone

This comment has been minimized.

Show comment
Hide comment
@ajohnstone

ajohnstone Dec 10, 2015

As described from @I12crash the problem only occurs when you mount an external volume.

This is repeatable with the following...

git clone https://github.com/jenkinsci/docker.git jenkinsci-docker
cd jenkinsci-docker;
docker build -t jenkins-test .;
docker rm -f photobox-base-jenkins > /dev/null 2>&1;
docker run -it \
  --env JAVA_OPTS="${JAVA_OPTS}" \
  --env JENKINS_SLAVE_AGENT_PORT=50001 \
  --name photobox-base-jenkins \
  -p 8080:8080 \
  -p 50001:50001 \
  -v `pwd`/data:/var/jenkins_home \
  jenkins-test

The Dockerfile sets the user to "jenkins" when mounting the directory docker sets this under root.
Firstly you could set the logging to user logger I.e. https://gist.github.com/ajohnstone/d372299267ec8e6e9fb7 . However you will get the following error from that point onwards.

mkdir: cannot create directory '/var/jenkins_home/init.groovy.d': Permission denied
cp: cannot create regular file '/var/jenkins_home/init.groovy.d/tcp-slave-agent-port.groovy': No such file or directory

So either don't switch to jenkins, which will solve this issue, or add sudoers to copy the files, let me know your thoughts are or whether you have any other solutions?

As described from @I12crash the problem only occurs when you mount an external volume.

This is repeatable with the following...

git clone https://github.com/jenkinsci/docker.git jenkinsci-docker
cd jenkinsci-docker;
docker build -t jenkins-test .;
docker rm -f photobox-base-jenkins > /dev/null 2>&1;
docker run -it \
  --env JAVA_OPTS="${JAVA_OPTS}" \
  --env JENKINS_SLAVE_AGENT_PORT=50001 \
  --name photobox-base-jenkins \
  -p 8080:8080 \
  -p 50001:50001 \
  -v `pwd`/data:/var/jenkins_home \
  jenkins-test

The Dockerfile sets the user to "jenkins" when mounting the directory docker sets this under root.
Firstly you could set the logging to user logger I.e. https://gist.github.com/ajohnstone/d372299267ec8e6e9fb7 . However you will get the following error from that point onwards.

mkdir: cannot create directory '/var/jenkins_home/init.groovy.d': Permission denied
cp: cannot create regular file '/var/jenkins_home/init.groovy.d/tcp-slave-agent-port.groovy': No such file or directory

So either don't switch to jenkins, which will solve this issue, or add sudoers to copy the files, let me know your thoughts are or whether you have any other solutions?

@jmkgreen

This comment has been minimized.

Show comment
Hide comment
@jmkgreen

jmkgreen Dec 10, 2015

I've hit this with a brand new install today. Looking for a workaround now.

Be advised of moby/moby#7198 (comment) in considering the solution

I've hit this with a brand new install today. Looking for a workaround now.

Be advised of moby/moby#7198 (comment) in considering the solution

@carlossg

This comment has been minimized.

Show comment
Hide comment
@carlossg

carlossg Dec 10, 2015

This is the same as #155 and documented in README

This will store the jenkins data in /your/home on the host. Ensure that /your/home is accessible by the jenkins user in container (jenkins user - uid 1000) or use -u some_other_user parameter with docker run.

You must set the correct permissions in the host before you mount volumes sudo chown 1000 volume_dir

An alternative is discussed in #158

This is the same as #155 and documented in README

This will store the jenkins data in /your/home on the host. Ensure that /your/home is accessible by the jenkins user in container (jenkins user - uid 1000) or use -u some_other_user parameter with docker run.

You must set the correct permissions in the host before you mount volumes sudo chown 1000 volume_dir

An alternative is discussed in #158

@jmkgreen

This comment has been minimized.

Show comment
Hide comment
@jmkgreen

jmkgreen Dec 10, 2015

Resolved albeit with torture involved.

  1. Create a 'jenkins' user on the host, note it's uid
  2. docker run -u <jenkins-uid> ...

Do NOT docker run -u 'jenkins' - This causes the container's own jenkins user to continue to be used. Either choose a different name on the host and pass this through or pass through the resultant uid.

Resolved albeit with torture involved.

  1. Create a 'jenkins' user on the host, note it's uid
  2. docker run -u <jenkins-uid> ...

Do NOT docker run -u 'jenkins' - This causes the container's own jenkins user to continue to be used. Either choose a different name on the host and pass this through or pass through the resultant uid.

@carlossg

This comment has been minimized.

Show comment
Hide comment
@carlossg

carlossg Dec 14, 2015

Added a warning when the jenkins home can't be written to, but this is a matter of using the correct volume/container permissions with Docker

Added a warning when the jenkins home can't be written to, but this is a matter of using the correct volume/container permissions with Docker

@carlossg carlossg closed this Dec 14, 2015

@gionn

This comment has been minimized.

Show comment
Hide comment
@gionn

gionn Jan 7, 2016

@carlossg the problem is triggered when using a host directory as a data volume, since chown is run only once at build-time.

A fix may be to move the chown later, in the jenkins.sh script, so it get executed every time a container is started.

gionn commented Jan 7, 2016

@carlossg the problem is triggered when using a host directory as a data volume, since chown is run only once at build-time.

A fix may be to move the chown later, in the jenkins.sh script, so it get executed every time a container is started.

@carlossg

This comment has been minimized.

Show comment
Hide comment
@carlossg

carlossg Jan 13, 2016

No, that is not possible. The container is run as jenkins (1000) user, so it won't be able to change anything owned by root, no matter where you mount it from

There is an alternative in #158

No, that is not possible. The container is run as jenkins (1000) user, so it won't be able to change anything owned by root, no matter where you mount it from

There is an alternative in #158

@mikeprice99

This comment has been minimized.

Show comment
Hide comment
@mikeprice99

mikeprice99 Jan 13, 2016

I've just come across this. My easy solution is to run as instructed. The container dies. I then change permissions on the folder it created to 777. Then start the container again. It will work.
In my case, I was running as root, but the files created by the container appeared to be owned by 'mike'. So I then changed the owner of the jenkins folder to mike:mike and reset permission to 755.

I've just come across this. My easy solution is to run as instructed. The container dies. I then change permissions on the folder it created to 777. Then start the container again. It will work.
In my case, I was running as root, but the files created by the container appeared to be owned by 'mike'. So I then changed the owner of the jenkins folder to mike:mike and reset permission to 755.

@omorillo

This comment has been minimized.

Show comment
Hide comment
@omorillo

omorillo Jan 13, 2016

@mikeprice99's solution worked for me.

@mikeprice99's solution worked for me.

@heartpandora

This comment has been minimized.

Show comment
Hide comment
@heartpandora

heartpandora Jan 14, 2016

@mikeprice99 chmod -R 777 /my/pah
-Rshould be added

@mikeprice99 chmod -R 777 /my/pah
-Rshould be added

@mikeprice99

This comment has been minimized.

Show comment
Hide comment
@mikeprice99

mikeprice99 Jan 25, 2016

Setting to 777 is just a temporary fix: once you've got it to work you can
simply discover which owner it expects and reset ownership/permissions
accordingly.

On 22 January 2016 at 23:40, Ryan Hartje notifications@github.com wrote:

I wouldn't recommend setting a whole folder to 777 ever. That's a really
bad idea security wise.


Reply to this email directly or view it on GitHub
#177 (comment).

Setting to 777 is just a temporary fix: once you've got it to work you can
simply discover which owner it expects and reset ownership/permissions
accordingly.

On 22 January 2016 at 23:40, Ryan Hartje notifications@github.com wrote:

I wouldn't recommend setting a whole folder to 777 ever. That's a really
bad idea security wise.


Reply to this email directly or view it on GitHub
#177 (comment).

@mchelen

This comment has been minimized.

Show comment
Hide comment
@mchelen

mchelen Jan 27, 2016

#177 (comment) fixes the problem:
If the directory is empty:
sudo chown 1000 volume_dir

If the directory already contains files:
sudo chown -R 1000 volume_dir

mchelen commented Jan 27, 2016

#177 (comment) fixes the problem:
If the directory is empty:
sudo chown 1000 volume_dir

If the directory already contains files:
sudo chown -R 1000 volume_dir

@andyberry88

This comment has been minimized.

Show comment
Hide comment
@andyberry88

andyberry88 Jan 29, 2016

To save someone else burning 2-3 hours trying to debug the same issue I had...

If you've mounted another disk to a path on the host after starting the Docker service Docker will mount the underlying directory, not the drive that is now mounted. You need to restart the Docker service before Docker will use the mounted drive (the comments about directory perms above still apply).

andyberry88 commented Jan 29, 2016

To save someone else burning 2-3 hours trying to debug the same issue I had...

If you've mounted another disk to a path on the host after starting the Docker service Docker will mount the underlying directory, not the drive that is now mounted. You need to restart the Docker service before Docker will use the mounted drive (the comments about directory perms above still apply).

@chevdor

This comment has been minimized.

Show comment
Hide comment
@chevdor

chevdor Mar 2, 2016

Same issue today on 1.642.2.

I actually don´t see why the permissions should be changed on the host. I have a bunch of docker images all working fine without tweaking of the volume permissions.

I am running the container on a NAS thus I cannot teak too much on the users permissions. The volume is mounted RW.

Why does Jenkins require more 'care' than other images (such as mongodb, nginx, mariadb, redis, gitlab, ....)?

chevdor commented Mar 2, 2016

Same issue today on 1.642.2.

I actually don´t see why the permissions should be changed on the host. I have a bunch of docker images all working fine without tweaking of the volume permissions.

I am running the container on a NAS thus I cannot teak too much on the users permissions. The volume is mounted RW.

Why does Jenkins require more 'care' than other images (such as mongodb, nginx, mariadb, redis, gitlab, ....)?

@carlossg

This comment has been minimized.

Show comment
Hide comment
@carlossg

carlossg Mar 3, 2016

because those other images are running as root, doing the chown for you and then switching to a different user. That's what #158 would do

carlossg commented Mar 3, 2016

because those other images are running as root, doing the chown for you and then switching to a different user. That's what #158 would do

@gotgenes

This comment has been minimized.

Show comment
Hide comment
@gotgenes

gotgenes Jun 7, 2016

As mentioned in #277, uid 1000 and gid 1000 are commonly occupied by users/groups in many candidate host operating systems. Because of the issue discussed here of needing to ensure files of the host system's mounted directory are set to the uid and gid of the jenkins user in the container, it would help if a more obscure uid and gid were selected for the jenkins user of the Docker container.

gotgenes commented Jun 7, 2016

As mentioned in #277, uid 1000 and gid 1000 are commonly occupied by users/groups in many candidate host operating systems. Because of the issue discussed here of needing to ensure files of the host system's mounted directory are set to the uid and gid of the jenkins user in the container, it would help if a more obscure uid and gid were selected for the jenkins user of the Docker container.

@s4s0l

This comment has been minimized.

Show comment
Hide comment
@s4s0l

s4s0l Aug 24, 2016

For anybody still fighting this

My docker file:

FROM jenkins:2.7.2
USER root
ENV GOSU_VERSION 1.9
RUN set -x \
    && apt-get update && apt-get install -y --no-install-recommends ca-certificates wget && rm -rf /var/lib/apt/lists/* \
    && dpkgArch="$(dpkg --print-architecture | awk -F- '{ print $NF }')" \
    && wget -O /usr/local/bin/gosu "https://github.com/tianon/gosu/releases/download/$GOSU_VERSION/gosu-$dpkgArch" \
    && wget -O /usr/local/bin/gosu.asc "https://github.com/tianon/gosu/releases/download/$GOSU_VERSION/gosu-$dpkgArch.asc" \
    && export GNUPGHOME="$(mktemp -d)" \
    && gpg --keyserver ha.pool.sks-keyservers.net --recv-keys B42F6819007F00F88E364FD4036A9C25BF357DD4 \
    && gpg --batch --verify /usr/local/bin/gosu.asc /usr/local/bin/gosu \
    && rm -r "$GNUPGHOME" /usr/local/bin/gosu.asc \
    && chmod +x /usr/local/bin/gosu \
    && gosu nobody true

#switch to jenkins to customize
USER jenkins
COPY groovies/executors.groovy /usr/share/jenkins/ref/init.groovy.d/executors.groovy
COPY plugins.txt /usr/share/jenkins/ref/
RUN /usr/local/bin/plugins.sh /usr/share/jenkins/ref/plugins.txt

#switch to root to run
USER root
COPY entrypoint.sh /entrypoint.sh
RUN chmod u+x /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]
CMD ["jenkins", "/bin/tini", "--", "/usr/local/bin/jenkins.sh"]

The entrypoint:

#!/bin/bash
set -e
if [ "$1" = 'jenkins' ]; then
    chown -R jenkins:jenkins "$JENKINS_HOME"
    exec gosu "$@"
fi
exec "$@"

As in https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#/entrypoint
and https://github.com/tianon/gosu#from-debian it solves this problem, quite nicely. It would be nice if this pattern was used in base jenkins image...

s4s0l commented Aug 24, 2016

For anybody still fighting this

My docker file:

FROM jenkins:2.7.2
USER root
ENV GOSU_VERSION 1.9
RUN set -x \
    && apt-get update && apt-get install -y --no-install-recommends ca-certificates wget && rm -rf /var/lib/apt/lists/* \
    && dpkgArch="$(dpkg --print-architecture | awk -F- '{ print $NF }')" \
    && wget -O /usr/local/bin/gosu "https://github.com/tianon/gosu/releases/download/$GOSU_VERSION/gosu-$dpkgArch" \
    && wget -O /usr/local/bin/gosu.asc "https://github.com/tianon/gosu/releases/download/$GOSU_VERSION/gosu-$dpkgArch.asc" \
    && export GNUPGHOME="$(mktemp -d)" \
    && gpg --keyserver ha.pool.sks-keyservers.net --recv-keys B42F6819007F00F88E364FD4036A9C25BF357DD4 \
    && gpg --batch --verify /usr/local/bin/gosu.asc /usr/local/bin/gosu \
    && rm -r "$GNUPGHOME" /usr/local/bin/gosu.asc \
    && chmod +x /usr/local/bin/gosu \
    && gosu nobody true

#switch to jenkins to customize
USER jenkins
COPY groovies/executors.groovy /usr/share/jenkins/ref/init.groovy.d/executors.groovy
COPY plugins.txt /usr/share/jenkins/ref/
RUN /usr/local/bin/plugins.sh /usr/share/jenkins/ref/plugins.txt

#switch to root to run
USER root
COPY entrypoint.sh /entrypoint.sh
RUN chmod u+x /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]
CMD ["jenkins", "/bin/tini", "--", "/usr/local/bin/jenkins.sh"]

The entrypoint:

#!/bin/bash
set -e
if [ "$1" = 'jenkins' ]; then
    chown -R jenkins:jenkins "$JENKINS_HOME"
    exec gosu "$@"
fi
exec "$@"

As in https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#/entrypoint
and https://github.com/tianon/gosu#from-debian it solves this problem, quite nicely. It would be nice if this pattern was used in base jenkins image...

@carlossg

This comment has been minimized.

Show comment
Hide comment
@carlossg

carlossg Aug 24, 2016

@s4s0l that was already discussed in #225

@s4s0l that was already discussed in #225

@s4s0l

This comment has been minimized.

Show comment
Hide comment
@s4s0l

s4s0l Aug 24, 2016

Ok, Got lost in issue graph..anyway this issue is the first that Google finds so maybe someone finds gosu solution useful.

s4s0l commented Aug 24, 2016

Ok, Got lost in issue graph..anyway this issue is the first that Google finds so maybe someone finds gosu solution useful.

alberto56 added a commit to dcycle/dcyclejenkins that referenced this issue Oct 4, 2016

@starstuffharvestingstarlight

This comment has been minimized.

Show comment
Hide comment
@starstuffharvestingstarlight

starstuffharvestingstarlight Dec 9, 2016

I know this is an old thread, but this is how I fixed this issue to have jenkins run as a specific user on the host (with correct permissions):

FROM jenkins:latest

ARG HOST_UID
ARG HOST_GID

USER root

RUN echo $HOST_UID $HOST_GID $JAVA_OPTS

RUN groupmod -g ${HOST_GID} jenkins
RUN usermod -u ${HOST_UID} -g ${HOST_GID} jenkins

USER jenkins

then I provide HOST_UID and HOST_GID as arguments.

I know this is an old thread, but this is how I fixed this issue to have jenkins run as a specific user on the host (with correct permissions):

FROM jenkins:latest

ARG HOST_UID
ARG HOST_GID

USER root

RUN echo $HOST_UID $HOST_GID $JAVA_OPTS

RUN groupmod -g ${HOST_GID} jenkins
RUN usermod -u ${HOST_UID} -g ${HOST_GID} jenkins

USER jenkins

then I provide HOST_UID and HOST_GID as arguments.

@shenliuyang

This comment has been minimized.

Show comment
Hide comment
@shenliuyang

shenliuyang Dec 20, 2016

sudo chown -R 1000:1000 volume_dir

sudo chown -R 1000:1000 volume_dir

yabuchan added a commit to yabuchan/jenkins-on-kubernetes that referenced this issue Apr 8, 2017

fatihkilic pushed a commit to fatihkilic/docker that referenced this issue Apr 14, 2017

@SaravanaStorageNetwork

This comment has been minimized.

Show comment
Hide comment
@SaravanaStorageNetwork

SaravanaStorageNetwork May 3, 2017

Changing permission of $PWD/jenkins to 1000 helped
This should be updated in this document - https://jenkins.io/doc/book/getting-started/installing/#docker

SaravanaStorageNetwork commented May 3, 2017

Changing permission of $PWD/jenkins to 1000 helped
This should be updated in this document - https://jenkins.io/doc/book/getting-started/installing/#docker

@ravigomez

This comment has been minimized.

Show comment
Hide comment
@ravigomez

ravigomez May 12, 2017

Dears,

I Solved it creating a host folder like this:

sudo mkdir -p /srv/docker/jenkins/jenkins
sudo chmod 777 /srv/docker/jenkins/jenkins

Dears,

I Solved it creating a host folder like this:

sudo mkdir -p /srv/docker/jenkins/jenkins
sudo chmod 777 /srv/docker/jenkins/jenkins

@jonefeewang

This comment has been minimized.

Show comment
Hide comment
@jonefeewang

jonefeewang Sep 28, 2017

I solved this problem with don't chmod or chown any folder, just let it be.

My environment :

     Mac OS x 10.9.5
    docker tools for mac (installed with ` brew install docker `)

just mkdir jenkins_home and then run docker run -d -p 8080:8080 -p 50000:50000 -v $PWD/jenkins_home:/var/jenkins_home --name jenkins jenkins

I solved this problem with don't chmod or chown any folder, just let it be.

My environment :

     Mac OS x 10.9.5
    docker tools for mac (installed with ` brew install docker `)

just mkdir jenkins_home and then run docker run -d -p 8080:8080 -p 50000:50000 -v $PWD/jenkins_home:/var/jenkins_home --name jenkins jenkins

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Oct 3, 2017

In k8s for volumes you can use securityContext:

securityContext:
  fsGroup: 1000

ghost commented Oct 3, 2017

In k8s for volumes you can use securityContext:

securityContext:
  fsGroup: 1000
@harigitgub

This comment has been minimized.

Show comment
Hide comment
@harigitgub

harigitgub Oct 24, 2017

docker run -it --rm --name jenkins -p 8090:8080 -p 50 000:50000 -v /home/docker/jenkins:/var/jenkins_home csanchez/jenkins-kubernetes

after running this command and checking in the browser with http://ip:8090 it is asking for password after installing of jenkins.
As password is shown in terminal i entered and it asking to install plugins in which kubernetes plugin not available and it screen stuck there?

any suggestions on this

docker run -it --rm --name jenkins -p 8090:8080 -p 50 000:50000 -v /home/docker/jenkins:/var/jenkins_home csanchez/jenkins-kubernetes

after running this command and checking in the browser with http://ip:8090 it is asking for password after installing of jenkins.
As password is shown in terminal i entered and it asking to install plugins in which kubernetes plugin not available and it screen stuck there?

any suggestions on this

@hemano

This comment has been minimized.

Show comment
Hide comment
@hemano

hemano Nov 15, 2017

On Linux below steps worked for me:

mkdir $PWD/jenkins

sudo chown -R 1000:1000 $PWD/jenkins

docker run -d -p 8080:8080 -p 50000:50000 -v $PWD/jenkins:/var/jenkins_home --name jenkins jenkins

hemano commented Nov 15, 2017

On Linux below steps worked for me:

mkdir $PWD/jenkins

sudo chown -R 1000:1000 $PWD/jenkins

docker run -d -p 8080:8080 -p 50000:50000 -v $PWD/jenkins:/var/jenkins_home --name jenkins jenkins

@tarunsinghaldotme

This comment has been minimized.

Show comment
Hide comment
@tarunsinghaldotme

tarunsinghaldotme Jan 22, 2018

@hemano
changing ownership resolved my prob
thanks

@hemano
changing ownership resolved my prob
thanks

@sobi3ch

This comment has been minimized.

Show comment
Hide comment
@sobi3ch

sobi3ch Apr 16, 2018

id -g if it doesn't show 1000 then you need to pass -u $(id -g) to docker run command.

sobi3ch commented Apr 16, 2018

id -g if it doesn't show 1000 then you need to pass -u $(id -g) to docker run command.

@swateek

This comment has been minimized.

Show comment
Hide comment
@swateek

swateek May 20, 2018

I did two things without creating a JENKINS user.

sudo chmod -R 777 /home/swateek/tmp/jenkins/data

sudo docker run --rm --privileged -p 8080:8080 -p 50000:50000 -v /home/swateek/tmp/jenkins/data:/var/jenkins_home jenkins

Running docker with privileged helped!

swateek commented May 20, 2018

I did two things without creating a JENKINS user.

sudo chmod -R 777 /home/swateek/tmp/jenkins/data

sudo docker run --rm --privileged -p 8080:8080 -p 50000:50000 -v /home/swateek/tmp/jenkins/data:/var/jenkins_home jenkins

Running docker with privileged helped!

@carlossg

This comment has been minimized.

Show comment
Hide comment
@carlossg

carlossg May 20, 2018

Running docker with privileged helped!

wow that's a horrible idea

Running docker with privileged helped!

wow that's a horrible idea

@batmat

This comment has been minimized.

Show comment
Hide comment
@batmat

batmat May 20, 2018

Member

For the record, use a volume, see the recommended solution a bit more detailed at #493 (comment)

I.e. do not try to mount the host into the container, aka bind-mount. This is the way to get hurt, and solve it by a workaround. Using bind-mounts to store production data is really not the way to go.

Member

batmat commented May 20, 2018

For the record, use a volume, see the recommended solution a bit more detailed at #493 (comment)

I.e. do not try to mount the host into the container, aka bind-mount. This is the way to get hurt, and solve it by a workaround. Using bind-mounts to store production data is really not the way to go.

@Lewiscowles1986

This comment has been minimized.

Show comment
Hide comment
@Lewiscowles1986

Lewiscowles1986 Jul 12, 2018

Also in-case anyone is as stupid as me. Try to check your $PWD

I just got this from a script changing dir into /opt which is root owned. 🤦‍♂️

Also in-case anyone is as stupid as me. Try to check your $PWD

I just got this from a script changing dir into /opt which is root owned. 🤦‍♂️

@batmat

This comment has been minimized.

Show comment
Hide comment
@batmat

batmat Jul 12, 2018

Member

Do.Not.Use.Bind.Mounts. You will get burnt by all manners of permissions issues. That is expected, and using bind mounts is documented to be wrong.

Use volumes

Again, see #493 (comment)

@carlossg should we lock this issue?

Member

batmat commented Jul 12, 2018

Do.Not.Use.Bind.Mounts. You will get burnt by all manners of permissions issues. That is expected, and using bind mounts is documented to be wrong.

Use volumes

Again, see #493 (comment)

@carlossg should we lock this issue?

@phlegx

This comment has been minimized.

Show comment
Hide comment
@phlegx

phlegx Aug 2, 2018

Actually I think this permission issue can and should be solved by the Jenkins Docker image in the entrypoint.sh script. See also my discussion about this mechanism I had a wile ago on this custom postgres image here sameersbn/docker-postgresql#56

phlegx commented Aug 2, 2018

Actually I think this permission issue can and should be solved by the Jenkins Docker image in the entrypoint.sh script. See also my discussion about this mechanism I had a wile ago on this custom postgres image here sameersbn/docker-postgresql#56

@arprastogi

This comment has been minimized.

Show comment
Hide comment
@arprastogi

arprastogi Aug 8, 2018

mkdir /home/ronit/jenkins_home
chown 1000:1000 /home/ronit/jenkins_home

docker run --privileged --name jenkins-1 -p 8080:8080 -p 50000:50000 -v /home/ronit/jenkins_home:/var/jenkins_home jenkins

mkdir /home/ronit/jenkins_home
chown 1000:1000 /home/ronit/jenkins_home

docker run --privileged --name jenkins-1 -p 8080:8080 -p 50000:50000 -v /home/ronit/jenkins_home:/var/jenkins_home jenkins

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment