💪 Big Update

So here is a recap of the problem. It all comes down to root is required to run on privileged ports (80 + 443). We then drop to www-data after, which then causes a mess because any Docker CMD passed will default to root (not www-data) -- causing the error on this thread.

🦄 Proposed Solution

• I'm thinking of defaulting the fpm-apache and fpm-nginx images to be UNPRIVILEGED by default
• This will dramatically improve container security
• This will also reduce the complexities and required workarounds with su, sudo, etc

⚠️ Breaking change

👉 What would be required to fix

• By default, our NGINX and Apache images would listen on 8080 and 8443
• If you want port 80 + 443 on your host to go directly to the container, you would need to configure -p 80:8080 -p 443:8443

🗣️ Related discussions

• https://twitter.com/tobias_petry/status/1778816006409850997
• https://twitter.com/jaydrogers/status/1778823124789637216

Would love to hear everyone's thoughts 😃

from docker-php.

👉 Important Update

Hey all,

I just wanted to give you another update that I confirmed I have a working and stable solution with Spin.

I feel this is the best balance that I know of "The Docker Way" and how PHP works.

In short, the best way so solve this is use a build argument to change the user ID:

# Learn more about the Server Side Up PHP Docker Images at:
# https://serversideup.net/open-source/docker-php/

FROM serversideup/php:beta-8.3-fpm-nginx as base

FROM base as development

# Fix permission issues in development by setting the "www-data"
# user to the same user and group that is running docker.
ARG USER_ID
ARG GROUP_ID
RUN usermod -u $USER_ID www-data && \
    groupmod -g $GROUP_ID www-data

FROM base as deploy
COPY --chown=www-data:www-data . /var/www/html

You can do this in Docker Compose yourself if you wanted to.

version: '3.8'
services:

  php:
    build:
      target: development
      args:
        USER_ID: ${SPIN_USER_ID}
        GROUP_ID: ${SPIN_GROUP_ID}
    volumes:
      - .:/var/www/html/
    networks:
      - development

How this works

The above examples will change the www-data user when the build target is set to development.

In Spin, I automate ALL of this for you:

1. I grab the users user id and group id
2. A spin up will automatically grab the development build target
3. The www-data user id will be changed to match the user id of the running user

👉 All of this above prevents any PHP commands from running as a differing user ID

Best of all, I got this to work on macOS, Linux, and Windows (with WSL2). 🥳

Next Steps

Stay tuned as I will likely create content around this issue. This is one of those "gotchas" of using Docker + PHP in a production use case.

I will post on here once I have more documentation/videos ready on this 👍

from docker-php.

Right, splitting the command is not needed. At the end I've cleared all my docker images and containers and now this is the full, working code, no errors related to laravel.log nor cache creation, if it may help someone else too.

FROM serversideup/php:8.2-fpm-nginx as base

ENV AUTORUN_LARAVEL_MIGRATION=true
ENV SSL_MODE=off
ENV APP_ENV=production

FROM base as production

COPY --chown=$PUID:$PGID . .

RUN composer install --no-cache --no-dev --no-scripts --no-autoloader --ansi --no-interaction \
    && composer dump-autoload -o

I had to create a separate Dockerfile because I added (not pasted here) some tweaks to opcache, more extensions and so on. Thank you for the support and the image :)

from docker-php.

👉 Just a note

If you're running this locally, the owner and group IDs will differ based on the host machine.

If you're using a Linux host to run the docker container

• You'll probably get WYSIWYG (meaning a container running as the default 9999 will create the file as 9999 on the host)

If you're using a Windows or macOS host to run the container -- it gets complicated

• Since Docker is not native to these operating systems, Docker Desktop creates a network file share to mount the files to the container, changing the UID & GIDs

Just another level of complexity I am trying to work through 🙃

from docker-php.

I'll have an update for you guys soon on this in the V3 beta.

@tonysm's comment is heading in the right direction -- but it can have negative effects depending on what variation you're using.

Unfortunately a lot of this comes down to how Docker & PHP work, so I will be providing improved documentation on how to address permission issues.

I have an idea with Spin on how to make this really easy and automated, but I will need more time to explore this solution.

from docker-php.

Till there is a solid fix, I would just suggest to add the following environment variables, to let the image run on a different PUID & PGID.

docker-compose example:

environment:
      PUID: 1000
      PGID: 1000

from docker-php.

Can everyone on this thread post their host operating system? I assume it's all Linux?

Another Ubuntu 22.04 LTS here.

from docker-php.

