DB_PASSWORD_FILE not applied at runtime → MySQL auth fails (using password: NO)

[StrangeRanger]

Lychee version

v7.0.1

Did you check the latest Lychee version?

Yes, I did

Which PHP version are you using?

PHP 8.4

Detailed description of the problem

When running Lychee via Docker Compose with database credentials provided through Docker secrets (DB_PASSWORD_FILE), Lychee fails during database migrations with MySQL authentication errors indicating that no password is being used, even though the secret is present and readable inside the container.

Manual inspection shows that DB_PASSWORD is not populated in the runtime environment unless validate-env.sh is explicitly sourced, suggesting the secret-loading logic does not persist into the process running migrations.

---

Environment
• Lychee Docker image: ghcr.io/lycheeorg/lychee (intended version: v7.0.1)
• Database: MariaDB (Docker)
• Deployment method: Docker Compose
• Database credentials provided via Docker secrets using *_FILE variables

---

Docker Compose (relevant excerpts)

lychee:
  environment:
    - DB_CONNECTION=mysql
    - DB_HOST=lychee_db
    - DB_PORT=3306
    - DB_DATABASE=lychee
    - DB_USERNAME=lychee
    - DB_PASSWORD_FILE=/run/secrets/mysql_password

secrets:
  mysql_password:
    file: ./secrets/mysql_password.txt

---

Observed behavior

Lychee repeatedly fails during startup while running database migrations.

Exact log output (excerpt):

🚀 Starting Lychee entrypoint...
🔍 Validating environment variables...
✅ Valid database connection type: mysql
✅ Valid environment: production
✅ Core variables validated
🎉 Environment validation complete!
⏳ Waiting for database to be ready...
✅ Database port is open!
Validating and setting PUID/PGID
  User UID: 33
  User GID: 33
🔍 Validating permissions...
⏰ Set Permissions (this may take a while)...
✅ Permissions set securely
🧹 Clearing bootstrap cache...
🌐 Starting Lychee in web mode...
🔄 Running database migrations...

