missing folder fails the script.

[pmkyl]

it cannot find folder dhparams, and script fails. On ubuntu 20.04

mkdir -p nginx_secrets/dhparams

[JonasAlfredsson]

Hi,

Could you please share how you start your container.
Do you use a Docker run command, docker-compose or something else?

It sound like you are creating a bind mount, which will obscure the existing content inside the container. In that case you will need to either manually create that folder before startup, or you could create a startup script like this:

mkdir -p /etc/letsencrypt/dhparams

name it something like 10-create_dhparam_folder.sh and place it inside the /docker-entryoint.d/ folder.

//Jonas

[pmkyl]

Hello,
I was using command from the example in the readme file:

docker run -it -p 80:80 -p 443:443 \ --env [email protected] \ -v $(pwd)/nginx_secrets:/etc/letsencrypt \ --name nginx-certbot jonasal/nginx-certbot:local

And, I had no mounting folder in the working directory, it was clean. I just tried that again to make sure, and it doesnt work:

I have made a container like this:

FROM jonasal/nginx-certbot:latest   

COPY conf.d/* /etc/nginx/conf.d/

root@node1:~/temptest# docker run -p 80:80 -p 443:443 --env [email protected] -v $(pwd)/nginx_secrets:/etc/letsencrypt --name nginx-certbot docker.pkg.github.com/pmkyl/rb_nginx/rb_nginx:cb01-1
Couldn't find keyfile '/etc/letsencrypt/live/rb.codes/privkey.pem' for '/etc/nginx/conf.d/rb.codes.conf'
Couldn't find fullchain '/etc/letsencrypt/live/rb.codes/fullchain.pem' for '/etc/nginx/conf.d/rb.codes.conf'
Couldn't find chain '/etc/letsencrypt/live/rb.codes/chain.pem' for '/etc/nginx/conf.d/rb.codes.conf'
Couldn't find dhparam '/etc/letsencrypt/dhparams/dhparam.pem' for '/etc/nginx/conf.d/rb.codes.conf'
Important file(s) for '/etc/nginx/conf.d/rb.codes.conf' are missing, disabling...
Starting the Nginx service
Starting the certbot autorenewal service
RENEWAL_INTERVAL unset, using default of '8d'
Couldn't find the dhparam file '/etc/letsencrypt/dhparams/dhparam.pem'; creating it...
DHPARAM_SIZE unset, using default of 2048 bits

    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    %                        ATTENTION!                       %
    %                                                         %
    % This script will now create a 2048 bit Diffie-Hellman   %
    % parameter to use during the SSL handshake.              %
    %                                                         %
    % >>>>>      This MIGHT take a VERY long time!      <<<<< %
    %    (Took 65 minutes for 4096 bit on an old 3GHz CPU)    %
    %                                                         %
    % However, there is some randomness involved so it might  %
    % be both faster or slower for you. 2048 is secure enough %
    % for today and quite fast to generate. These files will  %
    % only have to be created once so please be patient.      %
    % A message will be displayed when this process finishes. %
    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    
Will now output to the following file: '/etc/letsencrypt/dhparams/dhparam.pem'
Can't open /etc/letsencrypt/dhparams/dhparam.pem for writing, No such file or directory
139674556036224:error:02001002:system library:fopen:No such file or directory:../crypto/bio/bss_file.c:69:fopen('/etc/letsencrypt/dhparams/dhparam.pem','w')
139674556036224:error:2006D080:BIO routines:BIO_new_file:no such file:../crypto/bio/bss_file.c:76:

[JonasAlfredsson]

Ah, excellent. Thank you for all the information, I see now why this happens.

The certbot program has a default set of folders which it creates if any are missing. The dhparam folder is just made up by me as an example and is not covered in this "recreation" process.
This becomes a problem when, as you do, just bind mount a folder on top of /etc/letsencrypt and certbot manages this empty folder structure but my dhparam creation script fails.

A suggestion might be that I include the 10-create_dhparam_folder.sh startup script inside the official release, which always created this dhparam folder, but this means that some people, who perhaps would like to use a completely different folder, will have to live with this being recreate at every container start. A small annoyance, but having it as a startup script will allow those who really don't want it to remove the file. This is probably the best way forward.

[JonasAlfredsson]

Thank you for reporting this, it made me find another bug as well!
I just pushed a fix for this, and it seems to be working for me™, but please check if it works for you too :)

[pmkyl]

Hello,
Thanks for looking into it, I will test it later today !

[pmkyl]

Works perfect ! Thanks alot ! 👍