There's only one answer and the answer is YES

from docker-php.

Hey @tsterker,

Thanks for checking in!

Regarding where the issue stands now

The root cause of his issue is a user experience issue -- it's not the users fault either.

Some background:

• PHP-FPM needs root to start its master process, but that's unsafe to run a PHP app as root all the time
• We add webuser to bring those privileges down to a non-privileged user

Where the problem stems:

• When a user runs "composer install" (for example, docker run -v $(pwd):/var/ww/html serversideup/php:8.2-fpm-nginx composer install) this will execute the command as root

The user would need to know to switch to webuser first, then execute the command (which is a poor user experience). The above command usually creates a "domino effect" error where the Laravel log gets created as root then the webserver runs into a second error, but the web user is trying to write to the log as webuser (thus throwing the permission denied error).

Regarding the CI + DIND

Is this related to building docker images? In this case, maybe kaniko could be an option to build images without privileged mode?

I want the images to assume this is compatible with any system and I don't want any dependencies on other libraries.

Moving forward

Let me take some time to document the issue better and see if I can post an issue on the S6 Overlay repo. They've been really helpful in the past, but I want to make sure I have the issue fully documented so I don't waste any of their time.

I'll keep you posted!

from docker-php.

Just adding a note for myself...

S6 Overlay has some changes that were released on May 4th. I might want to explore these changes since they talk specifically about the USER directive: https://github.com/just-containers/s6-overlay#notes

from docker-php.

Which is interesting because I expected the user and group ids to be 9999:9999.

For additional context, I tried to run the project changing the 9999 user and group ids to 1000 (the default values) and the permission denied error disappeared. Briefly, I replaced 9999 with 1000 in:

• docker-php/src/cli/Dockerfile

  Line 30 in 290e14f

  PGID=9999

• docker-php/src/cli/etc/s6-overlay/scripts/runas-user

  Line 4 in 290e14f

  PGID=${PGID:-9999}

• docker-php/docs/content/docs/6.reference/1.environment-variable-specification.md

  Line 15 in 290e14f

  `PUID`<br />*Default: 9999*|User ID the webserver and PHP should run as.|all

Actually, if I now run a ls -la command of the webroot, now I get:

127.0.0.1 - - [10/Aug/2023:16:22:56 +0000] "GET /ping HTTP/1.1" 301 162 "-" "curl/7.81.0"
total 412
drwxrwxr-x 15 webuser webgroup   4096 Aug 10 15:26 .
drwxr-xr-x  1 root    root       4096 Aug 10 16:10 ..
-rw-rw-r--  1 webuser webgroup    258 Jun 30 15:18 .editorconfig
-rw-rw-r--  1 webuser webgroup   1197 Aug 10 15:07 .env
-rw-rw-r--  1 webuser webgroup   1099 Aug 10 15:07 .env.example
drwxrwxr-x  7 webuser webgroup   4096 Aug 10 14:52 .git
-rw-rw-r--  1 webuser webgroup    186 Jun 30 15:18 .gitattributes
-rw-rw-r--  1 webuser webgroup    255 Aug 10 14:38 .gitignore
-rw-rw-r--  1 webuser webgroup   4158 Jun 30 15:18 README.md
drwxrwxr-x  3 webuser      998   4096 Aug 10 15:12 _volumes
drwxrwxr-x  7 webuser webgroup   4096 Jun 30 15:18 app
-rwxr-xr-x  1 webuser webgroup   1686 Jun 30 15:18 artisan
drwxrwxr-x  3 webuser webgroup   4096 Jun 30 15:18 bootstrap
-rw-rw-r--  1 webuser webgroup   1919 Aug 10 14:32 composer.json
-rw-rw-r--  1 webuser webgroup 294977 Aug 10 14:32 composer.lock
drwxrwxr-x  2 webuser webgroup   4096 Jun 30 15:18 config
drwxrwxr-x  5 webuser webgroup   4096 Jun 30 15:18 database
drwxrwxr-x  3 webuser      998   4096 Aug 10 15:53 docker
-rw-rw-r--  1 webuser webgroup   1080 Aug 10 15:14 docker-compose.dev.yml
-rw-rw-r--  1 webuser webgroup    212 Aug 10 16:17 docker-compose.yml
-rw-rw-r--  1 webuser webgroup    248 Jun 30 15:18 package.json
-rw-rw-r--  1 webuser webgroup   1084 Jun 30 15:18 phpunit.xml
drwxrwxr-x  2 webuser webgroup   4096 Aug 10 16:17 public
drwxrwxr-x  5 webuser webgroup   4096 Jun 30 15:18 resources
drwxrwxr-x  2 webuser webgroup   4096 Jun 30 15:18 routes
drwxrwxr-x  5 webuser webgroup   4096 Jun 30 15:18 storage
drwxrwxr-x  4 webuser webgroup   4096 Jun 30 15:18 tests
drwxrwxr-x 40 webuser webgroup   4096 Aug 10 14:32 vendor
-rw-rw-r--  1 webuser webgroup    263 Jun 30 15:18 vite.config.js

