Bind-mounting read-only grafana.ini causes: chown: changing ownership of '/etc/grafana/grafana.ini': Read-only file system

[wpalmer]

run.sh fails when the ownership of grafana.ini cannot be changed, which means that /etc/grafana/grafana.ini cannot be bind-mounted as read-only.

Specifically, it exits with the error:
chown: changing ownership of '/etc/grafana/grafana.ini': Read-only file system

[johanot]

Bump. Ended up copying grafana.ini into my container image instead of voluming it. Mounting it as RW is not an acceptable option.

[sandersaares]

This remains an issue.

[microbug]

Indeed it does.

[AleksanderGrzybowski]

Any update on this? I'm trying to use this with docker config feature and the same problem appears.

[ahrtr]

Any update on this?

[danh-fissara]

This is happening because the entrypoint script tries to chmod /etc/grafana, which happens to overlap with where the config file is by default.

grafana-docker/run.sh

Line 10 in b96242c

chown -R grafana:grafana /etc/grafana

Looking at what actually gets created there, there's only an ldap config file:

# ls -l
-rw-r-----.  1 grafana grafana 13099 Nov 16 09:48 grafana.ini
-rw-r-----.  1 grafana grafana  3469 Nov 16 09:48 ldap.toml

Question to devs: Is this ownership necessary? AFAIK config under /etc is normally owned by root.

As a workaround, you can mount grafana.ini elsewhere, and use the GF_PATHS_CONFIG env var to override the default. E.g.

docker run -v /root/grafana.ini:/grafana.ini:ro -e GF_PATHS_CONFIG=/grafana.ini grafana/grafana

[microbug]

Working on the assumption that /etc/grafana doesn't need to be read-write, I added read-only support to my Grafana container, which also sorts out the problems with UID/GID differing between host and container. My container builds on grafana/grafana:latest so it should always be up to date.

In testing it seems to work fine with a read-only /etc/grafana mounted. As far as I can tell the only things that get placed in /etc/grafana are grafana.ini and ldap.toml, neither of which should ever be edited by the container, so read-only mounting shouldn't be a problem.

https://github.com/microbug/grafana

[xlson]

Fixed in 291c817

[sandersaares]

I am not so sure about that. Is this really a fix?

Consider:

• I mount /home/whatever/ on the host to /etc/grafana/ in the container.
• I chown the directory and contents as root:root on the host and chmod to user-only access (so only root can view it and the secret credentials within).
• I start the container.

What happens? Startup script does nothing (no chown anymore) but when Grafana itself starts as the container-nonroot-user it cannot access the configuration file because it is chmod so that only root can access it.

The problem is not the chown, it is that Grafana does not run as root inside the container, IMO.

[xlson]

Hi @sandersaares,

There are several problems with how we handle file ownership and what user grafana runs as inside the container that, those issues are being tracked in #141. The issue being dealt with in this issue (#51) is the chowing of /etc/grafana and the problems it causes, as we no longer do that it is resolved.

When it comes to chowing it is something I wish to remove completely, if you volume mount a file system into the container it is your responsibility as a user to make sure that the files and folders within that filesystem has the correct file permissions for Grafana to be able to use them. Currently that is harder to accomplish than neccessary, but not impossible. In the future it should be possible to configure what userid and groupid that Grafana runs as as to make sure that you as a user can easily control file ownership.