Connection aborted. OSError 107

I successfully generated my certs, however i want to setup a cron job for renewal and get an error on the dry-run, “(‘Connection aborted.’, OSError(107, ‘Transport endpoint is not connected’)). Skipping.”

My domain is: (about 10 additional domains in the cert)

I ran this command: certbot renew --dry-run

It produced this output:
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator nginx, Installer nginx
Attempting to renew cert ( from /etc/letsencrypt/renewal/ produced an unexpected error: (‘Connection aborted.’, OSError(107, ‘Transport endpoint is not connected’)). Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/ (failure)

My web server is: nginx/1.14.0 (Ubuntu)

OS: Ubuntu 18.04.3

I have full root access to the machine using certbot 0.31.0.

1 Like

I’ve got no idea, but could you post the log from /var/log/letsencrypt/letsencrypt.log?

Can we also see this file?:
[you can hide any account numbers]

here you go.

renew_before_expiry = 30 days

version = 0.31.0
archive_dir = /etc/letsencrypt/archive/
cert = /etc/letsencrypt/live/
privkey = /etc/letsencrypt/live/
chain = /etc/letsencrypt/live/
fullchain = /etc/letsencrypt/live/

Options used in the renewal process

account = xxx
authenticator = nginx
installer = nginx
server =

Nothing mysterious there...
Are you still using nginx?
You didn't go over to the dark side? - LOL

Did you recently remove an IPv6 entry for that name (or www)?

Hi @srulikuk

searching that error -> problems with your harddisk or mount points.

(Easiest) Solution: Reboot your server.

Its a fresh installation only for certbot, still using nginx
I started having problems renewing on my old ubuntu 14.04 installations in the last few weeks
(~# curl -4
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to
So i made this fresh install for the sole purpose of creating and renewing the certs.

On the same disk(s) as before?

No, its a new VM ubuntu 18.04

But is it in the same hyper-visor host?
[using the same disk(s)]

Are they local or remotely mounted disks?

Yes same host, are you saying I should try to reboot the host? (that’s really a last case for me)

I wouldn't got there just yet...
Can you check the drive subsystem?
Any alarms/failures/etc. related to disk access?
Can you inspect them visually?
[a lot of times you can see rows of green blinking lights and the one red/yellow/orange light crying for help!]

Please use Google and read some of the results.

One of your mount points doesn't work, so it's not a problem of a program. Instead, it's a problem of your hardware. Unmounting in a running system may be more critical then rebooting the system.

In a perfect world, he would be using a hot-swappable drive subsystem.
And only one drive is going bad in a raid5 system and it’s just pull one out and put a new one in.
But you may be right, I may be crazy.
[Billy Joel in my head now]

1 Like

I am using hot-swappable but the world still aint perfect :wink:
I don’t have physical access to the server at the moment but I used “hpacucli” to check the condition of the 8 drives and the array, all reported “OK”.
Cant see anything relevant in logs.
If its a mount point a reboot of the VM should have resolved it.
I will play google for a little longer and if no joy I will reboot the server later.

1 Like

Best of luck :slight_smile:
You should run some sort of disk benchmark tool to prove its condition.
[perhaps a driver was recently updated and BAM!]

I tested all the drives today (removed 1 by 1 and created some large files and allowed the raid to rebuild, all without issue.)
Rebooted now and issue remains.
what a shame that i broke this record ->
root@serv-0:~# uptime
20:30:34 up 1196 days, 20:26,

Form my google searches I did not find anywhere that’s its hardware / mount point related, all i found is its problem in the python code.

Any ideas please?

And we start again... :slight_smile:

Force the renewal challenge location to a less used and 100% stable path...?

Not sure what you mean

The “default” location for the challenge file is /your/document_root/.well-known/acme-challenge/
This can be overridden to any location via an nginx location statement.

With something like this in your port 80 vhost config:

 location /.well-known/acme-challenge/ {
  root /some/stable/path/; #<<<change that to your specific location
  try_files $uri =404;