PermissionError: [Errno 1] Operation not permitted

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: 271.ch, ....

I ran this command:

certbot certonly \
  --config-dir /some_path \
  --work-dir /some_path \
  --cert-path /some_path \
  --key-path /some_path \
  --fullchain-path /some_path \
  --chain-path /some_path \
  --logs-dir /some_path/log \
  --agree-tos --email a@example.com \
  --cert-name my-certificates \
  --dns-rfc2136 --dns-rfc2136-credentials letsencrypt.conf.ini \
  --server https://acme-v02.api.letsencrypt.org/directory \
  -d example.com -d '*.example.com' \
  -d example2.com -d '*.example2.com' \
  -d example.info -d '*.example.info'

It produced this output:

Saving debug log to /some_path/log/letsencrypt.log
Requesting a certificate for glyphing.com and 17 more domains
An unexpected error occurred:
PermissionError: [Errno 1] Operation not permitted: '../../archive/my-certificates-0012/cert1.pem' -> '/some_path/live/my-certificates-0012/cert.pem'

Note that all 17 domains have been successfully validated.

I always got some error, but the private key was written in the correct folder, then I copied it together with 3x certificates from the log. The concatenated 4 certificated where c&p on HAproxy.
Now the private key is missing (the other 3 certs are stil generated).

certbot --version : 2.6.0

All other questions are not relevant since it is a manual execution, rfc2136, on my fedora notebook.

Questions:

  • is it a file permission problem? why is the check done at the and (after waiting 60 seconds) instead of checking at the start? because of what seems a local problem I have lost my 5 attempts in 168 hours
  • if all my configurations are absolute paths, why the error message use a relative path? relative to what?
  • I use certbot with this settings since 2021, what breaking change has been made since April 2023?
  • all dirs are owned by my user and I execute certbot using my user

thank you for your advice

2

What filesystem does that /some_path/ reside on? According to python - PermissionError: [Errno 1] Operation not permitted: 'file.txt' -> 'symlink.txt' while using os.symlink - Stack Overflow this error when symlinking is due to a filesystem not supporting symbolic links.

It's not a "check". It's one of the non-optional operations in the Certbot process that usually (read: almost always) works fine, but in your case for some reason it doesn't.

The symbolic link from /live/ to /archive/ uses relative links.

None, Certbot has always used symbolic links for this purpose.

6 Likes
3

Thank you very much. Issue solved.
I use veracrypt.
Because of the chnage in behaviour, one of the following has changed since April 2023: certbot, python, veracrypt.
But since veracrypt has had no update, the change must come from one of the other two.

1 Like
4

Veracrypt is not a filesystem of its own: a Veracrypt "container" (if you will) needs to be formatted with a specific filesystem, e.g. FAT, Ext4 or NTFS.

1 Like
5

I agree. mount says vfat.

1 Like
6

Yeah, FAT doesn't have symbolic link support.

Have you always used Certbot on that FAT filesystem earlier? As that shouldn't have worked in the first place.

4 Likes
7

You write

Have you always used Certbot on that FAT filesystem earlier? As that shouldn't have worked in the first place.

The answer is yes, and because of that reason I say that something has changed.
The symlink must always have been an issue, but the pem file in keys folder (private key) has always been written raw.

From a logical point of view I see two possibilities:

  1. there has been a change in how keys/my-certificates-0013.pem is written (from raw to symlink)
  2. there has been a change in the order how files are written/symlinked, thus the error blocks now keys/my-certificates.pem to be written

But at this point, this is a pure philosophical question :slightly_smiling_face:

8

Aaah, so you always have gotten that PermissionError? I thought your question was actually about this error..

Well, if you're actually using the files from the /keys/ directory: that directory isn't used any longer, as it was never used by Certbot itself. See https://github.com/certbot/certbot/blob/master/certbot/CHANGELOG.md#230---2023-02-14 for the changelog entry about that.

All the files you require are in the /archive/ directory.

3 Likes
9

Yes (I always had an error) and no (at the end I always got all my certs).
As I wrote, I copied the public keys from the log, but the private key have been written in the keys folder at least until April 2023

10

Thank you for the link! There is documented:

Certbot will no longer save previous CSRs and certificate private keys to /etc/letsencrypt/csr and /etc/letsencrypt/keys, respectively. These directories may be safely deleted.

1 Like
11

Yeah, you wrote:

(…) the private key was written in the correct folder (…)

You didn't mention you were using the /keys/ directory though :slight_smile: It's quite unusual to use the /keys/ directory and the requirement to fetch the certs from the log, as everything should be available in the /archive/ directory. I don't think the PermissionError should affect that?

Edit: According to the code indeed the files are first saved to /archive/ in the function save_successor() and after that the symbolic links are updated in the function update_all_links():

You should be able to use /archive/?

3 Likes
12

Basically I had the permission error, but also my workaround that allowed me to put together the whole cert chain until the change. I never thought about the symlink.
From now on I'll be able to use the correct method and save me time. Thank you.

1 Like
13

After a look at /archive/ I see that all its subfolders were empty, only the one generated today after copying everything in ext4 is not.

14

I don't see how anything would be placed in /archive/; As you've reassigned everything elsewhere:

3 Likes
15

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