Letsencrypt error: cannot change profile for the next exec call: No such file or directory

My domain is: awards.botany.org

I ran this command: "Request Certificate" via UI in Virtualmin.

It produced this output: Requesting a certificate for awards.botany.org, www.awards.botany.org from Let's Encrypt ..
.. request failed : Web-based validation failed :

cannot change profile for the next exec call: No such file or directory

My web server is (include version): Apache version 2.4.41

The operating system my web server runs on is (include version): Ubuntu 20.04.3

My hosting provider, if applicable, is: AWS

I can login to a root shell on my machine (yes or no, or I don't know): Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): Webmin 1.981/Virtualmin 6.17-3

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
/home/ubuntu# certbot --version
cannot change profile for the next exec call: No such file or directory

The above domain currently has a valid letsencrypt cert on it, but these errors started happening when renewal time started.

Thank you for asking about the certbot --version; that yields the same information so I am concluding that the error message in the Virtualmin UI is about certbot as well. Do I need to reinstall the certbot snap? I have little knowledge of snapd at this point, and no knowledge of what snap dependencies letsencrypt has.


@robbrandt Welcome to the forum.

I see you posted this at the VirtualMin forum and they did not issue that error message.

I do not think you are using Certbot - you would know :slight_smile: But, you are using a Lets Encrypt cert. And, you most recently issued a cert on Oct20. See:

But, your server is not sending it out. It still sends this so maybe need to be reloaded / restarted?

Certificate chain
 0 s:/CN=awards.botany.org
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3

subject= /CN=awards.botany.org
issuer= /C=US/O=Let's Encrypt/CN=R3
notBefore=Aug 20 21:08:18 2021 GMT
notAfter=Nov 18 21:08:17 2021 GMT
SHA1 Fingerprint=26:8F:28:BE:49:96:29:36:C7:29:B3:8F:93:47:0A:62:C2:85:9D:A8

This does not answer your problem as to why your renewal request failed now. Just pointing out further info to help resolve. I am not familiar with VirtualMin at all. You could search this forum for other threads on that and maybe you will find something helpful. This is the most recent:


Thanks, but WHAT needs to be reloaded/restarted? I've restarted apache and Webmin with no change in results.

I see why you say I requested a cert on Oct 20, but the current cert expires on Nov 18, so it's clearly the older one.

I still think this is a snap issue, and would like to know what snap dependencies letsencrypt has.


Sorry to be pedantic but let's clear up some terminology. Lets Encrypt (LE) is a Certificate Authority which issues certs by way of ACME protocol. You need an ACME client on your server to get certs from LE.

So, LE itself has no snap dependencies since nothing it does is on your computer. It is just the client on your system.

Certbot is one such client but there are others. You seem to have used VirtualMin. I see someone else is replying too so hopefully they know more about VirtualMin.


LetsEncrypt does not have any snap dependencies, nor will it run on snap. It is a cloud service available by API.

Certbot is one of the MANY LetsEncrypt clients, and runs on Snap. When installed via snap, it will install it's dependencies. A very early version of Certbot was titled "LetsEncrypt", but it then became it's own project.

What @MikeMcQ is trying to determine with you, is exactly what client you previously used. It appears the VirtualMin application/service handled getting the LetsEncrypt certificate for you; you need to figure out how it did that -- through an internal feature or by calling an external client -- and what external client that is.

It's possible that your system previously used a Certbot snap , and that was somehow uninstalled -- however it is also possible that your system has never used Certbot and used some other client. You can search the configuration files and logs on your system to try and find an answer to this.

I'm sorry this may sound frustrating to you, but the only information people can glean from your posts is that you are using VirtualMin and can't get a certificate. There simply isn't any information suggesting Certbot or another client is involved.


There may be an issue with the two other names included in the cert:

X509v3 Subject Alternative Name: 
  DNS:awards.awstemp.botany.org     <<< HTTPS NOT WORKING !!!
  DNS:awards.botany.org             <<< HTTPS     WORKING
  DNS:www.awards.awstemp.botany.org <<< HTTPS NOT WORKING !!!
  DNS:www.awards.botany.org         <<< HTTPS     WORKING

They are attempted to be served via this wildcard cert (which lacks coverage):

Given: The HTTP authentication requests won't need to connect via HTTPS, it just seems indicative of the lack of coverage by your (VirtualMin) system for those names.


The missing subdomains are a result of me cleaning up my configuration. They were valid last time I had a successful renewal but were targeted for deletion. When I started getting THIS error, I decided the time had come to simplify and removed them. So the renewal of the cert isn't QUITE exactly like the previous one.

1 Like

I'm not exactly sure how VM works, so this may not be the best advice:
But I would remove the HTTPS from it and then immediately add it back.
So that VM only tries to issue a cert for the remaining two names.
Note: This runs the risk of not having a cert at all if VM continues to fail.
[but I'm the gambling type - LOL]

1 Like

A little bit larger screen shot:

Shows that Virtualmin is trying to renew the default domains, and that if I wanted to I could do a custom list of them if the default isn't appropriate. And I can tell you from experience :wink: that when the domains aren't "right" you get an error message that tells you so. So unless there's a brand new bug somewhere, I don't think those recently removed subdomains have anything to do with the issue.

In the meantime, I have confirmed that my system SHOULD be using certbot. I've attempted to verify it's proper installation by uninstalling it and installing it again using the instructions here:

When I get to the step to verify that it' working, I get:
$ sudo certbot --apache
cannot change profile for the next exec call: No such file or directory

Looking to certbot help, I am pointed back to this site https://community.letsencrypt.org/.

Happy to go askubuntu of you all think that's where I should go, but this still looks like a certbot problem.

1 Like

That is very possible.

certbot certificates
[and we'll know for sure]

And show/upload the file:

And for good measure, also show the output of:
sudo apachectl -t -D DUMP_VHOSTS


And, if that fails with same "cannot change profile" error, try this to find it without having to run it
sudo which -a certbot


The "A-" is optional, I always prefer "A+".
And frankly a meager grade IYAM - LOL
"A-" = "B++"
[which is only slightly better than "C++" and hardly no one uses that anymore ROFL]


Are you getting punchy? :slight_smile:


@robbrandt I googled your exact failure message and the top hits both involved a failed apparmor component. I know nothing about it other than these 2 threads describe a remedy for your exact message. The apparmor problem causes other programs to not run with that error shown.

This one (start at bottom and work up - it's long)

And, this one:

Let us know if this tip helped. Otherwise we can look further and we will want to see the outputs suggested by Rudy and me above. Thanks


$ sudo certbot certificates
cannot change profile for the next exec call: No such file or directory

The last entry from /var/log/letsencrypt/letsencrypt.log was from October 22nd, although the automated renewal fails every few hours and I've tried manually at least a dozen times in the last 4 days.

The list of VHOSTS is quite extensive and I'd rather not publish it. Anything in particular you want to focus on?

$ sudo which -a certbot

1 Like
systemctl status apparmor
# "Yup, dead apparmor"
systemctl restart apparmor
snap restart lxd

... didn't help

1 Like

$ sudo lxd --version
cannot change profile for the next exec call: No such file or directory
snap-update-ns failed with code 1

$ microk8s

Command 'microk8s' not found, but can be installed with:

sudo snap install microk8s

$ sudo snap install microk8s
error: This revision of snap "microk8s" was published using classic confinement
and thus may perform arbitrary system changes outside of the security
sandbox that snaps are usually confined to, which may put your system at

   If you understand and want to proceed repeat the command including

I'll stop right here because it seems significant.

1 Like

Can you show the result of this:

sudo systemctl status apparmor

Do not bother with lxd or microk8s. In those other trouble reports those programs were being prevented from running just as certbot is in yours. We need to find the underlying reason for that. So far apparmor is the only candidate.


Any vhosts related to the names trying to renew.

1 Like

● apparmor.service - Load AppArmor profiles
Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor preset: enabled)
Active: active (exited) since Tue 2021-11-02 05:52:20 UTC; 10h ago
Docs: man:apparmor(7)
Home · Wiki · AppArmor / apparmor · GitLab
Process: 2905846 ExecStart=/lib/apparmor/apparmor.systemd reload (code=exited, status=0/SUCCESS)
Main PID: 2905846 (code=exited, status=0/SUCCESS)

Nov 02 05:52:19 ip-172-30-0-148 systemd[1]: Stopped Load AppArmor profiles.
Nov 02 05:52:19 ip-172-30-0-148 systemd[1]: Starting Load AppArmor profiles...
Nov 02 05:52:19 ip-172-30-0-148 apparmor.systemd[2905846]: Restarting AppArmor
Nov 02 05:52:19 ip-172-30-0-148 apparmor.systemd[2905846]: Reloading AppArmor profiles
Nov 02 05:52:20 ip-172-30-0-148 apparmor.systemd[2905861]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd
Nov 02 05:52:20 ip-172-30-0-148 systemd[1]: Finished Load AppArmor profiles.

1 Like