Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Correct way to mount data #46

Closed
Georacer opened this issue Sep 4, 2022 · 3 comments
Closed

Correct way to mount data #46

Georacer opened this issue Sep 4, 2022 · 3 comments

Comments

@Georacer
Copy link

Georacer commented Sep 4, 2022

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"
  1. Set PUID and PGID=1000 in .env.
  2. 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 version (type docker --version) : Docker version 20.10.17, build 100c701

  • Docker compose version if applicable (type docker-compose --version) : N/A, now using docker compose instead of docker-compose

  • Platform (Debian 9, Ubuntu 18.04, ...) : Ubuntu 22.04

  • System info (type uname -a) : Linux george-ThinkPad-E14-Gen-2 5.15.0-46-generic Add support for php81-dom #49~20.04.1-Ubuntu SMP Thu Aug 4 19:15:44 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

  • Include all necessary configuration files : docker-compose.yml, .env, ...

Docker info

> Output of command `docker info`

Logs

> Container logs (set LOG_LEVEL to debug if applicable)
@Georacer
Copy link
Author

Georacer commented Sep 4, 2022

Upon further googling, I'm pretty sure my situations is similar to this: docker/desktop-linux#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
Copy link
Author

Georacer commented Sep 4, 2022

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
Copy link
Author

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.

Repository owner locked and limited conversation to collaborators May 4, 2023
@crazy-max crazy-max converted this issue into discussion #55 May 4, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant