Synology docker ...Network error Could not connect to the API server

I still have a worry as “templates” aren’t shown, and there is no error’s message… I’m still searching the root cause for this, but it seems related to access’ rights and permissions…

This might be because the BASEROW_TRIGGER_SYNC_TEMPLATES_AFTER_MIGRATION is not equal to true. If false, then the templates won’t be installed on startup. It can sometimes take a couple of minutes before the templates are installed.

How can this be fixed ?

To help you further, you would have to explain in much detail how you’re currently running Baserow. Which Docker image, which ports are opened, which environment variables, whether you’re using internal/external PostgreSQL and Redis. Please be as detailed as possible.

Would you mind posting a properly indented version of your Docker compose configuration? Then I can try to replicate your problem locally.

Hi @bram, here’s correctly formatted file. THanks, have a nice day

version: "3.9"
services:
  redis:
    image: redis:7.2
    command:
      - /bin/sh
      - -c
      - redis-server --requirepass *
    container_name: Baserow-REDIS
    hostname: baserow-redis
    mem_limit: 256m
    mem_reservation: 50m
    cpu_shares: 768
    security_opt:
      - no-new-privileges:true
    read_only: true
    user: 1026:100
    healthcheck:
      test: ["CMD-SHELL", "redis-cli ping || exit 1"]
    volumes:
      - /volume1/docker/baserow/redis:/data:rw
    environment:
      TZ: Europe/*
    restart: on-failure:5

  db:
    image: postgres:16.0
    container_name: Baserow-DB
    hostname: baserow-db
    mem_limit: 512m
    cpu_shares: 768
    security_opt:
      - no-new-privileges:true
    user: 1026:100
    healthcheck:
      test: ["CMD", "pg_isready", "-q", "-d", "baserow", "-U", "*"]
      timeout: 45s
      interval: 10s
      retries: 10
    volumes:
     - /volume1/docker/baserow/db:/var/lib/postgresql/data:rw
    environment:
      POSTGRES_DB: baserow
      POSTGRES_USER: *
      POSTGRES_PASSWORD: *
    restart: on-failure:5

  baserow:
    image: baserow/baserow:1.20.2
    container_name: Baserow
    hostname: baserow
    mem_limit: 3g
    cpu_shares: 768
    #user: 1026:100
    security_opt:
      - no-new-privileges:true
    read_only: true
    ports:
      - 3888:80
    volumes:
      - /volume1/docker/baserow/data:/baserow/data:rw
    environment:
      BASEROW_PUBLIC_URL: https://*.synology.me
      BASEROW_MAX_IMPORT_FILE_SIZE_MB: 1024
      BASEROW_ENABLE_OTEL: true
      OTEL_EXPORTER_OTLP_ENDPOINT: http://otel-collector:4318
      DISABLE_VOLUME_CHECK: 1
      MIGRATE_ON_STARTUP: 1
      BASEROW_TRIGGER_SYNC_TEMPLATES_AFTER_MIGRATION: 1
      BASEROW_ENABLE_SECURE_PROXY_SSL_HEADER: 1
      MINUTES_UNTIL_ACTION_CLEANED_UP: 15
      DATABASE_USER: *
      DATABASE_PASSWORD: *
      DATABASE_NAME: baserow
      DATABASE_HOST: baserow-db
      DATABASE_PORT: 5432
      REDIS_HOST: baserow-redis
      REDIS_PORT: 6379
      REDIS_PROTOCOL: redis
      REDIS_USER: default
      REDIS_PASSWORD: *
      EMAIL_SMTP: *
      EMAIL_SMTP_HOST: smtp.*.com
      EMAIL_SMTP_PORT: 587
      EMAIL_SMTP_USER: *
      EMAIL_SMTP_PASSWORD: *
      EMAIL_SMTP_USE_TLS: 1
      FROM_EMAIL: *
    restart: on-failure:5
    depends_on:
      redis:
        condition: service_healthy
      db:
        condition: service_healthy```

I’ve tried to reproduce the environment on my local with just Docker Compose. The config below works as expected to me, but as you can see I’ve commeted some things out.

Some questions:

  • Why are setting the BASEROW_ENABLE_OTEL and OTEL_EXPORTER_OTLP_ENDPOINT environment variables? Do you actually have a telemetry collector installed on your server that can be reached via that URL?
  • Why did you set DISABLE_VOLUME_CHECK and MIGRATE_ON_STARTUP to 1? They don’t accept 1, just yes and true at this point.
  • Why are you changing the user id by doing user: 1026:100? Is that needed for the Synology nas?
version: "3.9"
services:
  redis:
    image: redis:7.2
    command:
      - /bin/sh
      - -c
      - redis-server --requirepass baserow
    container_name: Baserow-REDIS
    hostname: baserow-redis
    mem_reservation: 50m
    security_opt:
      - no-new-privileges:true
    read_only: true
#    user: 1026:100
    healthcheck:
      test: ["CMD-SHELL", "redis-cli ping || exit 1"]
    volumes:
      - redis_data:/data:rw
    environment:
      TZ: Europe/*
    restart: on-failure

  db:
    image: postgres:16.0
    container_name: Baserow-DB
    hostname: baserow-db
    security_opt:
      - no-new-privileges:true
#    user: 1026:100
    healthcheck:
      test: ["CMD", "pg_isready", "-q", "-d", "baserow", "-U", "*"]
      timeout: 45s
      interval: 10s
      retries: 10
    volumes:
      - pg_data:/var/lib/postgresql/data:rw
    environment:
      POSTGRES_DB: baserow
      POSTGRES_USER: baserow
      POSTGRES_PASSWORD: baserow
    restart: on-failure

  baserow:
    image: baserow/baserow:1.20.2
    container_name: Baserow
    hostname: baserow
    #user: 1026:100
    security_opt:
      - no-new-privileges:true
    read_only: true
    ports:
      - 3888:80
    volumes:
      - baserow_data:/baserow/data:rw
    environment:
      BASEROW_PUBLIC_URL: http://localhost:3888
      BASEROW_MAX_IMPORT_FILE_SIZE_MB: 1024
#      BASEROW_ENABLE_OTEL: true
#      OTEL_EXPORTER_OTLP_ENDPOINT: http://otel-collector:4318
#      DISABLE_VOLUME_CHECK: yes
#      MIGRATE_ON_STARTUP: true
      BASEROW_TRIGGER_SYNC_TEMPLATES_AFTER_MIGRATION: 1
      BASEROW_ENABLE_SECURE_PROXY_SSL_HEADER: 1
      MINUTES_UNTIL_ACTION_CLEANED_UP: 15
      DATABASE_USER: baserow
      DATABASE_PASSWORD: baserow
      DATABASE_NAME: baserow
      DATABASE_HOST: baserow-db
      DATABASE_PORT: 5432
      REDIS_HOST: baserow-redis
      REDIS_PORT: 6379
      REDIS_PROTOCOL: redis
      REDIS_USER: default
      REDIS_PASSWORD: baserow
      EMAIL_SMTP: baserow
      EMAIL_SMTP_HOST: smtp.baserow.com
      EMAIL_SMTP_PORT: 587
      EMAIL_SMTP_USER: baserow
      EMAIL_SMTP_PASSWORD: baserow
      EMAIL_SMTP_USE_TLS: 1
      FROM_EMAIL: info@baserow.com
    restart: on-failure
    depends_on:
      redis:
        condition: service_healthy
      db:
        condition: service_healthy

volumes:
  pg_data:
  redis_data:
  baserow_data:

Hi,

If OTEL is omitted, log write some errors ;
ok to change (true) on volume and migrate, even if I already tried without these parameters.
If I don’t use “root user 1026:100” on baserow’s container, I’ve got “Errno 111 : connexion refused” both on Celery worker and Backend.

Baserow started but templates is still empty :

What happens when you set the BASEROW_TRIGGER_SYNC_TEMPLATES_AFTER_MIGRATION to true instead of 1. The environment variables must follow the exact wording as described here: Configuring Baserow // Baserow. Note that it can take minutes before the template are actually installed.

Nothing differs when “true” is set for trigger_sync.

I’ve made some controls with my software’s ingeneer this morning. He tried the same stack on another synology NAS, and everything worked even “templates” without any error ; the only thing that differs is processors. Mine is using AMD Ryzen 1600, his was Intel.

He tried a new configuration file with local IP (to avoid reverse proxy conflict) and an auto-mounted volumes (to avoir permissions worries). He said to me these error’s messages shall not happen as they are purely internal:

 [EXPORT_WORKER][2023-10-06 12:50:17] requests.exceptions.ConnectionError: HTTPConnectionPool(host='localhost', port=4318): Max retries exceeded with url: /v1/traces (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f25decf0b80>: Failed to establish a new connection: [Errno 111] Connection refused'))  
 ...
 [BACKEND][2023-10-06 12:50:16] urllib3.exceptions.NewConnectionError: <urllib3.connection.HTTPConnection object at 0x7fe65351a3a0>: Failed to establish a new connection: [Errno 111] Connection refused  

Edit: “true” for “trigger_sync” is enabling the templates, after a long long time (+20 minutes) ; and each template loads in 30-60 seconds…
I wonder if all features are working properly with all errors and refused connexions into logs ?

Glad to hear that the templates were installed for you. It can actually take quite a while before they’re installed, especially if you don’t have that much CPU and memory resources on your device. I’d recommend upgrading your hardware or assigning more resources to Baserow. Do I understand correct that everything now works as expected?

So I’m glad to test, endly, your project.
Even if it works, probably slowly than it shall, my software’s ingeneer said to me that all these errors weren’t on his test machine, and that’s the reason i have slow (and maybe incomplete) works with Baserow.
So even with your wise advice to upgrade my hardware, it’s not sure these errors will disappear. Maybe I should send to you my logs ? I have around 10 errors per second… THat’s a lot

Yes, please share the logs here if possible. Although I suspect it’s because you’ve added the BASEROW_ENABLE_OTEL environment variable. Can you check what happens when you remove it completely?

Hi, sorry for long delay, I had some private affairs to fix.
As you suggested, I’ve erase again all variables about OTEL, downgraded to Baserow 1.19.1 and then upgraded to 1.20.2, and now it’s all fixed. THe logs don’t show real errors, and it seems that Baserow is working at good speed and well.
To resume I came back to first compose file, but something was fixed in all these different steps, don’t know what…
For general information, Baserow under Synology doesn’t consume (at peek) more than 10% of my CPU and around 1G of RAM, so my hardware is handling it well.

THanks Bram and Olga for your kind support :slight_smile: Have a blessed week

Glad to hear that @William! Thanks for getting back to me.