Container fails to start due to missing config file

[Qwertie-]

Expected Behavior

Expect the container to start with default setup

Current Behavior

Container fails to start with error repeatedly logged
dokuwiki     | [01-Mar-2021 02:03:46] ERROR: failed to post process the configuration
dokuwiki     | [01-Mar-2021 02:03:46] ERROR: FPM initialization failed
dokuwiki     | nginx: [emerg] open() "/config/nginx/nginx.conf" failed (2: No such file or directory)
dokuwiki     | [01-Mar-2021 02:03:47] ERROR: failed to open error_log (/config/log/php/error.log): No such file or directory (2)

Steps to Reproduce

Start container with this docker compose

  dokuwiki:
    image: ghcr.io/linuxserver/dokuwiki
    container_name: dokuwiki
    environment:
      - PUID=1000
      - PGID=1000
    volumes:
      - /home/core/config/dokuwiki:/config
    restart: unless-stopped

/home/core/config/dokuwiki is just an empty dir. I'm guessing I need to add some nginx config but I'm not sure what.

Environment

OS: Fedora CoreOS CPU architecture: x86_64 How docker service was installed: It comes preinstalled with Fedora CoreOS $ docker --version Docker version 19.03.13, build 4484c46

[github-actions[bot]]

Thanks for opening your first issue here! Be sure to follow the bug or feature issue templates!

[aptalca]

post a full log

[Qwertie-]

Ah it looks like I had missed the important part in the scrollback

dokuwiki     | mkdir: cannot create directory ‘/config/nginx’: Permission denied
dokuwiki     | mkdir: cannot create directory ‘/config/www’: Permission denied
dokuwiki     | mkdir: cannot create directory ‘/config/log’: Permission denied
dokuwiki     | mkdir: cannot create directory ‘/config/keys’: Permission denied
dokuwiki     | mkdir: cannot create directory ‘/config/log’: Permission denied
dokuwiki     | mkdir: cannot create directory ‘/config/php’: Permission denied

The volume mount needed :Z added to the end to fix SELinux permissions

[Nindaleth]

I've just spent some time on this and didn't link the issue to SELinux initially - the container always worked first time, only after docker-compose down or docker container stop && docker container rm the next container always failed.

Could you add a note about this into the readme, please? Based on official Docker docs, perhaps using lower-case :z would be better (as I understand that the host machine is considered to be another "container" in that context). It can be simple, such as

If the machine runs SELinux, you need to append `:z` as the volume mount flag to prevent permission errors.

or so... alternatively I can send that in a PR if that's the better way to go.

[aptalca]

That is not specific to this image, it's a docker system compatibility with selinux and way beyond the scope of the readme (which assumes you have a fully functional docker setup)

[Nindaleth]

fully functional Docker setup

Sure, I absolutely agree that this is necessary. The thing is, how can an inexperienced user tell for sure? Installing Docker and then going through the post-install section's "non-root" part successfully would give the impression that after running the hello-world container as non-root, the environment is ready to run containers. Unfortunately Docker doesn't seem to provide a healthcheck container or additional check procedures.

During the initial steps, I could tell immediately that my older Docker version didn't support cgroupsv2 (also present in the OS), as no container would start at all and I got an easily googleable error; after installing a newer Docker version the problem was solved, now the containers start and run properly as Docker supports cgroupsv2 since 20.10.x. But this one isn't that simple to tell - I have several other non-:z volume-bound containers running and restartable without noticing any issues - in my limited experience I saw everything pointing to a single container (even though it's not at fault at all!).

I agree that the addition wouldn't be specific to a single image. I can see multiple linuxserver images note that When using volumes (-v flags), permissions issues can arise between the host OS and the container; is a SELinux mention not a reasonable fit in that context?