Php: Permission denied on creating /var/run/apache2/apache2.pid

Created on 11 Nov 2018  Â·  9Comments  Â·  Source: docker-library/php

Using the nextcloud:latest docker image, which is based on php:7.2-apache-stretch, I get these errors:

[Sun Nov 11 10:36:55.584958 2018] [core:error] [pid 1] (13)Permission denied: AH00099: could not create /var/run/apache2/apache2.pid
[Sun Nov 11 10:36:55.584972 2018] [core:error] [pid 1] AH00100: apache2: could not log pid to file /var/run/apache2/apache2.pid

The relevant docker compose is:

  nextcloud:
    image: nextcloud
    restart: always
    user: $UID:$GID
    sysctls:
      - net.ipv4.ip_unprivileged_port_start=0
    environment:
      - APACHE_RUN_USER=#$UID
      - APACHE_RUN_GROUP=#$GID

How can I run apache using a specified user?

Issue

All 9 comments

Why would you reply with RTFM and then close? Why not open a discussion?

I actually already read the linked instructions and, per my docker compose snippet posted earlier, have already used the features described there. I'm still seeing an issue. Please reopen.

Yeah my mistake, it's the second paragraph of that section where it says "For running the Apache variants as an arbitrary user, there are several choices:"

Using the environment variables APACHE_RUN_USER and APACHE_RUN_GROUP over Docker's --user. is required for the Apache variant as it seems the first bullet point is incorrect and Apache is unable to create its pid file according to its instructions

If your kernel is version 4.11 or newer, you can add --sysctl net.ipv4.ip_unprivileged_port_start=0 and then --user should work as it does for FPM.

$ docker run -dit --sysctl net.ipv4.ip_unprivileged_port_start=0 --user 1000:1000 -p 80:80 --name php php:7.2-apache-stretch
0dcc5bd13032c9d65f5ef2b3ac17abb1fa7cbadeaca8c43dc6cdd5d22b810695
$ docker logs php
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.2. Set the 'ServerName' directive globally to suppress this message
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.2. Set the 'ServerName' directive globally to suppress this message
[Mon Nov 12 17:51:44.470532 2018] [core:error] [pid 1] (13)Permission denied: AH00099: could not create /var/run/apache2/apache2.pid
[Mon Nov 12 17:51:44.470562 2018] [core:error] [pid 1] AH00100: apache2: could not log pid to file /var/run/apache2/apache2.pid

Using the environment variables works correctly

$ docker run --rm -dit --sysctl net.ipv4.ip_unprivileged_port_start=0 -e APACHE_RUN_USER=daemon -p 80:80 --name php -it php:7.2-apache-stretch
ce1fc1926440b2d16ca9d3ca402c86305ba7522e65ac2119790ac7c54c0a24e4
$ docker logs php
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.2. Set the 'ServerName' directive globally to suppress this message
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.2. Set the 'ServerName' directive globally to suppress this message
[Mon Nov 12 17:53:21.340028 2018] [mpm_prefork:notice] [pid 1] AH00163: Apache/2.4.25 (Debian) PHP/7.2.12 configured -- resuming normal operations
[Mon Nov 12 17:53:21.340088 2018] [core:notice] [pid 1] AH00094: Command line: 'apache2 -D FOREGROUND'

$ docker ps
CONTAINER ID        IMAGE                    COMMAND                  CREATED             STATUS              PORTS                                         NAMES
ce1fc1926440        php:7.2-apache-stretch   "docker-php-entrypoi…"   9 seconds ago       Up 7 seconds        0.0.0.0:80->80/tcp                            php

I'll see about correcting the documentation

So is the confusion that the environment variables are mutually exclusive to the --user option? In other words, the environment variables supercede the --user option? The only difference I see between my configuration and your working configuration is that you do not specify --user but I do.

Not sure how this was working previously, but it's definitely a bug! Filed https://github.com/docker-library/php/pull/745 which should fix it. :+1:

Thank you for the fix! How will I know when I've picked up the fix from the docker registry? I'm not familiar with your release process.

Once #745 is merged there needs to be a PR to the official source of truth for docker images repo. After that is merged the image is made available on the docker hub.

Somewhere in this process there are some local builds (and pushes) that are done by a member of this images maintainers (I think it's @yosifkit and @tianon that have a local env for this to do this for _/php).

Your best bet might be to check any new releases of the library php image for the anticipated chmod changes on the affected directories.

@tianon could this be related to https://github.com/moby/moby/pull/36587 (the "how did this work before" part)?

Looks like the PR from @tianon will finally address this. I am happy to test it when it is published to the docker hub, but not sure when that will be.

Was this page helpful?
0 / 5 - 0 ratings