In Connection.php line 826:

  SQLSTATE[HY000] [1045] Access denied for user 'lychee'@'172.21.0.3' (using
  password: NO) (Connection: mysql, SQL: select exists (select 1 from informa
  tion_schema.tables where table_schema = schema() and table_name = 'migratio
  ns' and table_type in ('BASE TABLE', 'SYSTEM VERSIONED')) as `exists`)

In Connector.php line 67:

  SQLSTATE[HY000] [1045] Access denied for user 'lychee'@'172.21.0.3' (using
  password: NO)

The container then restarts and repeats the same failure.

---

Investigation

An interactive shell was started inside the Lychee container:

docker compose run --rm --entrypoint sh lychee

Checking environment variables before sourcing any scripts:

DB_PASSWORD=

Then manually sourcing the validation script used by the entrypoint:

. /usr/local/bin/validate-env.sh

Checking again:

DB_PASSWORD=<set>

This demonstrates:
• DB_PASSWORD_FILE is readable
• validate-env.sh does populate DB_PASSWORD
• However, DB_PASSWORD is not present by default in the environment used by the application/migration process

---

Expected behavior

When DB_PASSWORD_FILE is set:
• Lychee should read the file
• Export DB_PASSWORD
• Ensure DB_PASSWORD is available to the process running migrations and the web app

This is the documented and expected behavior of _FILE-style secret handling.

---

Actual behavior
• Environment validation reports success
• Database port is reachable
• Migrations run without a password
• MySQL rejects the connection with (using password: NO)

---

Root cause (likely) (suggest by ChatGPT)

validate-env.sh (or equivalent secret-loading logic):
• Is executed in a subshell instead of being sourced
• Or otherwise does not export variables into the shell that launches php artisan migrate

As a result, secrets loaded from *_FILE variables do not persist into the runtime environment.

---

Workarounds
• Explicitly set DB_PASSWORD instead of DB_PASSWORD_FILE

---

Additional notes
• The secret file exists and is readable
• The database user exists and is reachable
• The error message clearly indicates no password is being used
• Prior to upgrading to v7, using DB_PASSWORD_FILE and Docker Compose secrets worked fine

---

Impact

This breaks Docker secrets–based deployments, which are a standard and recommended practice for containerized applications.

Steps to reproduce the issue

1. Create a working directory and add the following files exactly as shown:
   • docker-compose.yml (use the full file content below)
   • ./lychee/conf/.env (use the full file content below)
   • Create secret files referenced by the compose file:
   ./secrets/mysql_root_password.txt ./secrets/mysql_password.txt ./secrets/mail_password.txt
2. Create docker-compose.yml with the following contents:

services:
  lychee_db:
    image: mariadb:11
    container_name: lychee_db
    restart: unless-stopped
    environment:
      - MYSQL_ROOT_PASSWORD_FILE=/run/secrets/mysql_root_password
      - MYSQL_DATABASE=lychee
      - MYSQL_USER=lychee
      - MYSQL_PASSWORD_FILE=/run/secrets/mysql_password
    expose:
      - 3306
    volumes:
      - mysql:/var/lib/mysql
    networks:
      - lychee
    secrets:
      - mysql_root_password
      - mysql_password

  lychee:
    image: ghcr.io/lycheeorg/lychee:latest
    container_name: lychee
    restart: unless-stopped
    ports:
      - "8000:8000"
    volumes:
      - ./lychee/uploads:/app/public/uploads
      - ./lychee/storage/app:/app/storage/app
      - ./lychee/logs:/app/storage/logs
      - ./lychee/tmp:/app/storage/tmp
      - ./lychee/conf/.env:/app/.env:ro
      - ./lychee/conf/user.css:/app/public/dist/user.css
      - ./lychee/conf/custom.js:/app/public/dist/custom.js
    environment:
      ## App config
      - APP_NAME=Lychee
      - APP_ENV=production
      - APP_URL=https://images.hthompson.dev
      - APP_FORCE_HTTPS=true
      ## Database config
      - DB_CONNECTION=mysql
      - DB_HOST=lychee_db
      - DB_PORT=3306
      - DB_DATABASE=lychee
      - DB_USERNAME=lychee
      - DB_PASSWORD_FILE=/run/secrets/mysql_password
      ## Timezone config
      - TIMEZONE=America/Los_Angeles
      ## Trusted proxy config
      - TRUSTED_PROXIES=127.0.0.1,::1,172.18.0.0/16
      # - TRUSTED_PROXIES=*
      # - TRUSTED_PROXIES=127.0.0.1,::1,172.64.0.0/13,104.16.0.0/13,2606:4700::/32,
    depends_on:
      - lychee_db
    networks:
      - lychee
    secrets:
      - mysql_password
      - mail_password

networks:
  lychee:

volumes:
  mysql:

secrets:
  mysql_root_password:
    file: ./secrets/mysql_root_password.txt
  mysql_password:
    file: ./secrets/mysql_password.txt
  mail_password:
    file: ./secrets/mail_password.txt

3. Create ./lychee/conf/.env with the following contents (excerpt; unchanged defaults omitted for brevity):

APP_KEY=base64:<REDACTED>

4. Populate the secret files with appropriate values (do not commit them; any non-empty values should be sufficient to reproduce the behavior).

5. Start the stack:

docker compose up -d

6. View the Lychee container logs:

docker logs lychee

7. Observe that startup reaches migration execution and fails with an auth error indicating no password is being used:
   • SQLSTATE[HY000] [1045] Access denied for user 'lychee'@'172.21.0.3' (using password: NO)
8. (Optional diagnostic) Start an interactive shell in the Lychee container:

docker compose run --rm --entrypoint sh lychee

9. Confirm DB_PASSWORD is empty before sourcing the validation script:

echo "DB_PASSWORD=${DB_PASSWORD:+<set>}"

Expected output:

DB_PASSWORD=

10. Source the validation script:

. /usr/local/bin/validate-env.sh

11. Confirm DB_PASSWORD becomes set after sourcing:

echo "DB_PASSWORD=${DB_PASSWORD:+<set>}"

Expected output:

DB_PASSWORD=<set>

Diagnostics [REQUIRED]

N/A

Browser & System [REQUIRED]

System: Ubuntu 24.04
Deployment: Docker Compose
Browser & Related: N/A

Please confirm (incomplete submissions will not be addressed)

• I understand my bug report will be removed if I haven't met the criteria above.
• I have provided easy and step-by-step instructions to reproduce the bug.
• I understand that if I am requested to provide more information, I must do so within 14 days or the bug report will be closed.

[ildyria]

I will investigate that one.

[ildyria]

Fixed: #3958

[StrangeRanger]

Thank you for such a quick response and fix!

[ildyria]

It will be available in the next release or already on edge depending of how you like to play :)