With SFTP Gateway, you may encounter the following error in the web admin UI:
localhost:636 Connection refused
The first troubleshooting step is to restart the LDAP service.
If the problem persists, follow along with the rest of this article
to see if the VM is even listening on port
Otherwise, email us at
email@example.com and we can help
troubleshoot the issue.
SFTP Gateway uses LDAP behind the scenes. And LDAP runs on port 636.
If LDAP is down, the
sftpgw-admin-api service will fail, and the
web admin UI will give a red error message on the top right.
You can get the status of the LDAP service with the following commands:
sudo su HOSTNAME=$(hostname | cut -d"." -f1) systemctl status dirsrv@$HOSTNAME
Note: The commands above are just a fancy way of running
systemctl status dirsrv@ip-172-31-4-199,
or whatever your Private IPv4 DNS hostname is (without the
.ec2.internal domain suffix).
If LDAP is down, you can restart it:
systemctl restart dirsrv@$HOSTNAME
At this point, you can refresh your web admin UI browser. If it's working, then you have solved the problem.
Diagnosing the issue further
If the LDAP service is
active, but you're still seeing the
error, then keep reading.
The LDAP service runs on two different ports:
389: This is normally used for clear text LDAP. But you can also run
start_tls, which is TLS over 389. This is what we use for the
ldapsearchCLI, which depends on
636: This is the LDAP service used by Java.
To determine which ports are running on your VM, run this command:
You should see the following output on a healthy VM:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp6 0 0 :::636 :::* LISTEN 2571/ns-slapd tcp6 0 0 :::389 :::* LISTEN 2571/ns-slapd
And you should see the following output on a VM that didn't get to finish its initial configuration:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp6 0 0 :::389 :::* LISTEN 2571/ns-slapd
If you see the latter, please email us at firstname.lastname@example.org.
This may be the result of running an underpowered EC2 instance (we recommend
t3.medium or better),
and the first time initialization did not have enough memory to