Manual Auth Hook Exists But Not Executable

My domain is:

I ran this command:

docker run -it --rm --name certbot \
            -v "${pwd}/etc:/etc/letsencrypt" \
            -v "${pwd}/var:/var/lib/letsencrypt" \
            -v "${pwd}/logs:/var/log/letsencrypt" \
            -v "${pwd}/" \
            certbot/certbot:latest certonly \
            --verbose \
            --manual \
            --non-interactive \
            --agree-tos \
            --email \
            --manual-auth-hook / \
            --manual-cleanup-hook / \
            --domain \

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
manual-auth-hook command / exists, but is not executable.
Ask for help or search for solutions at See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

My web server is (include version): Manual cert

The operating system my web server runs on is (include version): Manual cert

My hosting provider, if applicable, is: GoDaddy

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): cPanel

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 1.19.0

This manual auth script previously worked, but now produces the above output. The script has a line for #!/usr/bin/env python3. On the host, it has executable permissions. Any ideas what has changed?

Hi @stumpylog, welcome to the LE community forum :slight_smile:

Please show:
ls -l /

Are they supposed to execute be the same file?

Maybe I'm oversimplifying the problem here, but isn't that a python script file - while a bash script file is being expected.

The one thing that stands out to me is ${pwd}, which is looking for an environment variable of that name. Perhaps this command is part of a script that creates that variable, but I'm not sure. Double check that you didn't mean $(pwd) or even ${PWD} which is a POSIX shell built-in.

One thing you can try to diagnose this (to see whether it's a Certbot problem or an environment problem) is to invoke the script directly in the Docker environment, e.g.

docker run --rm -it \
-v "${pwd}/" \
--entrypoint / certbot/certbot:latest

Python scripts should work.

Based on the error, my guess is the file just needs a +x bit set.

1 Like

Why would a bash script being expected?

Although I agree it's rather confusing, as the manual speaks about "custom shell scripts" at least once while at other places it just mentions "commands"..

In any case, I don't see a reason why a Python script including a proper shebang wouldn't work.

1 Like

Maybe my misunderstanding; As all script examples shown end with .sh

None-the-less, wouldn't the file need execute permission?
Thus my request to see: ls -l

It probably does, looking at the error :wink:


Maybe that's something to test.
My path would be to make a bash script that calls python
[which should always work]

It's just a misunderstanding. Script examples are historically done as .sh because that is more consistent across environments - Python/Ruby/Perl/etc have not classically been default installations on linux distributions and must be explicitly added. Some distros now load them on, but the barebones ones usually do not.

There are lots of Certbot plugins/projects/etc that use Python scripts on the hooks.

I often prefer to use Python when I can, but shell scripts are often easier for these scripts since they have a streamlined syntax for accessing the environment variables.

Edit: You do need a shebang line on the script to invoke the correct interpreter/executable for the file.

1 Like

Thanks for the quick replies. They are meant to be the same file, using CERTBOT_AUTH_OUTPUT existing or not to handle cleaning up the old validation file.

At least on my host, the script has +x set.

-rwxr-xr-x  1 user user 1.8K Sep 14 14:05*

The script has the shebang line set as #!/usr/bin/env python3. I have also tried #!/usr/bin/python3 to no success.

The usage of ${pwd} might be somehwhat wrong, my own bash scripting isn't great. But since it appears that certbot finds the file, I believe it is working? Unless its a Docker thing, creating an empty directory or file or something. I'll have look at that more.

1 Like

Is that asterisk actually there?

Well, I feel a bit foolish. If I change ${pwd} to $(pwd), everything appears to work as it should. I'm not sure when I made that change, but it was obviously after I last renewed this set of certificates.



Ah, this is just an unfortunate aspect of how Docker mounts volumes.

When you do:

-v "${pwd}/blah:/blah"

The ${pwd}/blah just evaluates to /blah. Docker sees that /blah does not exist on the host, so it creates that directory on the host and then mounts it into the container.

So the path exists, it's just a directory rather than an executable file.

If you look at the root directory on your server, you will probably see an empty directory named /



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