PermissionError: [Errno 13] Permission denied: '/root/cloudflare.ini'

Help
1

I am running certbot via docker-compose service for my web application and getting permission denied trying to read the cloudflare.ini mounted from the host at /etc/cloudflare/cloudflaire.ini to the image at /root/cloudflare.ini. Based on logs the nightly renewal check was working fine for months until until 3/5/24 and I am not sure why. I tried running as the same UID as the host which is "1000:1000" but there is no UID with 1000 on the certbot image since I believe it is running as root. How can I troubleshoot this? Is there a Dockerfile somewhere for the certbot/dns-cloudflare image?

  certbot:
    image: certbot/dns-cloudflare
    volumes:
      - certbot_etc:/etc/letsencrypt
      - /etc/cloudflare/cloudflare.ini:/root/cloudflare.ini
    command: >-
      certonly --dns-cloudflare
      --dns-cloudflare-credentials /root/cloudflare.ini
      --dns-cloudflare-propagation-seconds 60
      --email contact@example.com
      --agree-tos --no-eff-email
      --keep-until-expiring

logs:

certbot-1  | Saving debug log to /var/log/letsencrypt/letsencrypt.log
certbot-1  | Renewing an existing certificate for example.com and *.example.com
certbot-1  | An unexpected error occurred:
certbot-1  | PermissionError: [Errno 13] Permission denied: '/root/cloudflare.ini'
certbot-1  | Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
2

how about temporally set it as 666 and watch what user and process certbot access it as?

3 Likes
3

I'd suggest just not storing your credentials config under /root - how about /usr/share/cloudflare or something similar? You can use something like docker run --entrypoint "/bin/sh" -it certbot/dns-cloudflare to run the container without exiting, which gives you a chance to inspect the filesystem.

2 Likes
4

That would suggest world readability which is a bad idea.

1 Like
5

Agree, but my impression was that lack of readability was specifically the problem.

@letsmax regarding the dockerfile, you can see the layers here: Docker

The actual base image is alpine 3.18 docker-alpine/x86_64/Dockerfile at 08dbcabbd55e7430a326b582e544c6e1695126f3 · alpinelinux/docker-alpine · GitHub with python: python/3.12/alpine3.18/Dockerfile at eba24df439d48988302a60cf9ef5cddd5d49b51f · docker-library/python · GitHub

Here is the dockerfile that's part of certbots build pipeline: certbot/tools/docker/Dockerfile at f4e031f5055fc6bf8c87eb0b18f927f7f5ba36a8 · certbot/certbot · GitHub

2 Likes
6

Readability problem, sure, but never ever make your DNS API access credentials readable to everybody. Unless you want your DNS zone hacked :wink:

That said, I have no clue how permissions and Docker work, so no solution from me I'm afraid.

1 Like
7

As an aside, it's a shame the DNS providers haven't attempted to settle on a single common API for acme challenge TXT updates, then at least the potential risk would be limited to answering challenges.

2 Likes
8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.