Authorization issues when using docker-compose

InfluxDB 2
,
1

Hi - I am using docker-compose to connect my Python application’s container to an InfluxDB container and am experiencing authorization errors (the response is {"code":"unauthorized","message":"unauthorized access"} and I also see "authorization not found" in the InfluxDB container logs.

Initially, my app container is able to connect to the InfluxDB container via http://influxdb:8086 using the credentials supplied as environment variables in the compose YAML (this actually worked all day today, but then suddenly stopped working), but at some seemingly arbitrary point I eventually start to encounter the auth errors. When I try to login via the UI at localhost:8086 I see a "Could not sign in" alert.

I can use those same credentials to run an InfluxDB container alone:

docker run -p 8086:8086 -e DOCKER_INFLUXDB_INIT_MODE=setup \
-e DOCKER_INFLUXDB_INIT_USERNAME=someuser \ 
... influxdb:2.0.7

and successfully connect/authenticate (both from my app and via the UI). It seems like the authorization only fails when using docker-compose.

Here is the InfluxDB service in my compose YAML:

influxdb:
    image: influxdb:2.0.7
    secrets:
      - influx_user
      - influx_password
      - influx_token
      - influx_org
      - influx_bucket
    environment:
      - DOCKER_INFLUXDB_INIT_MODE=setup
      - DOCKER_INFLUXDB_INIT_RETENTION=1w
      - DOCKER_INFLUXDB_INIT_USERNAME=/run/secrets/influx_user
      - DOCKER_INFLUXDB_INIT_PASSWORD=/run/secrets/influx_password
      - DOCKER_INFLUXDB_INIT_ORG=/run/secrets/influx_org
      - DOCKER_INFLUXDB_INIT_BUCKET=/run/secrets/influx_bucket
      - DOCKER_INFLUXDB_INIT_ADMIN_TOKEN=/run/secrets/influx_token
    ports:
      - 8086:8086
    volumes:
      # - influxdb_data:/var/lib/influxdb
      - influxdb_data:/root/.influxdbv2
    healthcheck:
      test: "exit 0"
    networks:
      - net

I am using docker volumes to persist data and was experimenting with changing the volume mount location, which is why there is a line commented out under the volumes param. I do not understand why this is happening and would appreciate any suggestions. Thank you for your time and consideration.

2

Seems to be an issue with the docker-compose secrets. I can see that they are mounted in the InfluxDB container, but they don’t work in terms of authenticating. It works if I just hardcode the password, token, etc. Not sure why the secrets don’t work.

3

@erm1249 from what I understand, secrets in a compose file get mounted into the container as a text file and not as environment variables. The influxdb container doesn’t currently support reading in variables from files like that so I’d imagine that’s why it isn’t working. In your example, I would guess that the username is literally the string /run/secrets/influx_user rather than the contents of that file.

4

Stumbled across this today, after a long time trying to troubleshoot my Docker container. It’s March 26, 2025, and this little post from Dec 2021 is what finally solved my ongoing frustration. Made an account just to reply here…

wbaker is right: Compose secrets are not read into environment variables. It’s using the path as a literal string.

Compose file:

environment:
    - INFLUX_TOKEN=/run/secrets/influx_token

secrets:
    - influx_token # file is setup in other dedicated compose

I went into the container and tested. Summarized the gist of the outputs below.

bash, inside the container:

> influx server-config
...401 auth error response

> env
...INFLUX_TOKEN=/run/secrets/influx_token

> export INFLUX_TOKEN="$(cat /run/secrets/influx_token)"
> env
...INFLUX_TOKEN=abcdefghijklmnopetcetcetc......

> influx server-config
...all the information you could ever hope for

SO. If anyone else is struggling out there and wondering why your secrets are not working, but hardcoding is…yep. Needs some extra love and care within the container to get those working, but it is possible.

Hope this helps other people with similar headaches find relief. And please let me know if this has been solved and is handled differently at all today, but I have been Googling the hell out of the internet and re-re-reading documentation, and this is the only post that led me to a solution.