search

crazy-max / docker-dokuwiki

DokuWiki Docker image
MIT License
43 stars 19 forks source link

Correct way to mount data #46

Closed Georacer closed 1 year ago

Georacer commented 2 years ago

Behaviour

Steps to reproduce this issue

I already have an existing installation of dokuwiki, local on my host. I want to use the same files to mount them on the container and serve them from there. These files are owned by my personal user with UID/GID=1000

  1. Edit the docker-compose.yml file to mount the volume: 
    volumes:
  - "<absoulte_path>/dokuwiki/data:/data"
  2. Set PUID and PGID=1000 in .env.
  3. docker compose up -d --build

Expected behaviour

I expected the wiki to be immediately hosted in localhost:8000.

Actual behaviour

The first weird thing is that the image looks for the /data/conf/local.protected.php to decide if this is a first installation. My installation didn't have this file, so I created it manually. Still, when I start the container, line 69 in https://github.com/crazy-max/docker-dokuwiki/blob/master/rootfs/etc/cont-init.d/03-config.sh#L69 looks for /data/data to decide if the data folder has been initialized. Of course, this doesn't exist, because I mounted my dokuwiki/data folder, not dokuwiki. Fair enough, I change my `docker-compose.yml into

volumes:
- "<absoulte_path>/dokuwiki:/data"

But now I get 

Copying global config...
cp: can't create '/data/conf/mediameta.php': Permission denied
cp: can't create '/data/conf/entities.conf': Permission denied
cp: can't create '/data/conf/.htaccess': Permission denied
cp: can't create '/data/conf/scheme.conf': Permission denied
cp: can't create '/data/conf/users.auth.php.dist': Permission denied
cp: can't create '/data/conf/wordblock.conf': Permission denied
cp: can't create '/data/conf/acronyms.conf': Permission denied
cp: can't create '/data/conf/smileys.conf': Permission denied
cp: can't create '/data/conf/mime.conf': Permission denied
cp: can't create '/data/conf/license.php': Permission denied
cp: can't create '/data/conf/acl.auth.php.dist': Permission denied
cp: can't create '/data/conf/local.php.dist': Permission denied
cp: can't create '/data/conf/plugins.php': Permission denied
cp: can't create '/data/conf/manifest.json': Permission denied
cp: can't create '/data/conf/plugins.required.php': Permission denied
cp: can't create '/data/conf/dokuwiki.php': Permission denied
cp: can't create '/data/conf/mysql.conf.php.example': Permission denied
cp: can't create '/data/conf/interwiki.conf': Permission denied

Upon inspecting the mounted folder in my host, I see that both /data/plugins and /data/tpl folders are owned by a user named "100999", so something is definitely wrong, but I can't put my finger on it.

Any pointers, especially in the correct volume mount incantation? Thanks in advance!

Configuration

Docker info

> Output of command `docker info`

Logs

> Container logs (set LOG_LEVEL to debug if applicable)
Georacer commented 2 years ago

Upon further googling, I'm pretty sure my situations is similar to this: https://github.com/docker/desktop-linux/issues/31 I've installed Docker Desktop in my machine, even though I still use the command line to summon the compose scripts.

Your image (and many others) read the desired user and group ID as an environment variable and create a new container user based on that. But docker remaps that UID onto 100999 and the files belonging to the root of the container actually have my user's UID.

Which totally breaks how the image is set up to work. I'm not sure how this could be fixed, because a lot of functionality in the container is not meant to be executed as root.

Georacer commented 2 years ago

Based on the above information, I think an approach would be to:

  1. Create a group on the host machine with the GID=100999, the one created by docker, with the hope that it will stay constant.
  2. chown the entire volume path on the host to the 100999 user.
  3. chmod -R g+w the entire volume path, in case my host user wants to edit the files.

I my existing plugins still don't load after doing the above, but I think this is due to logic of your image, which replaces some folders with the dokuwiki installation upon building.

Georacer commented 1 year ago

I have now opted for a different approach: I create a named volume and mount that into the container. When I want to back up the data, I tar the whole container file tree. I can then restore it with something like: docker run --rm -v dokuwiki:/data -v $(pwd):/backup ubuntu bash -c "cd /data && tar --same-owner -xvpf /backup/backup.tar --strip 1

I consider this closed by now.