from docker-php.

Quick Question

Can everyone on this thread post their host operating system? I assume it's all Linux?

I am working on resolving this issue. I finally have a Linux development machine to do some testing and reproduction with this issue to finally get it resolved.

Ubuntu 22.04.3 LTS

from docker-php.

Experiencing the issue on Ubuntu 22.04 LTS, fresh install.

For what it's worth; I'm not seeing this problem with Laravel Sail, maybe we can find some inspiration there?

from docker-php.

Ubuntu 22.04. This error will occur in mounted path like

volumes:
  - ./storage:/var/www/html/storage

as well in docker volumes

volumes:
  - storage:/var/www/html/storage

from docker-php.

I have a gut feeling on the problem and the solution for Linux hosts is a little trickier compared to macOS & Windows.

I have some theories and I will revisit this soon. I will keep everyone posted 👍

from docker-php.

I think I have an update on how to fix this. Unfortunately this will require a lot of refactoring.

Keep an eye on this PR: #205

Any feedback, please let me know 👍

More to come soon 🚀

from docker-php.

@xaimes I'm using it on Linux for local dev, but I had to set the PUID and PGID both to 1000 (my host machine's user ID) for it to work. For instance, this is my local docker-compose.yml:

services:
    laravel.test:
        image: serversideup/php:8.2-fpm-nginx
        extra_hosts:
            - 'host.docker.internal:host-gateway'
        ports:
            - '${APP_PORT:-80}:80'
        environment:
            LARAVEL_SAIL: 1
            SSL_MODE: 'off'
            PUID: '${UID:-1000}'
            PGID: '${GID:-1000}'
        volumes:
            - '.:/var/www/html'
        networks:
            - sail
        depends_on:
            - mysql
// ...

from docker-php.

I like this way and is exactly the way i'm doing right now. Using the env var for id with 1000 as default

from docker-php.

⚡️ New Feature Added

Hey all,

I just wanted to explain my latest commit: 2115656

What's new

I created a docker-php-serversideup-set-id command that allows you to set the permissions easily.

Usage:

docker-php-serversideup-set-id [username] [uid] [gid]

What this does

