Testcontainers-java: Permissions error with config mounted into MySQL container

[ezraroi]

11:42:05.293 [Test worker] ERROR 🐳 [mysql:5.7.22] - Container log output (if any) will follow:
11:42:05.304 [tc-okhttp-stream-474827747] INFO 🐳 [mysql:5.7.22] - STDERR: 
11:42:05.305 [tc-okhttp-stream-474827747] INFO 🐳 [mysql:5.7.22] - STDERR: ERROR: mysqld failed while attempting to check config
11:42:05.305 [tc-okhttp-stream-474827747] INFO 🐳 [mysql:5.7.22] - STDERR: command was: "mysqld --verbose --help"
11:42:05.305 [tc-okhttp-stream-474827747] INFO 🐳 [mysql:5.7.22] - STDERR: 
11:42:05.306 [tc-okhttp-stream-474827747] INFO 🐳 [mysql:5.7.22] - STDERR: mysqld: Can't read dir of '/etc/mysql/conf.d/' (Errcode: 13 - Permission denied)
11:42:05.306 [tc-okhttp-stream-474827747] INFO 🐳 [mysql:5.7.22] - STDERR: mysqld: [ERROR] Fatal error in defaults handling. Program aborted!

We see this in the log (look on the null):
Cmd: com.github.dockerjava.core.command.CopyArchiveToContainerCmdImpl@2c8c6bb[cp ,<null>, ,6ca1ea3ce4b2582536fac69ceeb991670930b1ac65a6b2206c1ab88f3c990b65,:,/etc/mysql/] 11:41:45.064 [Test worker] INFO 🐳 [mysql:5.7.22] - Starting container with ID: 6ca1ea3ce4b2582536fac69ceeb991670930b1ac65a6b2206c1ab88f3c990b65

If we override the MySQLContainer class and just rmove this line from the configure function:
optionallyMapResourceParameterAsVolume(MY_CNF_CONFIG_OVERRIDE_PARAM_NAME, "/etc/mysql/conf.d", "mysql-default-conf");

Everything is working. Looks like it is copying invalid file to the container

[kiview]

Hi @ezraroi,
in which environment are you running? OS, Docker version?

[ezraroi]

OS is Ubunto 16.04 and Docker version 17.03.2-ce, build f5ec1e2

[bo0tzz]

I am experiencing this same issue, also on Ubuntu 16.04 but on docker version 18.06.1-ce, build e68fc7a

[kiview]

And this is happening for Testcontainers 1.9.1?
Because of the mapping, this is probably some file permissions problem on the host with the config file.

Since we changed most other parts of Testcontainers to favor copying the file into the container instead of mounting or mapping, it would probably solve this problem here as well.

[ezraroi]

Yes, version 1.9.1.

[noqqe]

Same Issue here

<testcontainers.version>1.11.2</testcontainers.version>

build   24-May-2019 09:21:02    2019-05-24 09:21:02.234 ERROR 605 --- [           main] ?.7.23] : Log output from the failed container:
build   24-May-2019 09:21:02    ERROR: mysqld failed while attempting to check config
build   24-May-2019 09:21:02    
build   24-May-2019 09:21:02    command was: "mysqld --verbose --help"
build   24-May-2019 09:21:02    
build   24-May-2019 09:21:02    mysqld: Can't read dir of '/etc/mysql/conf.d/' (Errcode: 13 - Permission denied)
build   24-May-2019 09:21:02    mysqld: [ERROR] Fatal error in defaults handling. Program aborted!

[rnorth]

I think @kiview is right - this will be down to permissions on the volume mounted configuration. The right long-term solution has to be to change the container code to copy config files in, rather than volume mount. This has been possible for a while.

A PR to do this would be welcomed if anyone is interested; we can help talk through the solution to clarify anything that is needed.

[gedl]

Same problem here
Any immediate workaround?
I'm on MacOs 10.14.5 and test containers 1.11.2

edit: same thing on 1.11.3

[mkornblum]

I am also facing this problem. A workaround which seems to work OK for me and is in the spirit of "copy config files in, rather than volume mount", is something like:

 mysql = (MySQLContainer) new MySQLContainer().withDatabaseName("some_database")
        .withCopyFileToContainer(MountableFile.forClasspathResource("db/testMySQL.cnf"), "/etc/mysql/conf.d/")
        .withLogConsumer(logConsumer);

I haven't dug into this much further than that but I assume the ultimate PR would do something similar in the MySQLContainer class?

[jarebudev]

I also experienced this problem and looked into this further.

This was with

<dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.testcontainers</groupId>
                <artifactId>testcontainers-bom</artifactId>
                <version>1.12.4</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

In my instance the problem is being caused when the mysql-default-conf resource (my.cnf) inside the mysql-1.12.4.jar is extracted into a temporary folder under /tmp on the host so it can be copied into the mysql container (destination /etc/mysql/conf.d).

The reason it was failing to copy was that the temporary folder was created with no read permission for all users due to my umask setting.

ls -lrat /tmp
...
drwxrwx---.  2 user user     20 Jan 14 22:34 .testcontainers-tmp-15478807415261855030

The solution for me was to change my umask setting so that all users could read the temp folder.

umask 002

@rnorth @kiview - from what I could tell all config files in modules are copied into the container instead of volume mapping (unless I'm missing something)? If you think this is worth documenting somewhere let me know and i'll make the change and submit a PR.

[rottenha]

This is actually a bug in the testcontainers implementation in general, checking 1.14.3 and 1.15-rc2, that it almost always never explicitly sets the file permission on resources copied from the host system into a container, but instead relies on the file permissions being correctly set on the host system. This is a major problem, affecting multiple containers when trying to run the test suites.

In this particular case, regarding MySQLContainer, the automatic configuration is done in methods MySQLContainer.configure() and parent class method JdbcDatabaseContainer.optionallyMapResourceParameterAsVolume(), which internally calls MountableFile.forClasspathResource(resourceName) instead of MountableFile.forClasspathResource(resourceName, fileMode).

A sound approach and a proper fix is to explicitly set the file permissions in the implementation class MySQLContainer.configure() that knows about the requirements and change the calls appropriately.

Second, the approach of implicit file permissions in MountableFile.forClassPathResource() should be deprecated in favour of explicitly setting them, i.e. normal use case should be to explicitly set them, unless explicitly file permission are set to be default from the host system.