Mysql: docker logs mbind: Operation not permitted

[coding-chenkaikai]

你好，执行docker run mysql:8.0.1的时候，docker logs 查看容器日志出现mbind: Operation not permitted，最初以为是权限的问题，添加--cap-add=ALL参数，还是会出现该日志，请问下该问题的影响范围是什么以及如何避免出现？

[ghost]

same issue here

[ltangvald]

The server use mbind for NUMA (non-uniform memory access) operations, but Docker blocks this access by default. It's possible to provide a custom profile that allows it, but the syntax of the profile files has changed across Docker versions, so it's kind of messy. There's more about this here: https://docs.docker.com/engine/security/seccomp/

[tianon]

Closing since this is more an issue with the default configuration of Docker's seccomp profile, and there's not anything we can do to fix this in the image itself.

See https://github.com/docker-library/mongo/issues/113 for a similar issue over on the mongo image.

As noted there, adding something to the documentation (especially referencing the error message) would be a great idea. :+1:

[johncmunson]

All of a sudden I started getting these mbind errors as well. For me, the solution was locking down the version of the mysql docker image. I changed my docker-compose.yml from...

services:
  mysqldb:
    image: mysql

to...

services:
  mysqldb:
    image: mysql:5.7.22

[atkinchris]

@johncmunson - we're seeing the same thing - mbind: Operation not permitted with no other environment changes in the last few days, when running Docker on an EC2.

[nirodg]

None of this workarounds does work for me. I've tried on my local env, on a virtual machine and even on a VPS and nothing, same issue. I've tried using a different version and it crashes, seriously thinking it might be a bug or something.

version: '3.1'
services:
  mysql:
    image: mysql
    container_name: mysql.dev
    restart: always
    ports:
     - 13306:3306
    environment:
      MYSQL_ROOT_PASSWORD: brage
      MYSQL_DATABASE: mysqlapp

  adminer:
    image: adminer
    restart: always
    links:
      - mysql
    ports:
      - 18080:8080

The only way to connect is by docker exec -it mysql.dev mysql -u root -p

To connect to adminer it´s straightforward, just open the browser and type http://localhost:18080

[yosifkit]

@nirodg, your issue is unrelated to mbind. The mbind error does not cause MySQL to fail to run or refuse connections. Assuming that your adminer is unable to connect to MySQL, then most likely you are running into #409, #419, #424.

[skjnldsv]

Please bump when latest tag images are fixed :/

[tianon]

The mbind error is a red herring; it shouldn't stop the server from working. Whatever issue you're experiencing is likely deeper than just mbind.

[samabsalom]

I came across this by googling the mbind thing. Just adding this here to allow others to know that regardless of the root issue using 5.7 instead of latest fixed the problem and got the container running again
Thanks all!

[tianon]

It's not "fixed" because there's not a bug here we _can_ fix. The mbind message is a _warning_. It is harmless, and should not cause any issues except performance. If you wish to remove it, you'll need to tweak your container's seccomp profile to allow NUMA, and there's literally nothing we can do about that from inside the image -- you have to do so at runtime.

If your MySQL daemon is not starting, there's a very low chance that this mbind message is even related, and I'd suggest digging further into your logs and/or install.

[ltangvald]

The underlying issue wasn't fixed in time for 8.0.12 unfortunately, but as tianon says the message is just a warning. There's a workaround in the upstream image that fixes this, but the workaround was to disable numa support in the binary, which is ok for the docker-custom rpm we use there, but not for the regular debian packages used in this image

[mvelebit]

@tianon @ltangvald Thanks for the info!

[bensonfx]

add this in docker-compose can fix it

security_opt:
  - seccomp:unconfined

[ltangvald]

@bensonfx That disables much of docker's native security, and is not recommended for anything aside from testing. However, this issue is fixed in 8.0.13, so just update the image and you should no longer see the error message.

[teyou]

@ltangvald not true. I'm still able to see this issue in 8.0.13

[fjzzmike]

add this in docker-compose can fix it

security_opt:
  - seccomp:unconfined

it is OK

[crazy-canux]

security_opt is not working on docker swarm.
How to fix it for docker swarm mode useing docker-compose?

[LukeQCJ]

my error as follows :

2019-10-18 07:58:56+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.0.18-1debian9 started.
2019-10-18 07:59:01+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
2019-10-18 07:59:01+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.0.18-1debian9 started.
2019-10-18T07:59:51.875727Z 0 [Warning] [MY-011070] [Server] 'Disabling symbolic links using --skip-symbolic-links (or equivalent) is the default. Consider not using this option as it' is deprecated and will be removed in a future release.
2019-10-18T07:59:51.896131Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.18) starting as process 1
2019-10-18T08:01:57.377624Z 4 [System] [MY-013381] [Server] Server upgrade from '80017' to '80018' started.
mbind: Operation not permitted

but I tried the option

     security_opt:
       - seccomp:unconfined

then fix it.

[titpetric]

You can add cap_add: [ SYS_NICE ] to docker-compose.yml services instead of seccomp:unconfined.

[lzk50136]

add this in docker-compose can fix it

security_opt:
  - seccomp:unconfined

thx

[crazy-canux]

please reopen this. "security_opt" and "cap_add" not supported in compose for docker swarm.

[jtomaszewski]

The issue should totally be open. What does this warning even say? Mysql instead of forwarding errors from OS that tell us very little, could provide warning with context of how it affects mysql.

Also, maybe there are better ways of informing us about some performance optimization not working, than echoing the same warning message every second. (Like, once a minute, on a bootstrap?)

And last but not least, there should be an ability to somehow tweak the running mysql instance so that it doesn't care about that "performance optimization" (or whatever mbind error is blocking), and so we can run the mysql server safely without the warning.

[mario-evangelista-silva]

in my case it was solved by including the "privileged = true" directive in the docker-compose.

[BinZhiZhu]

add this in docker-compose can fix it

security_opt:
  - seccomp:unconfined

I also encountered the same problem. I used the appeal method but still did not solve the problem. Why? MySQL keeps restarting

[tianon]

It's not "fixed" because there's not a bug here we _can_ fix. The mbind message is a _warning_. It is harmless, and should not cause any issues except performance. If you wish to remove it, you'll need to tweak your container's seccomp profile to allow NUMA, and there's literally nothing we can do about that from inside the image -- you have to do so at runtime.

If your MySQL daemon is not starting, there's a very low chance that this mbind message is even related, and I'd suggest digging further into your logs and/or install.

[chiqui3d]

except performance

Performance is not an issue?

I'm using version 8.0.23 and I'm still having this problem with excessive memory consumption.

[tianon]

To be clear: performance is an issue, but not one we can automatically solve in the image (or even really in MySQL itself, unless that team decides to rewrite how this bit of code works), which is what I was trying to get at there -- allowing mbind requires adjusting the seccomp profile of the container (and the simplest way to do so in Docker is to add the SYS_NICE capability to your container, which will automatically adjust the default seccomp profile to include the necessary bits, as discussed in this thread, esp. https://github.com/docker-library/mysql/issues/303#issuecomment-643154859):

You can add cap_add: [ SYS_NICE ] to docker-compose.yml services instead of seccomp:unconfined.