Mariadb container with cifs volume causes InnoDB to crash

General
1

Hey,

I am trying to build a docker container that uses MariaDB and stores the database data for it on a network share.

This is my Dockerfile for the container (the usernames and passwords filled in of course):

FROM mariadb
ENV MARIADB_USER <username>
ENV MARIADB_PASSWORD <password>
ENV MARIADB_ROOT_PASSWORD <root_password>

Next I am creating an image, volume and container with this:

docker image build --tag my-database

docker volume create                                            \
	--opt type="cifs"                                           \
	--opt o="username=,password=,file_mode=0777,dir_mode=0777"  \
	--opt device="//192.168.1.100/database"                     \
	database-storage

docker container create                       \
	--name my-database                        \
	--volume database-storage:/var/lib/mysql  \
	--publish 3306:3306                       \
	--user mysql                              \
	my-database

If I then run this container, it fails with this output in the log:

2021-12-24 01:05:13+00:00 [Note] [Entrypoint]: Entrypoint script for MariaDB Server 1:10.6.5+maria~focal started.
2021-12-24 01:05:13+00:00 [Note] [Entrypoint]: Initializing database files
2021-12-24 01:05:14 0x7fe321ffd700  InnoDB: Assertion failure in file /home/buildbot/buildbot/build/mariadb-10.6.5/storage/innobase/os/os0file.cc line 3596
InnoDB: Failing assertion: cb->m_err == DB_SUCCESS
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mariadbd startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: https://mariadb.com/kb/en/library/innodb-recovery-modes/
InnoDB: about forcing recovery.

And if I just restart it again, this log:

2021-12-24 01:06:15+00:00 [Note] [Entrypoint]: Entrypoint script for MariaDB Server 1:10.6.5+maria~focal started.
2021-12-24 01:06:16+00:00 [Note] [Entrypoint]: Initializing database files
2021-12-24  1:06:16 0 [ERROR] InnoDB: Plugin initialization aborted with error I/O error
2021-12-24  1:06:16 0 [ERROR] Plugin 'InnoDB' init function returned error.
2021-12-24  1:06:16 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2021-12-24  1:06:16 0 [ERROR] Unknown/unsupported storage engine: InnoDB
2021-12-24  1:06:16 0 [ERROR] Aborting

Looking at the database folder on my shared network folder, there are four files:

    16384 23 Dec 17:06 aria_log.00000001
       52 23 Dec 17:06 aria_log_control
100663296 23 Dec 17:05 ib_logfile101
 12582912 23 Dec 17:05 ibdata1

Before I added the file_mode=0777,dir_mode=0777 to the volume creation options I got even more read/write errors. And now since adding those two I am left with the InnoDB IO errors :frowning:

Does anyone have an idea what I am doing wrong?

Thank you!
Ari

PS: I should probably mention, if I don’t add the --volume line to the creation of the container, then it works just fine with the automatically created temporary volume.

2

May I suggest to make a test setup on a vm, where you install mariadb directly on the host and point the data dir to cifs as well? This way you can rule out if its a docker problem (less likely) or a cifs remote share problem (most likely). My expectation is that it doesn’t work either, because cifs shares lack required capabilites.

If you don’t want to create the suggested test setup, you can try if using nfsv4 baked volumes solves the issue. I used to store postgres database data on nfsv4 and worked like a charm (even though the documentation of postgres recommends to NOT do it) and I assume both will require the same capabilites from the filesystem.

The explaination why it works with a named volume that doesn’t point to a remote share is simple: the data is written into a local filesystem that provides all the required bells and whistles.