ansible-role-certbot: Permission denied: '/var/log/letsencrypt/.certbot.lock'

I’ve been seeing this coming from the daily cron job:

Cron username@somewhere.example.com certbot renew --quiet --no-self-upgrade

The following error was encountered:
[Errno 13] Permission denied: '/var/log/letsencrypt/.certbot.lock'
Either run as root, or set --config-dir, --work-dir, and --logs-dir to writeable paths.

Seems like it was set up to run as the user, not root?

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 21 (2 by maintainers)

Most upvoted comments

I missed this initially. The README states:

By default, this role configures a cron job to run under the provided user account […]

The run configuration didn’t match whatever was in /etc/cron.d/certbot so it took me a while to reconcile:

/etc/cron.d/certbot, which handles renewals, is supplied by the Debian package (tested on Ubuntu 18.04).
This role installs a cron job in the user’s crontab.
That cron job, the crontab one, fails by default as it’s run by the unprivileged user.

To fix generally, it’s necessary to set certbot_auto_renew_user: root, which perhaps we should be doing by default (although I understand the security implications of forcing users to be explicit about this). However, for Debian-based OSes, renewals should be skipped entirely as this is already handled.

Workarounds

Debian-based OSes

Set the variable certbot_auto_renew: false.

Non Debian-based OSes

Set the variable certbot_auto_renew_user: root.

colans on Jul 30, 2019

The role right now cannot be used to control the schedule or renewal on any system with systemd init. On ubuntu 20.04, there is

systemd certobot service: systemctl status certbot
/etc/init.d/certbot: installed by certbot package. According to the notes in the file, systemd service has precedence
user’s crontab (or crontab of user defined in certbot_auto_renew_user) – installed by geerlingguy.certbot role

The bottom line is that because of 1 & 2, the ansible role as is right now cannot be used to schedule or configure timing of the renewal.

As @colans suggested, use certbot_auto_renew: false and do not use the role’s scheduling as you will only duplicate the renewal job with what’s installed by the certbot package.

It seems that the solution is for the geerlinguy.certbot role to work with systemd’s certbot service as it has precedence over /etc/cron.d/certbot.

fama on May 28, 2021

@zeqk The Debian package handles renewals on its own via the /etc/cron.d/certbot cron job.

colans on Feb 19, 2021

This is actually handled by Pull Request #80. Sadly getting PR through @geerlingguy is difficult because he has so many popular roles

evilhamsterman on Aug 8, 2019