Cannot install SeaTable - Nginx / Letsencrypt Troubleshooting

I cannot install seatable any more. I tried to install Enterprise edition. Followed instructions from here:

docker login is not possible, but docker pull was possible without any login

when running: docker-compose up
there is a warning:
Aborted connection 3 to db: ‘unconnected’ user: ‘root’ host: ‘’ (Got an error reading communication packets)
after that I come to “idle script” … after “ctrl + c”

I tried to run docker-compose up -d

the problem is: there is no nginx.conf, no ssl configuration…
in /opt/seatable/seatable-data/seatable/conf.
any help?
(ubuntu 20.04.2)
here is my docker-compose.yml

(xyz = placeholder for my environment)

version: ‘2.0’
image: mariadb:10.5
container_name: seatable-mysql
- /opt/seatable/mysql-data:/var/lib/mysql
- seatable-net

image: memcached:1.5.6
container_name: seatable-memcached
entrypoint: memcached -m 256
- seatable-net

image: redis:5.0.7
container_name: seatable-redis
- seatable-net

image: seatable/seatable-ee:latest
container_name: seatable
- “80:80”
- “443:443”
- /opt/seatable/seatable-data:/shared
- DB_HOST=db
- TIME_ZONE=Europe/Berlin
- db
- memcached
- redis
- seatable-net


the error from docker login is:
Error response from daemon: Get unauthorized: please use personal access token to login

Hello @benjamin.friedrich, welcome to the SeaTable forums.

There was a recent change on Docker Hub for the credentials of SeaTable Enterprise.

Temporarily please use your own Docker Hub credentials (or try anonymous but you might run into Docker Hub rate limitations).

If there are further changes we’ll communicate them here in the forums as well.

Please let me know if this solves your issue.

No, install failes.
The problem ist that no nginx is installed / working.
Screenshot 2021-04-13 141852

also “reload nginx” results in:
“/etc/nginx/sites-enabled/default” failed (2: No such file or directory) in /etc/nginx/nginx.conf:25

Did you do fresh install or are you doing an upgrade? In case of an upgrade, what was the previous version?

It is a fresh install

I reinstalled the complete system once again. after docker compose up the log files tells:

Auto init letsencrypt failed, delete nginx config anyway.
Please check your Domain and try again later, now quit.


SEATABLE_SERVER_LETSENCRYPT=False -> seatable runs but without ssl…

Looks like a good pointer and would explain why Nginx can’t start afterwards.

You can give it a try with SEATABLE_SERVER_LETSENCRYPT=False when installing to see if that part is causing it.

And you’re doing it faster than I can do the typing. Let me try to reproduce it.

I could reproduce, at least what I think your issue is.

Please check the init-log seatable-data/seatable/logs/init.log, it should show the details about initializing lets encrypt. Right before the lines you reported a few comments ago:

