I'm trying to install HTTPD in docker, I wrote a dockerfile like this:
FROM centos
VOLUME /var/log/httpd
VOLUME /etc/httpd
VOLUME /var/www/html
# Update Yum Repostory
RUN yum clean all && \
yum makecache fast && \
yum -y update && \
yum -y install httpd
RUN yum clean all
EXPOSE 80
CMD /usr/sbin/httpd -D BACKGROUND && tail -f /var/log/httpd/access_log
it works if I run the image without host volumes, but failed if I use parameter:
--volume /data/httpd/var/www/html:/var/www/html --volume /data/httpd/var/log:/var/log --volume /data/httpd/etc:/etc/httpd
the error message is:
httpd: Could not open configuration file /etc/httpd/conf/httpd.conf: No such file or directory
I checked the mount point which is empty:
# ll /data/httpd/etc/
total 0
But if I don't use "volume" by default docker copys over files to a temp folder:
# ll /var/lib/docker/volumes/04f083887e503c6138a65b300a1b40602d227bb2bbb58c69b700f6ac753d1c34/_data
total 4
drwxr-xr-x. 2 root root 35 Nov 3 03:16 conf
drwxr-xr-x. 2 root root 78 Nov 3 03:16 conf.d
drwxr-xr-x. 2 root root 4096 Nov 3 03:16 conf.modules.d
lrwxrwxrwx. 1 root root 19 Nov 3 03:16 logs -> ../../var/log/httpd
lrwxrwxrwx. 1 root root 29 Nov 3 03:16 modules -> ../../usr/lib64/httpd/modules
lrwxrwxrwx. 1 root root 10 Nov 3 03:16 run -> /run/httpd
So I'm confused, why docker refused to copy them to the named location? and how to fix this problem?
This is a documented behavior indeed:
Volumes are initialized when a container is created. If the container’s
base image contains data at the specified mount point, that existing data
is copied into the new volume upon volume initialization. (Note that this
does not apply when mounting a host directory.)
i.e. when you mount the /etc/httpd volume --volume /data/httpd/etc:/etc/httpd, no data will be copied.
You can also see https://github.com/docker/docker/pull/9092 for a more detailed discussion on why it works this way (in case you are interested).
A usual workaround for this is to copy your initial data, to the volume folder (from within the container), inside your ENTRYPOINT or CMD script,
in case it is empty.
Note that your initial dataset must be kept outside the volume folder (e.g. as .tar file in /opt), for this to work, as the volume folder will be shadowed by the host folder mounted over it.
Given below is a sample Dockerfile and Script, which demonstrate the behavior:
Sample Dockerfile
FROM debian:stable
RUN mkdir -p /opt/test/; touch /opt/test/initial-data-file
VOLUME /opt/test
Sample script (try various volume mappings)
#Build image
>docker build -t volumetest .
Sending build context to Docker daemon 2.56 kB
Step 0 : FROM debian:stable
---> f7504c16316c
Step 1 : RUN mkdir -p /opt/test/; touch /opt/test/initial-data-file
---> Using cache
---> 1ea0475e1a18
Step 2 : VOLUME /opt/test
---> Using cache
---> d8d32d849b82
Successfully built d8d32d849b82
#Implicit Volume mapping (as defined in Dockerfile)
>docker run --rm=true volumetest ls -l /opt/test
total 0
-rw-r--r-- 1 root root 0 Nov 4 18:26 initial-data-file
#Explicit Volume mapping
> docker run --rm=true --volume /opt/test volumetest ls -l /opt/test/
total 0
-rw-r--r-- 1 root root 0 Nov 4 18:26 initial-data-file
#Explicitly Mounted Volume
>mkdir test
>docker run --rm=true --volume "$(pwd)/test/:/opt/test" volumetest ls -l /opt/test
total 0
And here is a simple entrypoint script, illustrating a possible workaround:
#!/bin/bash
VOLUME=/opt/test
DATA=/opt/data-volume.tar.gz
if [[ -n $(find "$VOLUME" -maxdepth 0 -empty) ]]
then
echo Preseeding VOLUME $VOLUME with data from $DATA...
tar -C "$VOLUME" -xvf "$DATA"
fi
"$#"
add the following to the Dockerfile
COPY data-volume.tar.gz entrypoint /opt/
ENTRYPOINT ["/opt/entrypoint"]
First run:
>docker run --rm=true --volume "$(pwd)/test/:/opt/test" volumetest ls -l /opt/test
Preseeding VOLUME /opt/test with data from /opt/data-volume.tar.gz...
preseeded-data
total 0
-rw-r--r-- 1 1001 users 0 Nov 4 18:43 preseeded-data
Subsequent runs:
>docker run --rm=true --volume "$(pwd)/test/:/opt/test" volumetest ls -l /opt/test
ls -l /opt/test
total 0
-rw-r--r-- 1 1001 users 0 Nov 4 18:43 preseeded-data
Note, that the volume folder will only be populated with data,
if it was completely empty before.
Related
Using:
podman version 4.2.0
AlmaLinux 8.7
I've created an image based on redhat/ubi8 with the following Dockerfile:
FROM docker.io/redhat/ubi8
RUN dnf install -y gcc-c++ cmake python39 openssh git
RUN useradd -ms /bin/bash foobar -g users
USER foobar
WORKDIR /home/foobar/
RUN mkdir -p .ssh
$ docker build -t mount_test_image .
I run the image from a directory that contains a directory ssh, and I want to mount that directory to /home/foobar/.ssh with ownership of foobar.users
$ ls -l
-rw-r--r--. 1 host_user users 269 Dec 7 09:10 Dockerfile
drwxrwxr-x. 2 host_user users 18 Dec 2 10:41 ssh
docker run -it -d --rm --mount type=bind,src=ssh,target=/home/foobar/.ssh --name=mount_test mount_test_image
However when I enter the container via
docker exec -it mount_test '/bin/sh'
The home directory looks like this:
drwx------. 1 foobar users 18 Dec 7 17:10 .
drwxr-xr-x. 1 root root 21 Dec 7 17:10 ..
-rw-r--r--. 1 foobar users 18 Jun 20 11:31 .bash_logout
-rw-r--r--. 1 foobar users 141 Jun 20 11:31 .bash_profile
-rw-r--r--. 1 foobar users 376 Jun 20 11:31 .bashrc
drwxrwxr-x. 2 root root 18 Dec 2 18:41 .ssh
I obviously get a "permission denied" when trying to access that directory.
sh-4.4$ ls /home/foobar/.ssh
ls: cannot open directory '/home/foobar/.ssh': Permission denied
I tried changing the ownership of the directory on the host to match the uid of the container user, but then it just looks like this:
drwxrwxr-x. 2 nobody root 18 Dec 2 18:41 .ssh
My host user uid:gid is 501:100 and the container user is 1000:100. Right now I'm just trying to generate an ssh key to upload to bitbucket, but this seems like a simple feature a container should be have. All the tutorials and examples just stop after the --mount command instruction and say "there ya go!". What good is the mount point if you can't read/write it?
EDIT:
I tried on Archlinux using docker instead of podman and it works like one would expect with both -v and --mount. The owner of the mounted directory in the container matches the uid and gid of the host. Is this then a bug in podman or is it just done differently?
You are using a non-root user (foobar) in a rootless container. You must use --userns=keep-id for the container user to see the mounted volumes.
https://github.com/containers/podman/blob/main/docs/tutorials/rootless_tutorial.md#using-volumes
I am attempting to run a laravel app on a local server in https mode in a Fedora 36 OS, but I am given this message
The stream or file "/var/www/compagnon-be/storage/logs/laravel.log"
could not be opened in append mode: Failed to open stream: Permission
denied The exception occurred while attempting to log
It seems to me that my permissions are correct
My DocumentRoot is /var/www/compagnon-be/public
I used these commands from /var/www
sudo chown -R $USER:apache compagnon-be
and
sudo chmod -R 775 compagnon-be
ls -l returns this (muser being my user)
[jaaf#localhost www]$ ls -l
total 12
drwxr-xr-x. 2 root root 4096 17 juin 13:13 cgi-bin
drwxrwxr-x. 14 muser apache 4096 2 déc. 06:32 compagnon-be
drwxr-xr-x. 4 root root 4096 1 déc. 06:52 html
[jaaf#localhost www]$
What is wrong ?
The trouble was coming from selinux.
I tried
sudo restorecon -R -v /var/www/compagnon-be
After that the message changed to
file_put_contents(/var/www/compagnon-be/storage/framework/views/dc2fe5ffc0c4db448244e2a441f79c65b3812ff5.php):
Failed to open stream: Permission denied
Then I decided to install setroubleshoot package in my Fedora distribution and launched sealert
Refreshing the page triggered an alert and sealert gave me the commands to use
It was:
Vous devez modifier l'étiquette sur (You must change label on) « /var/www/compagnon-be/storage/framework/views »
# semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/compagnon-be/storage/framework/views'
# restorecon -v '/var/www/compagnon-be/storage/framework/views'
How the gitlab-ci cache is working on docker runner?
What is /cache directory?
What is cache_dir?
Where and how files matching the "paths" in "cache" gitlab-ci.yml are stored?
Volume mounted to /cache directory is created automatically on gitlab-runner installation and managed by cache_dir setting
more about cache_dir:
https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section
https://gitlab.com/gitlab-org/gitlab-runner/blob/main/docs/executors/docker.md#the-builds-and-cache-storage
If you modify the /cache storage path, you also need to make sure to mark this
directory as persistent by defining it in volumes = ["/my/cache/"] under the
[runners.docker] section in config.toml.
TLDR
/cache dir is different from cache config in gitlab-ci.yml
/cache dir in job container is where the cached files are stored
files matching to cache config in gitlab-ci.yml are copied to /cache/$CI_PROJECT_NAMESPACE/$CI_PROJECT_NAME/<cache-key>-<cache-number> at the end of job
The "Clear Runner Caches" button in your project "Pipelines" page schedules TO NOT extract /cache/$CI_PROJECT_NAMESPACE/$CI_PROJECT_NAME/<cache-key>-<cache-number>/cache.zip to dir specified in cache config in gitlab-ci.yml (Instead of "removing content of /cache folder as I though at first)
P.S.
There is container named gitlab-runner-cache created on machine with gitlab-runner (https://gitlab.com/gitlab-org/gitlab-runner/blob/af343971874198a1923352107409583b78e8aa80/executors/docker/executor_docker.go#L382)
(Seems like) This container is used to create anonymous volume where /cache data is stored. After the anonymous volume is created this container is stopped.
The job containers (meaning container were your tests typically run) mounts this anonymous volume
Proofs
HAVING gitlab-ci.yml
image: srghma/docker-nixos-with-git-crypt
cache:
key: "test00000" # to reset cache - change this key OR clear cache in project settings page
paths:
- .mycache # gitlab allows only cache dirs that are relative to project root OR /cache (created automatically)
testtest:
script:
- nix-env -i tree
- tree --dirsfirst -L 4 /cache
- ls -al ./.mycache || true
- echo "test" > /cache/test
- mkdir -p ./.mycache
- echo "test" > ./.mycache/test
- tree --dirsfirst -L 4 /cache
- ls -al ./.mycache || true
Output:
on first run
Running with gitlab-runner 11.6.0 (f100a208)
on srghma_gitlab_runner 9b3980da
Using Docker executor with image srghma/docker-nixos-with-git-crypt ...
Pulling docker image srghma/docker-nixos-with-git-crypt ...
Using docker image sha256:ad3491aae178f629df713e0719750cc445b4881702b6b04b7cf325121f0032bf for srghma/docker-nixos-with-git-crypt ...
Running on runner-9b3980da-project-222-concurrent-0 via myrunner.com...
Fetching changes...
Removing .mycache/
HEAD is now at 675caa7 feat: cache update
From https://gitlab.com/srghma/myproject
675caa7..3d1e223 nix -> origin/nix
Checking out 3d1e2237 as nix...
Skipping Git submodules setup
Checking cache for test00000-11...
No URL provided, cache will be not downloaded from shared cache server. Instead a local version of cache will be extracted.
Successfully extracted cache
$ nix-env -i tree
installing 'tree-1.8.0'
these paths will be fetched (0.03 MiB download, 0.09 MiB unpacked):
/nix/store/dhfq0dsg9a0j5ai78bmh5qlrla8wvcxz-tree-1.8.0
copying path '/nix/store/dhfq0dsg9a0j5ai78bmh5qlrla8wvcxz-tree-1.8.0' from 'https://cache.nixos.org'...
building '/nix/store/dankqr2x4g5igc4w7lw9xqnn7lcy4f7a-user-environment.drv'...
created 233 symlinks in user environment
$ tree --dirsfirst -L 4 /cache
/cache
0 directories, 0 files
$ ls -al ./.mycache || true
$ echo "test" > /cache/test
ls: ./.mycache: No such file or directory
$ mkdir -p ./.mycache
$ echo "test" > ./.mycache/test
$ tree --dirsfirst -L 4 /cache
/cache
`-- test
0 directories, 1 file
$ ls -al ./.mycache || true
total 12
drwxr-xr-x 2 root root 4096 Feb 24 11:44 .
drwxrwxrwx 20 root root 4096 Feb 24 11:44 ..
-rw-r--r-- 1 root root 5 Feb 24 11:44 test
Creating cache test00000-11...
.mycache: found 2 matching files
No URL provided, cache will be not uploaded to shared cache server. Cache will be stored only locally.
Created cache
Job succeeded
on second run
Running with gitlab-runner 11.6.0 (f100a208)
on srghma_gitlab_runner 9b3980da
Using Docker executor with image srghma/docker-nixos-with-git-crypt ...
Pulling docker image srghma/docker-nixos-with-git-crypt ...
Using docker image sha256:ad3491aae178f629df713e0719750cc445b4881702b6b04b7cf325121f0032bf for srghma/docker-nixos-with-git-crypt ...
Running on runner-9b3980da-project-222-concurrent-0 via myrunner.com...
Fetching changes...
Removing .mycache/
HEAD is now at 3d1e223 feat: cache update
Checking out 3d1e2237 as nix...
Skipping Git submodules setup
Checking cache for test00000-11...
No URL provided, cache will be not downloaded from shared cache server. Instead a local version of cache will be extracted.
Successfully extracted cache
$ nix-env -i tree
installing 'tree-1.8.0'
these paths will be fetched (0.03 MiB download, 0.09 MiB unpacked):
/nix/store/dhfq0dsg9a0j5ai78bmh5qlrla8wvcxz-tree-1.8.0
copying path '/nix/store/dhfq0dsg9a0j5ai78bmh5qlrla8wvcxz-tree-1.8.0' from 'https://cache.nixos.org'...
building '/nix/store/dankqr2x4g5igc4w7lw9xqnn7lcy4f7a-user-environment.drv'...
created 233 symlinks in user environment
$ tree --dirsfirst -L 4 /cache
/cache
|-- srghma
| `-- myproject
| `-- test00000-11
| `-- cache.zip
`-- test
3 directories, 2 files
$ ls -al ./.mycache || true
total 12
drwxr-xr-x 2 root root 4096 Feb 24 11:44 .
drwxrwxrwx 20 root root 4096 Feb 24 11:44 ..
-rw-r--r-- 1 root root 5 Feb 24 11:44 test
$ echo "test" > /cache/test
$ mkdir -p ./.mycache
$ echo "test" > ./.mycache/test
$ tree --dirsfirst -L 4 /cache
/cache
|-- srghma
| `-- myproject
| `-- test00000-11
| `-- cache.zip
`-- test
3 directories, 2 files
$ ls -al ./.mycache || true
total 12
drwxr-xr-x 2 root root 4096 Feb 24 11:44 .
drwxrwxrwx 20 root root 4096 Feb 24 11:44 ..
-rw-r--r-- 1 root root 5 Feb 24 11:44 test
Creating cache test00000-11...
.mycache: found 2 matching files
No URL provided, cache will be not uploaded to shared cache server. Cache will be stored only locally.
Created cache
Job succeeded
after you clear cache by clicking on "Clear Runner Caches" in your project "Pipelines" page
Running with gitlab-runner 11.6.0 (f100a208)
on srghma_gitlab_runner 9b3980da
Using Docker executor with image srghma/docker-nixos-with-git-crypt ...
Pulling docker image srghma/docker-nixos-with-git-crypt ...
Using docker image sha256:ad3491aae178f629df713e0719750cc445b4881702b6b04b7cf325121f0032bf for srghma/docker-nixos-with-git-crypt ...
Running on runner-9b3980da-project-222-concurrent-0 via myrunner.com...
Fetching changes...
Removing .mycache/
HEAD is now at 3d1e223 feat: cache update
Checking out 3d1e2237 as nix...
Skipping Git submodules setup
Checking cache for test00000-12...
No URL provided, cache will be not downloaded from shared cache server. Instead a local version of cache will be extracted.
Successfully extracted cache
$ nix-env -i tree
installing 'tree-1.8.0'
these paths will be fetched (0.03 MiB download, 0.09 MiB unpacked):
/nix/store/dhfq0dsg9a0j5ai78bmh5qlrla8wvcxz-tree-1.8.0
copying path '/nix/store/dhfq0dsg9a0j5ai78bmh5qlrla8wvcxz-tree-1.8.0' from 'https://cache.nixos.org'...
building '/nix/store/dankqr2x4g5igc4w7lw9xqnn7lcy4f7a-user-environment.drv'...
created 233 symlinks in user environment
$ tree --dirsfirst -L 4 /cache
/cache
|-- srghma
| `-- myproject
| `-- test00000-11
| `-- cache.zip
`-- test
3 directories, 2 files
$ ls -al ./.mycache || true
ls: ./.mycache: No such file or directory
$ echo "test" > /cache/test
$ mkdir -p ./.mycache
$ echo "test" > ./.mycache/test
$ tree --dirsfirst -L 4 /cache
/cache
|-- srghma
| `-- myproject
| `-- test00000-11
| `-- cache.zip
`-- test
3 directories, 2 files
$ ls -al ./.mycache || true
total 12
drwxr-xr-x 2 root root 4096 Feb 24 11:45 .
drwxrwxrwx 20 root root 4096 Feb 24 11:45 ..
-rw-r--r-- 1 root root 5 Feb 24 11:45 test
Creating cache test00000-12...
.mycache: found 2 matching files
No URL provided, cache will be not uploaded to shared cache server. Cache will be stored only locally.
Created cache
Job succeeded
I've created a container, based off the centos:6.8 image using the following Dockerfile:
FROM centos:6.8
RUN adduser -m test
USER test
The image is then built using docker build:
docker build -t dockerdemo .
Then I start a container with:
docker run -ti dockerdemo bash
When I am inside the container, I appear to be able to write as the "test" user into the root directory of the container:
[test#9af9c4aeb990 /]$ ls -ld /
drwxr-xr-x 29 root root 4096 Oct 25 09:49 /
[test#9af9c4aeb990 /]$ id -a
uid=500(test) gid=500(test) groups=500(test)
[test#9af9c4aeb990 /]$ touch /test-file
[test#9af9c4aeb990 /]$ ls -l /test-file
-rw-rw-r-- 1 test test 0 Oct 25 09:49 /test-file
I am expecting to see Permission denied when I run the touch command.
If I alter the Dockerfile and remove the USER statement, and rebuild, then I can su to the "test" user inside the container and I get the behaviour I would expect:
[root#d16277f693d8 /]# su - test
[test#d16277f693d8 ~]$ id
uid=500(test) gid=500(test) groups=500(test)
[test#d16277f693d8 ~]$ ls -ld /
drwxr-xr-x 29 root root 4096 Oct 25 09:50 /
[test#d16277f693d8 ~]$ touch /test-file
touch: cannot touch `/test-file': Permission denied
Have I misunderstood how user permissions work inside containers?
Is there a way to produce my expected behaviour?
There was a vulnerability announced in 1.12.2 that your scenario matches. Release 1.12.3 just came out yesterday to fix this issue and CVE-2016-8867 was registered on the vulnerability. It's an internal container privilege escalation, so limited impact, but still worth the upgrade.
I'm using Docker to run an Apache instance. My docker file goes something like this:
FROM ubuntu
MAINTAINER your.face#gmail.com
RUN cat /etc/passwd
RUN cat /etc/group
RUN apt-get update && apt-get install -yq apache2 php5 libapache2-mod-php5 php5-mysql
RUN apt-get install -yq openssh-server
RUN mkdir /var/run/sshd
ENV APACHE_RUN_USER www-data
ENV APACHE_RUN_GROUP www-data
ENV APACHE_LOG_DIR /var/log/apache2
EXPOSE 80
ADD config/apache2/000-default.conf /etc/apache2/sites-available/000-default.conf
ADD config/php5/php.ini /etc/php5/apache2/php.ini
ADD config/start.sh /tmp/start.sh
ADD src /var/www
RUN chown -R root:www-data /var/www
RUN chmod u+rwx,g+rx,o+rx /var/www
RUN find /var/www -type d -exec chmod u+rwx,g+rx,o+rx {} +
RUN find /var/www -type f -exec chmod u+rw,g+rw,o+r {} +
#essentially: CMD ["/usr/sbin/apache2ctl", "-D", "FOREGROUND"]
CMD ["/tmp/start.sh"]
However, when I build the container and run it, I only ever get 403 errors.
Notice that I've specified that Apache should run as www-data in www-data group, and that /var/www has been recursively chownd to belong to root:www-data.
Also, all directories are searchable and readable, and all files are readable and writeable by the www-data group (well, according to ls -la and namei -m they are anyways).
How do I fix these permissions issues? I cant figure it out.
Actual error from the Apache error.log:
[Fri May 23 18:33:27.663087 2014] [core:error] [pid 14] (13)Permission denied: [client 11.11.11.11:61689] AH00035: access to /index.php denied (filesystem path '/var/www/index.php') because search permissions are missing on a component of the path
EDIT:
output of ls -laR /var/www at the end of the Dockerfile:
Step 21 : RUN ls -laR /var/www
---> Running in 74fd3609dfc8
/var/www:
total 1036
drwxr-xr-x 67 root www-data 4096 May 23 18:38 .
drwxr-xr-x 26 root root 4096 May 23 18:38 ..
-rw-rw-r-- 1 root www-data 28 May 23 12:22 .gitignore
-rw-rw-r-- 1 root www-data 501 May 23 12:22 .htaccess
-rw-rw-r-- 1 root www-data 7566 May 23 12:22 index.php
Output of namei -m /var/www/index.php at the end of the Dockerfile:
Step 22 : RUN namei -m /var/www/index.php
---> Running in 1203f0353090
f: /var/www/index.php
drwxr-xr-x /
drwxr-xr-x var
drwxr-xr-x www
-rw-rw-r-- index.php
EDIT2
After trying a whole bunch of things, including chmod -R 777 just to see if I could get anything to work, I tried putting the source files added from the Dockerfile into /var/www/html, the default location for Apache files to be served.
I matched the default file permissions exactly (I think), and it still isn't working. The default index.html that comes with Apache loads just fine, but the added src folder still have a 403 access denied error.
I changed the Dockerfile to ADD src /var/www/html/src and the permissions were set using:
RUN find /var/www/html -type d -exec chmod u+rwx,g+rx,o+rx {} +
RUN find /var/www/html -type f -exec chmod u+rw,g+r,o+r {} +
No luck. Below is some of the output of ls -laR on /var/www. Notice that the permissions for the html folder and index.html that come with an apache2 install match those of the added src folder:
Step 19 : RUN ls -laR /var/www/
---> Running in 0520950d0426
/var/www/:
total 12
drwxr-xr-x 6 root root 4096 May 23 19:23 .
drwxr-xr-x 24 root root 4096 May 23 19:23 ..
drwxr-xr-x 5 root root 4096 May 23 19:23 html
/var/www/html:
total 24
drwxr-xr-x 5 root root 4096 May 23 19:23 .
drwxr-xr-x 6 root root 4096 May 23 19:23 ..
-rw-r--r-- 1 root root 11510 May 23 18:28 index.html
drwxr-xr-x 47 root root 4096 May 23 19:23 src
/var/www/html/src:
total 1032
drwxr-xr-x 47 root root 4096 May 23 19:23 .
drwxr-xr-x 5 root root 4096 May 23 19:23 ..
-rw-r--r-- 1 root root 28 May 23 12:22 .gitignore
-rw-r--r-- 1 root root 501 May 23 12:22 .htaccess
-rw-r--r-- 1 root root 7566 May 23 12:22 index.php
Perhaps chmod doesn't work quite the way I thought it does??
EDIT3
A final bit of information. The Docker container is being built by buildbot, which I've been assuming runs as root. I haven't been able to reproduce this scenario without using buildbot to do the building.
Building everything via sudo docker build -t apache . type commands on my laptop works fine, but the problems arise when buildbot does it. No idea why :^/
I just ran into this after posting a similar question at Running app inside Docker as non-root user.
My guess is you can't chmod/ chown files that were added via the ADD command. – thom_nic Jun 19 at 14:14
Actually you can. You just need to issue a a RUN command after the ADD for the file location that will be INSIDE your container. For example
ADD extras/dockerstart.sh /usr/local/servicemix/bin/
RUN chmod 755 /usr/local/bin/dockerstart.sh
Hope that helps. It worked for me.
I encountered a similar issue; however my container was using VOLUME to map directories across the container.
Changing the permissions on the directory that maps to /var/www/html itself remedied the 403 Forbidden errors.
docker-host$ ls -ld /var/www/html
drwxr--r-- 53 me staff 1802 Mar 8 22:33 .
docker-host$ chmod a+x /var/www/html
docker-host$ ls -ld /var/www/html
drwxr-xr-x 53 me staff 1802 Mar 8 22:33 .
Note that chmod must be applied on the Docker host, not within the container. Executing it within the container effects no change to the directory.
docker-container$ chmod a+x /var/www/html
docker-container$ ls -ld /var/www/html
drwxr--r-- 53 me staff 1802 Mar 8 22:33 .