Depending on the host machine, the daemon's docker container might fail to create or to access the datadir with error permission denied.
The real problem is the user associated with the running container: within the Dockerfile a new root user is created, while the current user of the host machine should be used to prevent troubles with permissions.
Something like the following snippet should be added to the Dockerfile in order to make the user of the container the same as the host machine:
ARG USER_ID
ARG GROUP_ID
RUN if [ ${USER_ID:-0} -ne 0 ] && [ ${GROUP_ID:-0} -ne 0 ]; then \
userdel -f user &&\
if getent group user ; then groupdel user; fi &&\
groupadd -g ${GROUP_ID} user &&\
useradd -l -u ${USER_ID} -g user user &&\
install -d -m 0755 -o user -g user /home/user &&\
chown --changes --silent --no-dereference --recursive \
--from=0:0 ${USER_ID}:${GROUP_ID} \
/home/user \
;fi
USER user
This makes the container recreating the user user with host's permissions instead of root's ones only if the args USER_ID and GROUP_ID are specified when running the container. Otherwise, the entire process is skipped and the container works exactly like it's currently doing.
Depending on the host machine, the daemon's docker container might fail to create or to access the datadir with error
permission denied
.The real problem is the user associated with the running container: within the Dockerfile a new root user is created, while the current user of the host machine should be used to prevent troubles with permissions.
Something like the following snippet should be added to the Dockerfile in order to make the user of the container the same as the host machine:
This makes the container recreating the
user
user with host's permissions instead of root's ones only if the args USER_ID and GROUP_ID are specified when running the container. Otherwise, the entire process is skipped and the container works exactly like it's currently doing.