testing database does not get created on initial build

[chrispelzer]

Sail Version

1.51.0

Laravel Version

12.44.0

PHP Version

8.5

Operating System

macOS

OS Version

26.2

Description

The starting up the of mysql container will fail due to the creating of the testing database script not having the permissions for executable, though only when the runtime is published to the project using php artisan sail:publish since it will reference the files under /docker/mysql or mariadb or pgsql.

Error within the Mysql container

2025-12-30 01:27:51+00:00 [Note] [Entrypoint]: Giving user sail access to schema bug_report


/usr/local/bin/docker-entrypoint.sh: /docker-entrypoint-initdb.d/10-create-testing-database.sh: /usr/bin/env: bad interpreter: Permission denied

2025-12-30 01:27:51+00:00 [Note] [Entrypoint]: /usr/local/bin/docker-entrypoint.sh: running /docker-entrypoint-initdb.d/10-create-testing-database.sh

drwxr-xr-x@  3 chrispelzer  staff   96 Dec 29 20:27 .
drwxr-xr-x@ 11 chrispelzer  staff  352 Dec 29 20:27 ..
-rw-r--r--@  1 chrispelzer  staff  297 Dec 29 20:27 create-testing-database.sh
❯ pwd
/Users/chrispelzer/Sites/bug-report/docker/mysql

Shutting down docker and starting it back up will allow the mysql container to successfully run, but there is then no testing database created.

Steps To Reproduce

1. Create a new Laravel Sail application
   laravel new bug-report
2. Install Laravel Sail
   php artisan sail:install
3. Select mysql though I'm assuming same issue with mariadb and pgsql as well
4. Publish Sail runtime
   php artisan sail:publish
5. Start up sail
   sail up -d

[hosni]

It seems something is wrong inside the container.
This is the bash script which is runs the files inside /docker-entrypoint-initdb.d directory (if they are executable)
https://github.com/docker-library/mysql/blob/ddb031e406121b1a298563775d521c044452a508/8.4/docker-entrypoint.sh#L67-L69
If a file is executable, it shows ... running file ...
So it is run by a MySQL container, but when it tries to use /usr/bin/env (because of the Shebang), it fails!

@chrispelzer, could you please share the result of this command inside the MySQL container?

1. ls -l /usr/bin/env
2. which bash
3. ls -l $(which bash)

[chrispelzer]

which isn't available in the container, though I was able to determine the bash being used by type

bash-5.1# ls -l /usr/bin/env
-r-xr-xr-x 1 root root 50 Feb 21  2025 /usr/bin/env
bash-5.1# type bash
bash is /usr/bin/bash
bash-5.1# ls -la /usr/bin/bash
-rwxr-xr-x 1 root root 1366992 May  1  2024 /usr/bin/bash

[hosni]

which isn't available in the container, though I was able to determine the bash being used by type

bash-5.1# ls -l /usr/bin/env
-r-xr-xr-x 1 root root 50 Feb 21 2025 /usr/bin/env
bash-5.1# type bash
bash is /usr/bin/bash
bash-5.1# ls -la /usr/bin/bash
-rwxr-xr-x 1 root root 1366992 May 1 2024 /usr/bin/bash

@chrispelzer I think the confusing part here is that MySQL considers the file as executable, even though on your host, the file is clearly not executable:

-rw-r--r--@ create-testing-database.sh

MySQL decides whether to print running vs sourcing based on this check inside the container:

				if [ -x "$f" ]; then
					mysql_note "$0: running $f"
					"$f"
				else
					mysql_note "$0: sourcing $f"
					. "$f"

Since the log shows:

[Entrypoint]: running /docker-entrypoint-initdb.d/10-create-testing-database.sh

it means that inside the container the file is considered executable, even if it isn’t on macOS. This can happen with Docker Desktop mounts on macOS.

Execution then fails at the kernel level:

/usr/bin/env: bad interpreter: Permission denied

So MySQL:

• sees the file as executable
• chooses the “running” path
• tries to execute it
• but the shebang/interpreter cannot be executed
• and there is no fallback to source

To confirm this, could you please share:

1. Inside the container:

ls -l /docker-entrypoint-initdb.d/10-create-testing-database.sh

2. On the host:

ls -l ./docker/mysql/create-testing-database.sh

3. And try executing it inside the container:

/docker-entrypoint-initdb.d/10-create-testing-database.sh

I think this will show that the executable bit is effectively set inside the container, which explains why MySQL prints running even though the host file is not executable.

[github-actions]

Thank you for reporting this issue!

As Laravel is an open source project, we rely on the community to help us diagnose and fix issues as it is not possible to research and fix every issue reported to us via GitHub.

If possible, please make a pull request fixing the issue you have described, along with corresponding tests. All pull requests are promptly reviewed by the Laravel team.

Thank you!