alpine fpm image does not support running as a different user other than www-data

This has been mentioned (and evidenced) in #70 and #14, and the presence of hardcoded usernames already affected the apache images (see docker-library/wordpress#249).

Multiple longstanding issues exist, including some in the doc repo: docker-library/docs#1215 (comment). It seems the apache images are working now with this, although the fpm ones are not. This is unfortunate as the memory footprint of fpm is far lower, it is easier to isolate vs mod_php, and it does not create a en entire copy of the PHP interpreter and libraries in memory for every web server process.

I find it puzzling that the fpm images did not benefit from this first, as the ease of implementing this feature for them should be slightly more simple than it was for the apache counterparts.

@rcdailey has contributed quite a bit for this, AFAIK, but I don't see anything merged or working in the main repos.

See also nextcloud/docker#458 (comment)

[rcdailey]

The downside to fpm is that you have to expose paths inside the Nextcloud container to the container for the reverse proxy. I personally found the setup for that was pretty complicated and ugly. And honestly the performance is really good without it.

…

On Sun, Aug 18, 2019, 8:19 PM v ***@***.***> wrote: This has been mentioned (and evidenced) in #70 <#70> and #14 <#14>, and the presence of hardcoded usernames already affected the apache images (see docker-library/wordpress#249 <docker-library/wordpress#249>). Multiple longstanding issues exist, including some in the doc repo: docker-library/docs#1215 (comment) <docker-library/docs#1215 (comment)>. It seems the apache images are working now with this, although the fpm ones are not. This is unfortunate as the memory footprint of fpm is far lower, it is easier to isolate vs mod_php, and it does not create a en entire copy of the PHP interpreter and libraries *in memory* for every web server process. I find it puzzling that the fpm images did not benefit from this first, as the ease of implementing this feature for them should be slightly more simple than it was for the apache counterparts. @rcdailey <https://github.com/rcdailey> has contributed quite a bit for this, AFAIK, but I don't see anything merged or working in the main repos. See also nextcloud/docker#458 (comment) <nextcloud/docker#458 (comment)> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#876?email_source=notifications&email_token=AANPU5WKW6WKEBC2PN2QPMTQFHYL5A5CNFSM4IMU5WXKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HF3W2HQ>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANPU5RNHTR7NG7UF3FQBH3QFHYL5ANCNFSM4IMU5WXA> .

  nextcloud-app:
    image: nextcloud:16-apache
    restart: unless-stopped
    user: $NEXTCLOUD_WEB_UID:$NEXTCLOUD_WEB_GID
    sysctls:
      - net.ipv4.ip_unprivileged_port_start=0
    environment:
      - MYSQL_HOST=nextcloud-db
      - APACHE_RUN_USER=#$NEXTCLOUD_WEB_UID
      - APACHE_RUN_GROUP=#$NEXTCLOUD_WEB_GID
      - NEXTCLOUD_DATA_DIR=/nextcloud-data
      - REDIS_HOST=nextcloud-redis
      - NEXTCLOUD_ADMIN_USER=admin
      - NEXTCLOUD_ADMIN_PASSWORD=(...)
    env_file:
      - db.env
    volumes:
      - nextcloud-web:/var/www/html
      - nextcloud-data:/nextcloud-data
    ports:
      - 127.0.0.1:8082:80

No dice. Not sure fpm, it shouldn't be the case unless you chroot the fpm pool process.
Definitely not having a lucky strike with the docker composer files for nextcloud.

Also seeing this:

nextcloud-app_1    | Configuring Redis as session handler
nextcloud-app_1    | /entrypoint.sh: 26: /entrypoint.sh: cannot create /usr/local/etc/php/conf.d/redis-session.ini: Permission denied
nextcloud-app_1    | Initializing nextcloud 16.0.4.1 ...
nextcloud-db_1     | Initializing database

[wglambert]

the presence of hardcoded usernames already affected the apache images

The image doesn't have any hardcoded username, running Apache as an arbitrary user works fine

$ docker run -d --name apache --sysctl net.ipv4.ip_unprivileged_port_start=0 --user 1000:1000 -e APACHE_RUN_USER=#1000 php:apache
0a355e9479346a0e5a3ef6738091960f5f09f94e4819565032bf707252ec6e41

$ docker exec apache ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
1000         1  4.1  0.2  82920 24792 ?        Ss   17:21   0:00 apache2 -DFOREGROUND
1000        16  0.0  0.0  82944  5004 ?        S    17:21   0:00 apache2 -DFOREGROUND
1000        17  0.0  0.0  82944  5004 ?        S    17:21   0:00 apache2 -DFOREGROUND
1000        18  0.0  0.0  82944  5004 ?        S    17:21   0:00 apache2 -DFOREGROUND
1000        19  0.0  0.0  82944  5004 ?        S    17:21   0:00 apache2 -DFOREGROUND
1000        20  0.0  0.0  82944  5004 ?        S    17:21   0:00 apache2 -DFOREGROUND
1000        21  0.0  0.0   7640  2756 ?        Rs   17:21   0:00 ps aux

Your issue is with an image we don't maintain ourselves, but php:fpm-alpine is able to run as an arbitrary user

$ docker run -d --rm --user 1000:1000 --name php php:fpm-alpine
d16815859f8d036cab4af0a7e5ad416fe319b7200c2467e705e248b04379319e

$ docker exec php ps aux
PID   USER     TIME  COMMAND
    1 1000      0:00 php-fpm: master process (/usr/local/etc/php-fpm.conf)
    6 1000      0:00 php-fpm: pool www
    7 1000      0:00 php-fpm: pool www
    8 1000      0:00 ps aux

[wglambert]

Your issue is a duplicate of nextcloud/docker#763

/usr/local/etc/php/conf.d/redis-session.ini can not be written when using a non-root image, because the folder is owned by root and the default www-data user does not have write permission.

[yosifkit]

Closing since this is an issue in the nextcloud image and not php:fpm-alpine.