PHP/Apache containers exit 1 after rebuild: LANDO_SERVICE_CERT env not present at runtime with Docker 29 + compose 2.31

[f-liva]

Environment

• Lando: 3.26.3 (installed via official setup-lando.sh, stable channel)
• Docker Desktop: 29.4.0 (Windows, WSL2 Ubuntu integration)
• docker compose: 2.31.0 (bundled with lando at ~/.lando/bin/docker-compose-v2.31.0)
• OS: WSL2 Ubuntu 24.04 on Windows 11
• Recipe: mixed (WordPress + multiple PHP services). Project .lando.yml declares ~16 services (PHP 7.3, 8.3, 8.4, MariaDB, Redis, Memcached, Node, Mailhog, Mailpit, SFTP).

Symptom

After lando start (or lando rebuild), every container that runs the /lando-entrypoint.sh → /scripts/000-add-cert chain (PHP/Apache services: appserver, laravel, b2b, b2b2c, b2b2cwp, gestionale, gestione, pagamenti, sinistri, b2c) exits with status 1. Base services (database, redis, memcached, mailpit, mailserver, node, sftp) stay up.

docker logs <service>_1 shows:

addcert 12:36:08.80 INFO  ==> Enabling apache ssl modz
chown: cannot access '': No such file or directory
run-parts: /scripts/000-add-cert exited with return code 1

The offending script is the standard lando add-cert:

chown "$LANDO_HOST_UID:$LANDO_HOST_GID" "$LANDO_SERVICE_CERT"
chown "$LANDO_HOST_UID:$LANDO_HOST_GID" "$LANDO_SERVICE_KEY"

The env variables $LANDO_SERVICE_CERT and $LANDO_SERVICE_KEY are empty at runtime, so chown receives an empty target.

What makes this confusing

The generated compose fragments do define those env vars, for example ~/.lando/compose/ima/laravel-2.yml:

services:
  laravel:
    entrypoint: /lando-entrypoint.sh
    environment:
      LANDO_SERVICE_NAME: laravel
      LANDO_SERVICE_TYPE: php
      LANDO_SERVICE_CERT: /lando/certs/laravel.ima.crt
      LANDO_SERVICE_KEY: /lando/certs/laravel.ima.key

And the full merged config is correct:

docker compose -f ~/.lando/compose/ima/globals-0.yml -f ~/.lando/compose/ima/laravel-0.yml ... config \
  | grep SERVICE_CERT
#  LANDO_SERVICE_CERT: /lando/certs/laravel.ima.crt
#  (for every affected service)

But docker inspect <container> --format '{{.Config.Env}}' on the live (failed) containers does not show LANDO_SERVICE_CERT / LANDO_SERVICE_KEY, even though other envs from the same fragment file (e.g. LANDO_SERVICE_NAME, LANDO_SERVICE_TYPE) are present.

So compose-file merge is correct but the runtime docker create/docker compose up call issued by lando is dropping those two specific variables. Every fragment that defines the cert vars lives in a <service>-2.yml file, and they're the only ones not surviving the merge → run pipeline.

Workaround

lando rebuild -y (full destroy + recreate, not lando restart) resolves it. After rebuild all containers boot normally and the certs get written. Subsequent lando start/stop are stable.

Something about the existing container / network state interferes with env propagation under Docker 29; a clean recreate fixes the state.

Hypotheses

1. Docker 29 changed how docker compose applies the environment: map when one of the input files only overrides env (no other service attrs). lando's multi-file compose pipeline (~80 fragments per project) may hit an edge case where a single-purpose fragment (<service>-2.yml) gets silently skipped in-merge at runtime but not during compose config (dry-run).
2. State left over from the previous Docker version in the docker daemon's metadata store prevents env re-application on plain up, but a rebuild bypasses it.

Repro steps

1. Running WSL2 + Docker Desktop updated to 29.4.0 with a multi-service lando project that uses auto-generated certs
2. lando start → containers spin up but PHP/Apache ones exit 1
3. docker logs → cert chown empty
4. docker compose -f ... -f ... config | grep SERVICE_CERT → env is defined
5. docker inspect <php_container> --format '{{.Config.Env}}' | grep SERVICE_CERT → empty
6. lando rebuild -y → now the same docker inspect shows the env, containers start cleanly

Asks

• Add a note in the upgrade docs (or in lando rebuild help) that post Docker engine upgrade a rebuild may be required, not a restart
• Consider a preflight check in lando start that verifies the expected service envs end up in the container, to surface the issue with a clearer message than silent chown failure
• Bump the tested Docker engine compat range in lando 3.x (<=27.5.99 today, effectively usable up to 29 once rebuilt)

Happy to dig further if a maintainer points me at the relevant plumbing.