This takes the username you want to change the UID and GID for. It also checks to make sure other users in the container are not taken. If they are, the script moves them to a new id (hopefully that's safe 😅).

Why this was created

The intention of this script was to make it easy for a sysadmin to work with a decentralized workforce with many different types of machines and configurations.

It allows a sysadmin to set these files to fix the permission issues when developers are working with their files:

Dockerfile:

# Learn more about the Server Side Up PHP Docker Images at:
# https://serversideup.net/open-source/docker-php/

FROM serversideup/php:beta-8.3.0-fpm-nginx-bookworm as base

# Fix permission issues in development by setting the "www-data"
# user to the same user and group that is running docker.
FROM base as development
ARG USER_ID
ARG GROUP_ID
RUN docker-php-serversideup-set-id www-data ${USER_ID} ${GROUP_ID}

FROM base as deploy
COPY --chown=www-data:www-data . /var/www/html

docker-compose.yml:

version: '3.8'
services:

  php:
    build:
      target: development
      args:
        USER_ID: ${SPIN_USER_ID}
        GROUP_ID: ${SPIN_GROUP_ID}
    volumes:
      - .:/var/www/html/

Long story short

This wasn't really a bug with the Docker images, this was more of a user experience thing due to how PHP, Docker, and File Permissions work.

I created this feature and will provide templates to minimize confusion.

Next Steps

Let me know if you like this solution and I can close this issue.

Thanks for all your feedback to help get this resolved!

from docker-php.

this error also happened to me when i try to mount volume in kubernetes..

but if i not mount volume, it can start the pod..

@syamsoul: Try the beta and consider using a different variation than fpm-nginx (like unit): #254

from docker-php.

Works for me, would like to see it implemented

from docker-php.

I am re-opening this issue.

This is related to the attempted fix implemented in #180, suggested by @tsterker.

Reason for re-open

• I am experiencing permission issues in GitLab CI causing builds to fail

More details on the failure

1. GitLab CI + DIND (Docker-in-docker) uses root and the UID of 0. With the commands using UID 9999 by default, the CI machine cannot create a vendor directory on the first step of composer install

Ways to test your own apps

• Use the beta images on your app and see if you get the same results (https://serversideup.net/open-source/docker-php/docs/getting-started/contributing#beta-images)

Next steps

I am going to continue to troubleshoot and may possibly revert #180 if I cannot get this to work well.

from docker-php.

Adding my error message in here too for future reference

from docker-php.

Wanted to add a few things on this issue.
I copied all the project files with the proper user ownership like this:

COPY --chown=$PUID:$PGID ./composer.json ./composer.lock ./
RUN composer install --no-cache --no-dev --no-scripts --no-autoloader --ansi --no-interaction

COPY --chown=$PUID:$PGID . .
RUN composer dump-autoload -o

Now the issue is that it can't create cache files:

Unable to create lockable file: /var/www/html/storage/framework/cache/data/
fa/f2/faf26108316c685830630fa2070ff0a7b212a06a. Please ensure you have perm
ission to create files in this location.

I've tried giving to the whole storage folder all the permissions and ownership to both $PUID:$PGID or www-data:www-data, but no luck so far. Also with the beta I got no luck. What's the user running the webserver?

from docker-php.

Thanks for chiming in. The user running PHP is webuser, so you might need to do a su before running your composer commands.

Also -- I am not sure why you would need two copy commands in there. Also, the default web root is /var/www/html. If you're running your build within the Docker build process, then it would look something like this:

COPY --chown=$PUID:$PGID . /var/www/html
RUN su webuser && \
    composer install --no-cache --no-dev --no-scripts --no-autoloader --ansi --no-interaction && \
    composer dump-autoload -o

from docker-php.

@jaydrogers I'm currently trying to follow up on this topic and understand the issue mentioned above and how #180 could be the cause for this.

ℹ️ Is there an example that works with the current setup and breaks with #180?

e.g. you mention a GitLab CI + DIND setup above.

GitLab CI + DIND (Docker-in-docker) uses root and the UID of 0. With the commands using UID 9999 by default, the CI machine cannot create a vendor directory on the first step of composer install

Is this related to building docker images? In this case, maybe kaniko could be an option to build images without privileged mode?

That said, if there is a general compatibility issue with the ubiquitous DIND it's still a problem that would need solving.

from docker-php.

Just adding a note, #180 has been reverted.

New approach

• I am going to explore if the USER directive in v3.1.5.0 of S6 Overlay is a better approach

from docker-php.

I'm having the same issue here. Just for context, if I check the owner of the files using a disposable container by running spin run php ls -la, I get a list of files owned by 1000:1000:

127.0.0.1 - - [10/Aug/2023:15:45:19 +0000] "GET /ping HTTP/1.1" 301 162 "-" "curl/7.81.0"
total 412
drwxrwxr-x 15 1000 1000   4096 Aug 10 15:26 .
drwxr-xr-x  1 root root   4096 Aug  8 08:16 ..
-rw-rw-r--  1 1000 1000    258 Jun 30 15:18 .editorconfig
-rw-rw-r--  1 1000 1000   1197 Aug 10 15:07 .env
-rw-rw-r--  1 1000 1000   1099 Aug 10 15:07 .env.example
drwxrwxr-x  7 1000 1000   4096 Aug 10 14:52 .git
-rw-rw-r--  1 1000 1000    186 Jun 30 15:18 .gitattributes
-rw-rw-r--  1 1000 1000    255 Aug 10 14:38 .gitignore
-rw-rw-r--  1 1000 1000   4158 Jun 30 15:18 README.md
drwxrwxr-x  3 1000  998   4096 Aug 10 15:12 _volumes
drwxrwxr-x  7 1000 1000   4096 Jun 30 15:18 app
-rwxr-xr-x  1 1000 1000   1686 Jun 30 15:18 artisan
drwxrwxr-x  3 1000 1000   4096 Jun 30 15:18 bootstrap
-rw-rw-r--  1 1000 1000   1919 Aug 10 14:32 composer.json
-rw-rw-r--  1 1000 1000 294977 Aug 10 14:32 composer.lock
drwxrwxr-x  2 1000 1000   4096 Jun 30 15:18 config
drwxrwxr-x  5 1000 1000   4096 Jun 30 15:18 database
drwxrwxr-x  2 1000  998   4096 Aug 10 15:27 docker
-rw-rw-r--  1 1000 1000   1080 Aug 10 15:14 docker-compose.dev.yml
-rw-rw-r--  1 1000 1000    279 Aug 10 15:30 docker-compose.yml
-rw-rw-r--  1 1000 1000    248 Jun 30 15:18 package.json
-rw-rw-r--  1 1000 1000   1084 Jun 30 15:18 phpunit.xml
drwxrwxr-x  2 1000 1000   4096 Jun 30 15:18 public
drwxrwxr-x  5 1000 1000   4096 Jun 30 15:18 resources
drwxrwxr-x  2 1000 1000   4096 Jun 30 15:18 routes
drwxrwxr-x  5 1000 1000   4096 Jun 30 15:18 storage
drwxrwxr-x  4 1000 1000   4096 Jun 30 15:18 tests
drwxrwxr-x 40 1000 1000   4096 Aug 10 14:32 vendor
-rw-rw-r--  1 1000 1000    263 Jun 30 15:18 vite.config.js

Which is interesting because I expected the user and group ids to be 9999:9999.

from docker-php.

For additional context, I tried to run the project changing the 9999 user and group ids to 1000 (the default values) and the permission denied error disappeared. Briefly, I replaced 9999 with 1000 in:

Same effect here, in my case is 1001

from docker-php.

I am not expert on how the user 9999 is being created but i think we are on the way :)

from docker-php.

For me, when I had an issue trying to create a Docker Image that wasn't using volumes my RUN commands were running as root.

I solved it by setting the user to the expected values before the RUN and then importantly, setting back to root as the last command in the Dockerfile.

This is my Dockerfile

ARG PHP_VERSION='8.2'

# ================
# Base Stage
# ================
FROM serversideup/php:${PHP_VERSION}-fpm-nginx as base
ENV AUTORUN_ENABLED=false
ENV SSL_MODE=off

# ================
# Production Stage
# ================
FROM base as production

ENV APP_ENV=production
ENV APP_DEBUG=false

# Required Modules
RUN apt-get update && \
    apt-get install -y php${PHP_VERSION}-pgsql && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* /usr/share/doc/*

USER $PUID:$PGID

# Copy contents.
# - To ignore files or folders, use .dockerignore
COPY --chown=$PUID:$PGID . .

RUN composer install --optimize-autoloader --no-dev --no-interaction --no-progress --ansi

# artisan commands
RUN php ./artisan event:cache && \
    php ./artisan route:cache && \
    php ./artisan view:cache

USER root:root

Note the setting of USER to $PUID:$PGID and then back to root:root for fpm to work correctly.

from docker-php.

Quick Question

Can everyone on this thread post their host operating system? I assume it's all Linux?

I am working on resolving this issue. I finally have a Linux development machine to do some testing and reproduction with this issue to finally get it resolved.

from docker-php.

Linux, but got team members using WSl & Mac.
Workarounds on Linux works fine on WSl, but Mac seems to be more annoying.. At least development wise with files mounted rather than files inside the image.

from docker-php.

Hmm... we use macOS exclusively and never run into a problem. Usually with the file mount on macOS, it actually helps prevent the issues from happening.

Do you have steps to reproduce specifically for your Mac? I can run it on my machine and see if I can replicate.

from docker-php.

Hi,
I have a problem, probably related to this error.
The problem occurs on Linux (fedora) and on Windows (WSL2).

1. when I use my local machine to create a Laravel project (composer create-project laravel/laravel example-app) and run docker compose up the following error pops up:
   

2. when I use the container to create the Laravel project (docker run --rm -v $(pwd):/var/www/html serversideup/php:beta-8.3-fpm-nginx-alpine composer create-project laravel/laravel example-app) then running docker compose up afterwards displays the laravel welcome page, but I cannot edit any files on my local machine.

The problem is probably related to permissions, but because of this, I am not able to use these containers for development.

In older containers, this solution helped: #172 (comment)

But now these variables are no longer available.

Is there a solution to this problem?

This is my docker compose, it's very simple:

version: '3'
services:
    php:
        image: serversideup/php:beta-8.3-fpm-nginx-alpine
        ports:
            - 80:80
        volumes:
            - .:/var/www/html

from docker-php.

Hi, I have a problem, probably related to this error. The problem occurs on Linux (fedora) and on Windows (WSL2).

Probably these environment variables will be added soon, just noticed a note in the v3 docs:

from docker-php.

Yes, I hope they will be added.

But I wonder how others are using these containers for develpoment? It doesn't work on Windows or Linux. Does it work seamlessly on MacOs? Does everyone only use these containers production-wise? 😃

from docker-php.

@xaimes I'm using it on Linux for local dev, but I had to set the PUID and PGID both to 1000 (my host machine's user ID) for it to work. For instance, this is my local docker-compose.yml:

These env vars works in v2, not in v3 beta

from docker-php.

Ah, missed that y'all trying to use the v3 beta. Whoops, sorry.

from docker-php.

Related note

Feel free to chime in on this issue: #253

Right now www-data has two separate ids based off if you're using Alpine or Debian in the beta.

I don't like that.

I am thinking of creating a webuser and webgroup of the ID 9999 like I did the last time. So far that is not in the beta yet.

from docker-php.

this error also happened to me when i try to mount volume in kubernetes..

but if i not mount volume, it can start the pod..

from docker-php.

If anyone is having permissions issues and using Docker desktop, try uninstalling and using only Docker Engine.
For days I was struggling and in the end it turned out to be Docker Desktop.

from docker-php.

@jaydrogers I am trying to run the docker container as non-root as you have outlined in #179 (comment)
However, none of the startup scripts will work in that scenario as they require creating symlinks etc.
This is my docker-compose.yml

services:
  review:
    image: my/app
    build:
      context: .
      dockerfile: Dockerfile-review
    ports:
      # laravel
      - '8001:81'
    environment:
      PORT: 81
      PUID: '${UID:-1000}'
      PGID: '${GID:-1000}'
    user: 'www-data:1000'
    networks:
      - app-network

I am trying to get such a container running on heroku and heroku wont allow you to run as root.

I am running FROM serversideup/php:beta-8.3-fpm-apache as base

from docker-php.

@rburgst: You'll need to remove the user key. Unfortunately Apache will require root to initialize, then it drops permissions to run as www-data in the default config.

This is something I plan to improve documentation on, but it's also a limitation with some of these older servers like Apache.

I hope that I can find a true non-privileged execution of PHP with FrankenPHP (#283)

from docker-php.

@rburgst: You'll need to remove the user key. Unfortunately Apache will require root to initialize, then it drops permissions to run as www-data in the default config.

As I am trying to run in heroku this is nothing I have under my control.
In the meantime I will try with nginx and frankenphp.

from docker-php.

That would be cool, while I a had some success to get franken-php to work, I still have a long way to go to get it to work properly on heroku.

from docker-php.

💪 Big Update

So here is a recap of the problem. It all comes down to root is required to run on privileged ports (80 + 443). We then drop to www-data after, which then causes a mess because any Docker CMD passed will default to root (not www-data) -- causing the error on this thread.

🦄 Proposed Solution

• I'm thinking of defaulting the fpm-apache and fpm-nginx images to be UNPRIVILEGED by default
• This will dramatically improve container security
• This will also reduce the complexities and required workarounds with su, sudo, etc

⚠️ Breaking change

Caution

This will require users of the beta-*-fpm-nginx and beta-*-fpm-apache images to make updates

👉 What would be required to fix

• By default, our NGINX and Apache images would listen on 8080 and 8443
• If you want port 80 + 443 on your host to go directly to the container, you would need to configure -p 80:8080 -p 443:8443

🗣️ Related discussions

• https://twitter.com/tobias_petry/status/1778816006409850997
• https://twitter.com/jaydrogers/status/1778823124789637216

Would love to hear everyone's thoughts 😃

Would love to see that merged asap 😄

from docker-php.

💪 Another Big Update

We have a PR ready for testing that will dramatically improve container security and developer experience:

• #311

🙏 Please help test this

Everything is documented on the PR on how to test:

• We have pre-built images for you to test (see the PR for more details)
• We also dramatically improved the documentation with the containers moving to be unprivileged by default (get the preview URL from the PR)

We will merge this big change soon if we get good feedback 😅🚀

Check the PR for more details →

from docker-php.

A fix has been released 🥳

These changes are now live in our beta images! Learn more about the release here:

• https://github.com/serversideup/docker-php/releases/tag/v3.0.0-beta4

Monitor this CI/CD job for the exact moment these changes will be live (takes about an hour to build):

• https://github.com/serversideup/docker-php/actions/runs/8788452858

from docker-php.

It worked fine for me until a few minutes ago when I did a --build, now I get these errors

Password: su: Authentication failure
Unit is running unprivileged, then it cannot use arbitrary user and group

from docker-php.