Check for file ownership on startup

[UnlimitedCookies]

Hi,

somehow I recently accidentally changed the ownership of the files in the volume folder. Then it got stuck in a boot loop, because it couldn't read the config.

Thus it would be awesome to check the file ownership and to execute chown -R 100:101 files if necessary.

Thanks!

[jbergstroem]

somehow I recently accidentally changed the ownership of the files in the volume folder. Then it got stuck in a boot loop, because it couldn't read the config.

"Interesting". I'm guessing this change happened outside docker, as part of modifying the volume? Just trying to understand if there could be downsides to making such a change. Would it for instance make sense with refusing to start instead?

[UnlimitedCookies]

Exactly, I accidentally chowned the external volume.

I think it should be okay to just chown, but maybe someone else has a different view on this.

[jbergstroem]

I think it should be okay to just chown, but maybe someone else has a different view on this.

I think a good first step is attempting to write a file to the volume and if it doesn't work, exit. Is this perhaps the "boot loop" you're talking about since I can only assume it would emit some kind of error and then start up again due to --restart=always or similar?

Will have to read up about being able to express "unrecoverable startup error" to a container runtime.

[jbergstroem]

Will have to read up about being able to express "unrecoverable startup error" to a container runtime.

So, at least docker tells us that you shouldn't be using always as a restart strategy if there is chance of exits that should be seen as fatal; but rather on-failure or unless-stopped with a few corresponding settings.

Will check in other containers how they handle similar scenarios and think about what ramifications invoking chown could have.

[UnlimitedCookies]

For example chown -R postgres:postgres /var/lib/postgresql is used in the official postgresql docker image.

Another example is the gitea rootless docker image.

Linux-Server IO

Right off the top of my head I can't think of any implications this could have.

[jbergstroem]

@UnlimitedCookies thanks for the research. I will proceed with your suggestion then!

[UnlimitedCookies]

The only real implication it could have if someone knowingly changed the file ownership for some reason.

So maybe you should be able to turn this behavior off - I don't know if this is really necessary though. It's just a thought for edge cases.

[jbergstroem]

The only real implication it could have if someone knowingly changed the file ownership for some reason.

If someone needs to handle ACL differently in a volume that mysql assumes ownership of, I'm thinking there must be other tools available to them to handle it - for instance another volume. I prefer someone opening an issue about it should it occur.

Will open a PR today; just writing a test to cover it.

[UnlimitedCookies]

Hey, what's the current status on this?

[jbergstroem]

Hey, what's the current status on this?

Will land with next version of mariadb which also fixes the innodb bug (10.4.18).

[jbergstroem]

Note: landed with the bump to 10.4.17, really sorry about dragging my feet on this one.

[UnlimitedCookies]

Thanks for your great work! Obviously, since you do this voluntarily you have no tangible obligation.