Volumes
Managed Volume Permissions
Using a Volume
When creating a a volume in the Dockerfile
by it default it will have root
user permissions as seen below:
Dockerfile
ENV CONFLUENCE_TOMCAT_LOG_DIR "/opt/atlassian/confluence/logs"
VOLUME ["${CONFLUENCE_TOMCAT_LOG_DIR}"]
Inspect running container
Verify the volume has been created:
$ docker inspect confluence
...
"Volumes": {
"/opt/atlassian/confluence/logs": {},
"/var/atlassian/application-data/confluence": {}
},
...
Permissions are root
:
$ ls -la /opt/atlassian/confluence
...
drwxr-x---. 2 root root 251 Feb 28 01:10 logs
...
Set the Permission for the Volume
If we instead the set the permissions within the Dockerfile
follows:
# Extract the installation directory and set the permission for the log directory
RUN mkdir -p ${CONFLUENCE_INSTALL_DIR} \
&& curl -L --silent ${DOWNLOAD_URL} | tar -xz --strip-components=1 -C "$CONFLUENCE_INSTALL_DIR" \
&& chown -R ${RUN_USER}:${RUN_GROUP} ${CONFLUENCE_INSTALL_DIR}/ \
&& chown -R ${RUN_USER}:${RUN_GROUP} ${CONFLUENCE_TOMCAT_LOG_DIR}/ \
VOLUME ["${CONFLUENCE_TOMCAT_LOG_DIR}"]
NOTE:
We deliberately put the VOLUME
instruction after the chown
operation because any modifications after the VOLUME
instruction in a Dockerfile
is not persisted. This is because we want the chown
command to run on the image's filesystem but instead it will run it in the volume of a temporary container. By adding the VOLUME
instruction as the end, docker will copy the files into the volume and set the right permissions.
$ $ ls -la /opt/atlassian/confluence
...
drwxr-x---. 2 daemon daemon 251 Feb 28 01:20 logs
...
Host Bind Volume Mount
If we now do a host volume mount where /tmp/logs
is not owned by the application user:
$ sudo docker run -v /tmp/logs:/opt/atlassian/confluence/logs --name="confluence" -d -p 8090:8090 -p 8091:8091 hniyaz/confluence
We will once again run into permission issues:
$ ls -la /opt/atlassian/confluence
...
drwxr-x---. 2 root root 251 Feb 28 01:10 logs
...
To get around this you will need to set the permissions on /tmp/logs
on the host to allow the application user to have the correct access.
Portability
Having to set the permissions on the host prior to starting the container makes it less portable as it relies on the deployment system to ensure the permissions are already set.
To enable container portability and limit dependencies the solution is to set the permissions via the entrypoint
script. This means you will need to start the container as root
and then drop privileges within the entrypoint
script.