A common issue is that the domain in use is not accessible from the lets encrypt service ( It then can only fail.

So please check your Domain if it is publicly connected to DNS and routing to the container works. This is necessary, otherwise Letsencrypt can not verify and no certificate is created. For example if DNS is not working, you may see a message similar to the following in the init-log:

ValueError: Challenge did not pass for […] DNS problem: NXDOMAIN looking up A for - check that a DNS record exists for this domain

If that is not an option, you can create and use your own certificate if you’re looking for TLS/HTTPS suppor nevertheless. A description on how to do this is available in SeaTable Admin Manual: If you want to use your own SSL certificate, you can refer to the following steps (scroll to that sentence).

Hey everybody,
I also experienced that I ran into some letsencrypt limits after recreating a demo-site every day.
So my bet is:

The seatable log will give you more insights.

Best regards

hm…may be i am running into the limits…I will give it a another try in a few days…
what is interesting for me is: once started the docker compose up. A certificate request is created:

but after a few second it is deleted (+ the nginx config file…)

the log file tells:
mysql server is ready
Init sql success
Generating RSA private key, 4096 bit long modulus (2 primes)
e is 65537 (0x010001)
Generating RSA private key, 4096 bit long modulus (2 primes)
e is 65537 (0x010001)
Can’t load ./.rnd into RNG
140477038547968:error:2406F079:random number generator:RAND_load_file:Cannot open file:…/crypto/rand/randfile.c:88:Filename=./.rnd
Parsing account key…
Parsing CSR…
Found domains:
Getting directory…
Directory found!
Registering account…

Creating new order…
Order created!
Traceback (most recent call last):
File “/templates/acme-tiny-master/”, line 141, in get_crt
assert (disable_check or _do_request(wellknown_url)[0] == keyauthorization)
File “/templates/acme-tiny-master/”, line 46, in _do_request
raise ValueError("{0}:\nUrl: {1}\nData: {2}\nResponse Code: {3}\nResponse: {4}".format(err_msg, url, data, code, resp_data))
ValueError: Error:
Data: None
Response Code: None
Response: <urlopen error [Errno 111] Connection refused>

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File “/templates/acme-tiny-master/”, line 198, in
File “/templates/acme-tiny-master/”, line 194, in main
signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, log=LOGGER,, disable_check=args.disable_check, directory_url=args.directory_url,
File “/templates/acme-tiny-master/”, line 143, in get_crt
raise ValueError(“Wrote file to {0}, but couldn’t download {1}: {2}”.format(wellknown_path, wellknown_url, e))
ValueError: Wrote file to /var/www/challenges/j4eaYmd7pLKUZAwvCsFs9Sa1txZT6Y2GvFzq7Op4ZPA, but couldn’t download Error:
Data: None
Response Code: None
Response: <urlopen error [Errno 111] Connection refused>

Auto init letsencrypt failed, delete nginx config anyway.
Please check your Domain and try again later, now quit.

the ping on subdomain result is ok. so the ip/domain points to the server and is reachable.

Problem resolved…
First: DNS ip adress was cached before - Hoster updated dns route very late. (this caused the “not reachable” in my first post…)
Second: I missed two linux commands before running docker-compose up:

ufw allow 443
ufw allow 80

I missed that because running docker-compose up without “let’s encrypt=True” runs the server in http mode without any issue…so i wasn’t aware I had to open port manually 443 within iptables/ufw

Thank you for your help.

Good to read you could setup everything according to your needs!

Maybe some information to add as you asked yourself if this may have been LE rate limits related and there were more some comments about it earlier:

If ACME/LE rate limits are a cause of error, the error message states such. It would look like something along the following lines:

Response Code: 429
Response: {‘type’: ‘urn:ietf:params:acme:error:rateLimited’, ‘detail’: ‘Error creating new order :: too many failed authorizations recently: see’, ‘status’: 429}

You would also not need to take a week off, just hitting it at an early stage, especially if early connectivity or DNS setup is still brittle, the limits are not that harsh:

There is a Failed Validation limit of 5 failures per account, per hostname, per hour.

So this would set you on an extended coffee-break with a walk to a good bakery for some nice cake. Or to read the link about LE rate-limits given in the error message.

Some more commands to test for connectivity on the host and also from within the container:

$ docker exec seatable /bin/sh -c 'curl -IvsS "$SEATABLE_SERVER_HOSTNAME"/' | head -1
*   Trying
HTTP/1.1 502 Bad Gateway

The same curl command can also be run on the host.:

$ curl -IvsS | head -1
*   Trying ...
HTTP/1.1 502 Bad Gateway

In both cases I would expect that they give a 502 as long as nginx.conf is not there (which is fine. This is the default and is before Nginx has been fully configured, e.g. before LE ran through. Nginx then runs in a limited mode to allow ACME Tiny to do the LE HTTP challenge/response).

Depending on DNS resolution for the hostname, the second curl command may have revealed that the WAN IP was still propagating and/or iptables not being configured to allow access on the ports, but that would be more clear when accessing from a remote host, as when the routing is only on the host, it would only check the connectivity into the container which is normally not an issue (but perhaps a good test in trouble-shooting).

DNS can be especially tricky as it is cached at multiple places. Curl can help here by requesting with the hostname but also tell curl which IP to use, so you can test for e.g. the firewall configuration before DNS propagation went through, e.g. for port 80 and 443 (HTTP/HTTPS). It is the --resolve <host:port:addr> argument (there is more info on the curl blog):

$ curl -IvsS --resolve | head -1
* Added to DNS cache
* Hostname was found in DNS cache
*   Trying
* connect to port 80 failed: Network is unreachable
* Failed to connect to port 80: Network is unreachable
* Closing connection 0
curl: (7) Failed to connect to port 80: Network is unreachable

Just in case this is helpful for future visitors.

Have fun with your new SeaTable setup. And welcome again to the SeaTable forums!