rabbitmq restarts over and over with /config/ bind mount target on windows

[quarky42]

• Nico640/docker-unms 2.4.188
• WSL2 2.4.12.0 (latest: wsl --update --web-download)
• Ubuntu 24.04 (latest sudo apt-get update && sudo apt-get upgrade -y
• Docker version 28.0.1, build 068a01e

Error in unms-uisp container logs:
"Cookie file /var/lib/rabbitmq/.erlang.cookie must be accessible by owner only"

RabbitMQ restarts over and over.

rabbitmq_snippet.log

docker-compose.yml.txt

Exec'ing into the container docker exec -it unms-usip /bin/bash and chmod 700 /var/lib/rabbitmq/.erlang.cookie does not result in any change to the permissions on the cookie file. That file still shows node:node 777 as the ownership and permissions.

rm /var/lib/rabbitmq/.erlang.cookie was successful, but same behavior / error over and over when I restart the container.

Looking at your Dockerfile, I can see that /var/lib/rabbitmq is being created without permissions explicitly set. See: https://www.google.com/search?q=permissions+for+%22%2Fvar%2Flib%2Frabbitmq%22
/var/lib/rabbitmq directory should have permissions set to 755
.erlang.cookie file should have permissions set to 600

Digging a bit deeper, this is being caused by my docker-compose.yml mapping into the /config/ directory. On Windows, Docker Compose bind mounts do not support file permissions. There has been some discussion of Docker adding an opt-in feature for better explicit permission control, but it isn't ready yet. This has been a long standing issue for years that has impacted my own development work because the documentation was really inadequate.

It looks like /config/ is where the rabbitmq .erlang.cookie file ends up. If that cookie could be allowed to go to an image filesystem path or even a named volume, instead, then the permissions on that file could be correct in an environment like this.

I get that maybe running docker-unms on Ubuntu on WSL2 on Windows is not the preferred way to run it. Is there a strong need to have the .erlang.cookie in the config directory bind mount? Or maybe an alternative recommended setup using named volumes?

[quarky42]

After changing my docker-compose.yml to this:

services:
  unms:
    image: nico640/docker-unms:latest
    container_name: unms-uisp
    hostname: uisp.bustedchain.com
    environment:
      - TZ=US/Mountain
      # Filenames of custom cert and key files in /config/usercert/
      - SSL_CERT=fullchain.pem
      - SSL_CERT_KEY=privkey.pem
    ports:
      - 2055:2055/udp
      - 443:443
      - 80:80
    restart: always
    volumes:
      - /root/unms-uisp/config/:/config/

I booted up. Still had the same error, so I exec into the image, and this time changing permissions on the file works. Having the config file stored inside my running WSL Distribution is not ideal, but I can live with it for now. I just need to make sure I setup a backup job that will export it out for safe keeping.

[quarky42]

This is an updated docker-compose.yml file I am using now. It is working well with loading the config directory from a linux path under WSL and not a /mnt/C/<DIR>/<PATH>

docker-compose.yml.txt

I am using tmpfs for the uisp logs and have some logging limits on the docker logging driver as well.

[quarky42]

OBE, see next post. I tried deleting the cookie and it allowed my container to boot up with absolutely no data in it.

[quarky42]

Well, that failed miserably. Deleting that cookie file allows my restored backup to boot as if there is absolutely no data there. :(

Guess that key is needed to unlock stored data?

[quarky42]

Ok, this fixes that error without deleting the file:

docker exec unms-uisp chmod 400 /var/lib/rabbitmq/.erlang.cookie assuming your docker container is named unms-uisp

Adding that chmod 400 to the start script would be really helpful and prevent this error. I'll take a look at saving file permissions better as that seems to be getting lost when the file is restored.

The root of this issue is in having difficulty restoring backups. I loaded the 2.4.220 image, ran it, restored a backup that was made with 2.4.220, and it won't boot up. I see it loading the database and then it forever just fails to connect and the UI fails to load beyond saying that it will boot up in a minute.