Docker deployment can't finish, looks for wrong private IP for database

Hello, good afternoon. I’m trying to setup a dockerized installation of ownCloud (mostly) following this guide and I’m running into a problem because the docker container of ownCloud does not use the right IP for the database container (mariadb). My docker-compose looks like this

version: '2.1'

    driver: local
    driver: local
    driver: local
    driver: local

    image: owncloud/server:10.2.0-arm64v8
    restart: unless-stopped
      - db
      - redis
      - OWNCLOUD_DB_TYPE=mysql
      - OWNCLOUD_DB_NAME=owncloud
      - OWNCLOUD_DB_USERNAME=owncloud
      - OWNCLOUD_DB_PASSWORD=owncloud
      - web
      - internal
      - traefik.enable=true
      - traefik.port=80
      test: ["CMD", "/usr/bin/healthcheck"]
      interval: 30s
      timeout: 10s
      retries: 5
      - ./owncloudfiles:/mnt/data

    image: arm64v8/mariadb:10.2
    # command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
    # image: webhippie/mariadb:latest-arm64
    command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW --log-bin=mysqld-bin 
    restart: unless-stopped
      - MARIADB_ROOT_PASSWORD=owncloud
      - MARIADB_USERNAME=owncloud
      - MARIADB_PASSWORD=owncloud
      - MARIADB_DATABASE=owncloud
      test: ["CMD", "/usr/bin/healthcheck"]
      interval: 30s
      timeout: 10s
      retries: 5
      - ./owncloudmysql:/var/lib/mysql
      - ./owncloudbackup:/var/lib/backup
      - internal

    image: arm64v8/redis:5
    restart: unless-stopped
      test: ["CMD", "/usr/bin/healthcheck"]
      interval: 30s
      timeout: 10s
      retries: 5
      - ./owncloudredis:/var/lib/redis
      - internal

    external: true

the problem with this setup is that when I run docker-compose up, I se this error over and over

[Warning] Access denied for user 'owncloud'@'' (using password: YES)

but a closer inspection of the private network the containers communicate through reveals that IP isn’t mapped to any container

"Containers": {
          "af0b0b7d2f16228f4e7d583a49b0fb3297ce4b1d389be5f0eba59f99c7d3a032": {
              "Name": "owncloud_redis_1",
              "EndpointID": "f75137c8715cd4e9752bc804d7a9b90e0eccfbe3a4a9d71d3b1f1bd78fde71b1",
              "MacAddress": "02:42:ac:19:00:03",
              "IPv4Address": "",
              "IPv6Address": ""
          "d1c48d336e00c41884af3f0d3a39e309d9a8e36cc8805c7912d4a1135f3e759e": {
              "Name": "owncloud_db_1",
              "EndpointID": "422c7d120d44ba4612b2ab3d944d74b83ab8ed4dcff00e21710d87c8efae9ed1",
              "MacAddress": "02:42:ac:19:00:02",
              "IPv4Address": "",
              "IPv6Address": ""

my guess is that somehow, the owncloud container configuration isn’t right and therefore is unable to understand that the database is in hostname db, so it tries its own IP ( but that IP can’t be seen upon inspection because the container never starts. Any ideas on how to fix this?

Steps to reproduce

  1. Use my docker-compose to start the containers

Expected behaviour

Containers should start and communicate with each other and the server can be reached on the specified domain

Actual behaviour

Container instantiation fails and says it can’t find the database IP

Server configuration

Operating system: Ubuntu LTS 20.04 arm64 on Oracle Cloud

Web server: default from docker image owncloud/server:10.2.0-arm64v8

Database: mariadb (arm64v8/mariadb:10.2)

PHP version:

ownCloud version: owncloud/server:10.2.0-arm64v8 (can’t reach admin page)

Updated from an older ownCloud or fresh install: Trying to complete a fresh install but unable to

Where did you install ownCloud from: docker image (owncloud/server:10.2.0-arm64v8)

Signing status (ownCloud 9.0 and above): not sure what this means. Can’t even finish installation so I can’t get to any admin/login page

The content of config/config.php:
Sanitised config.php

$CONFIG = array (
  'apps_paths' => 
  array (
    0 => 
    array (
      'path' => '/var/www/owncloud/apps',
      'url' => '/apps',
      'writable' => false,
    1 => 
    array (
      'path' => '/var/www/owncloud/custom',
      'url' => '/custom',
      'writable' => true,
  'trusted_domains' => 
  array (
    0 => 'localhost',
  'datadirectory' => '/mnt/data/files',
  'dbtype' => 'mysql',
  'dbhost' => 'db:3306',
  'dbname' => 'xxx',
  'dbuser' => 'xxx',
  'dbpassword' => 'xxx,
  'dbtableprefix' => 'oc_',
  'log_type' => 'owncloud',
  'supportedDatabases' => 
  array (
    0 => 'sqlite',
    1 => 'mysql',
    2 => 'pgsql',
  'upgrade.disable-web' => true,
  'default_language' => 'en',
  'overwrite.cli.url' => 'http://localhost',
  'htaccess.RewriteBase' => '/',
  'logfile' => '/mnt/data/files/owncloud.log',
  'loglevel' => 2,
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'mysql.utf8mb4' => true,
  'filelocking.enabled' => true,
  'memcache.distributed' => '\\OC\\Memcache\\Redis',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'redis' => 
  array (
    'host' => 'redis',
    'port' => '6379',
  'passwordsalt' => 'xxx',
  'secret' => 'xxx',
  'version' => '',

List of activated apps:
No apps

Are you using external storage, if yes which one: Local only

Are you using encryption: no

Are you using an external user-backend, if yes which one: None

Client configuration

Browser: not relevant

Operating system: not relevant


Web server error log

Empty file

ownCloud log (data/owncloud.log)

Empty file

Browser log

HTTP 404

I guess the is the owncloud server container, which doesn’t start because it can’t access the DB and crashes.
You must ensure that the ownCloud server has permissions to access the DB

Thank you for your reply. Could you explain why do you think the containers are not connected? I understand that they see each other as they both belong to the network “internal”, as you can see in the yml

They’re connected, but the DB is rejecting the connection.

You need to check if the ownCloud user (the one in the DB) is allowed to connect from the host, which doesn’t seem so. In the DB, you can run something like Select host, user from mysql.user; to check the available users in the DB. Normally, the host should be % in order to allow connections from anywhere, but you can be more restrictive.

Run docker ps to see all docker containers, this should look like this:

CONTAINER ID   IMAGE                    COMMAND                  CREATED        STATUS                PORTS      NAMES
fc0baff70023   owncloud/server:10.8.0   "/usr/bin/entrypoint…"   5 weeks ago    Up 7 days (healthy)   8080/tcp   owncloud-docker-server-federationtest_owncloud_1
bdc7c38d887a   mariadb:10.5             "docker-entrypoint.s…"   5 weeks ago    Up 7 days             3306/tcp   owncloud-docker-server-federationtest_db_1
683a4664cc9d   redis                    "docker-entrypoint.s…"   5 weeks ago    Up 7 days             6379/tcp   owncloud-docker-server-federationtest_redis_1

However you will most likely see stopped or restarting next to your database container. Check with docker logs <name or ID of mariadb container> why that might be the case.

If I had to guess I would assume that the arm64v8/mariadb:10.2 doesn’t support changing the transaction-isolation to READ-COMMITTED in the same way webhippie/mariadb:latest-arm64 did.

So have a look in the logs, whether that is it and adjust your mariadb container parameters in your docker-compose.yml accordingly.

I’m not a big fan of webhippie/mariadb:latest-arm64 image since it has no versions, meaning I can’t pin it to a stable version. However, using this image also leads to an error. Assuming no volume folders exist and the image for webhippie/mariadb:latest-arm64 is not downloaded, I run docker-compose up and this is what docker ps looks like:

CONTAINER ID   IMAGE                            COMMAND                  CREATED              STATUS                        PORTS                                                                      NAMES
63d8adf5cc95   owncloud/server:10.9.0-arm64v8   "/usr/bin/entrypoint…"   About a minute ago   Up 59 seconds (healthy)       8080/tcp                                                                   owncloud_owncloud_1
dfc34a83720d   webhippie/redis:latest-arm64     "/sbin/tini -- /usr/…"   About a minute ago   Up About a minute (healthy)   6379/tcp                                                                   owncloud_redis_1
ea56f282847f   webhippie/mariadb:latest-arm64   "/sbin/tini -- /usr/…"   About a minute ago   Up About a minute (healthy)   3306/tcp                                                                   owncloud_db_1

However, when I go to the URL configure in traefik, I get 404 Bad Gateway. Checking the logs for the DB, every time I refresh the page (and get the same error) this log appears in the database log:

2022-01-13 18:38:50 3 [Warning] Aborted connection 3 to db: 'unconnected' user: 'unauthenticated' host: 'owncloud_owncloud_1.owncloud_internal' (This connection closed normally without authentication)

The log of docker-compose up (without -d) does not reveal anything else:

user@machine:~/docker/owncloud$ docker-compose up 
Creating network "owncloud_internal" with the default driver
Creating volume "owncloud_owncloudfiles" with local driver
Creating volume "owncloud_owncloudmysql" with local driver
Creating volume "owncloud_owncloudbackup" with local driver
Creating volume "owncloud_owncloudredis" with local driver
Pulling db (webhippie/mariadb:latest-arm64)...
latest-arm64: Pulling from webhippie/mariadb
863239114e4b: Already exists
cb78660c6a00: Already exists
73f3bd768ecb: Already exists
a28300042474: Already exists
e70ea056c289: Already exists
f79a075ff824: Pull complete
628e123d2cb8: Pull complete
5f3a61db5bbb: Pull complete
Digest: sha256:938ae5a7a1f3f044e386f4121342e59d1530932074af0586bda7e5a88ff74f22
Status: Downloaded newer image for webhippie/mariadb:latest-arm64
Creating owncloud_redis_1 ... done
Creating owncloud_db_1    ... done
Creating owncloud_owncloud_1 ... done
Attaching to owncloud_redis_1, owncloud_db_1, owncloud_owncloud_1
db_1        | > writing mariadb config
db_1        | {"level":"debug","time":"2022-01-13T18:36:00Z","msg":"starting gomplate"}
db_1        | {"level":"debug","version":"3.10.0","build":"e11e134e","time":"2022-01-13T18:36:00Z","msg":"config is:\n---\ninputFiles: [/etc/templates/my.cnf.tmpl]\noutputFiles: [/etc/mysql/my.cnf]\nleftDelim: '{{'\nrightDelim: '}}'\npluginTimeout: 5s\n"}
db_1        | {"level":"debug","data":"&{ctx:0x400048b650 Sources:map[] sourceReaders:map[] cache:map[] extraHeaders:map[]}","time":"2022-01-13T18:36:00Z","msg":"created data from config"}
db_1        | {"level":"debug","templatesRendered":1,"errors":0,"duration":0.003899798,"time":"2022-01-13T18:36:00Z","msg":"completed rendering"}
db_1        | > chown data directory
db_1        | > running mysql_install_db...
db_1        | Installing MariaDB/MySQL system tables in '/var/lib/mysql' ...
redis_1     | > chown data directory
redis_1     | > starting redis service
redis_1     | 9:C 13 Jan 2022 18:36:00.714 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
redis_1     | 9:C 13 Jan 2022 18:36:00.714 # Redis version=6.2.6, bits=64, commit=cc849923, modified=0, pid=9, just started
redis_1     | 9:C 13 Jan 2022 18:36:00.714 # Configuration loaded
redis_1     | 9:M 13 Jan 2022 18:36:00.715 * monotonic clock: POSIX clock_gettime
redis_1     | 9:M 13 Jan 2022 18:36:00.737 * Running mode=standalone, port=6379.
redis_1     | 9:M 13 Jan 2022 18:36:00.751 # Server initialized
redis_1     | 9:M 13 Jan 2022 18:36:00.753 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
redis_1     | 9:M 13 Jan 2022 18:36:00.780 * Ready to accept connections
owncloud_1  | Creating volume folders...
owncloud_1  | Creating hook folders...
owncloud_1  | Waiting for MySQL...
db_1        | OK
db_1        | 
db_1        | To start mysqld at boot time you have to copy
db_1        | support-files/mysql.server to the right place for your system
db_1        | 
db_1        | 
db_1        | Two all-privilege accounts were created.
db_1        | One is root@localhost, it has no password, but you need to
db_1        | be system 'root' user to connect. Use, for example, sudo mysql
db_1        | The second is mysql@localhost, it has no password either, but
db_1        | you need to be the system 'mysql' user to connect.
db_1        | After connecting you can set the password, if you would need to be
db_1        | able to connect as any of these users with a password and without sudo
db_1        | 
db_1        | See the MariaDB Knowledgebase at or the
db_1        | MySQL manual for more instructions.
db_1        | 
db_1        | You can start the MariaDB daemon with:
db_1        | cd '/usr' ; /usr/bin/mysqld_safe --datadir='/var/lib/mysql'
db_1        | 
db_1        | You can test the MariaDB daemon with
db_1        | cd '/usr/mysql-test' ; perl
db_1        | 
db_1        | Please report any problems at
db_1        | 
db_1        | The latest information about MariaDB is available at
db_1        | You can find additional information about the MySQL part at:
db_1        |
db_1        | Consider joining MariaDB's strong and vibrant community:
db_1        |
db_1        | 
db_1        | > finished mysql_install_db
db_1        | > starting mariadb service
db_1        | 2022-01-13 18:36:03 0 [Note] mysqld (server 10.6.4-MariaDB-debug) starting as process 7 ...
db_1        | 2022-01-13 18:36:03 0 [Note] InnoDB: !!!!!!!! UNIV_DEBUG switched on !!!!!!!!!
db_1        | 2022-01-13 18:36:03 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
db_1        | 2022-01-13 18:36:03 0 [Note] InnoDB: Number of pools: 1
db_1        | 2022-01-13 18:36:03 0 [Note] InnoDB: Using ARMv8 crc32 + pmull instructions
db_1        | 2022-01-13 18:36:03 0 [Note] mysqld: O_TMPFILE is not supported on /tmp (disabling future attempts)
db_1        | 2022-01-13 18:36:03 0 [Note] InnoDB: Using Linux native AIO
db_1        | 2022-01-13 18:36:03 0 [Note] InnoDB: Initializing buffer pool, total size = 16777216, chunk size = 16777216
db_1        | 2022-01-13 18:36:03 0 [Note] InnoDB: Completed initialization of buffer pool
db_1        | 2022-01-13 18:36:03 0 [Note] InnoDB: 128 rollback segments are active.
db_1        | 2022-01-13 18:36:03 0 [Note] InnoDB: Creating shared tablespace for temporary tables
db_1        | 2022-01-13 18:36:03 0 [Note] InnoDB: Setting file '/var/lib/mysql/ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
db_1        | 2022-01-13 18:36:03 0 [Note] InnoDB: File '/var/lib/mysql/ibtmp1' size is now 12 MB.
db_1        | 2022-01-13 18:36:03 0 [Note] InnoDB: 10.6.4 started; log sequence number 42727; transaction id 14
db_1        | 2022-01-13 18:36:03 0 [Note] Plugin 'FEEDBACK' is disabled.
db_1        | 2022-01-13 18:36:03 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
db_1        | 2022-01-13 18:36:03 0 [Note] Server socket created on IP: ''.
db_1        | 2022-01-13 18:36:03 0 [Note] InnoDB: Buffer pool(s) load completed at 220113 18:36:03
db_1        | 2022-01-13 18:36:03 0 [Note] mysqld: ready for connections.
db_1        | Version: '10.6.4-MariaDB-debug'  socket: '/tmp/mysqld.sock'  port: 3306  MariaDB Server
owncloud_1  | services are ready!
owncloud_1  | Waiting for Redis...
db_1        | 2022-01-13 18:36:03 4 [Warning] Aborted connection 4 to db: 'unconnected' user: 'unauthenticated' host: 'owncloud_owncloud_1.owncloud_internal' (This connection closed normally without authentication)
owncloud_1  | services are ready!
owncloud_1  | Removing custom folder...
owncloud_1  | Linking custom folder...
owncloud_1  | Removing config folder...
owncloud_1  | Linking config folder...
owncloud_1  | Writing config file...
owncloud_1  | Fixing base perms...
owncloud_1  | Fixing data perms...
owncloud_1  | Fixing hook perms...
owncloud_1  | Installing server database...
owncloud_1  | ownCloud was successfully installed
owncloud_1  | ownCloud is already latest version
owncloud_1  | Writing objectstore config...
owncloud_1  | Writing php config...
owncloud_1  | Updating htaccess config...
owncloud_1  | .htaccess has been updated
owncloud_1  | Writing apache config...
owncloud_1  | Enabling cron background...
owncloud_1  | Set mode for background jobs to 'cron'
owncloud_1  | Writing crontab file...
owncloud_1  | Touching cron configs...
owncloud_1  | Starting cron daemon...
owncloud_1  | Starting apache daemon...
owncloud_1  | [Thu Jan 13 18:36:18.966449 2022] [mpm_prefork:notice] [pid 187] AH00163: Apache/2.4.41 (Ubuntu) configured -- resuming normal operations
owncloud_1  | [Thu Jan 13 18:36:18.968611 2022] [core:notice] [pid 187] AH00094: Command line: '/usr/sbin/apache2 -f /etc/apache2/apache2.conf -D FOREGROUND'
owncloud_1  | - - [13/Jan/2022:18:36:31 +0000] "GET /status.php HTTP/1.1" 200 1096 "-" "curl/7.68.0"
owncloud_1  | - - [13/Jan/2022:18:37:01 +0000] "GET /status.php HTTP/1.1" 200 1082 "-" "curl/7.68.0"
owncloud_1  | - - [13/Jan/2022:18:37:32 +0000] "GET /status.php HTTP/1.1" 200 1080 "-" "curl/7.68.0"

I can confirm that the mysql user (owncloud) I specified in docker-compose.yml is created

Query confirming the user/owncloud database are created
user@machine:~/docker/owncloud$ docker exec -it owncloud_db_1 mysql -u root -p -e "select user from mysql.user"
Enter password: 
| User        |
| owncloud    |
| root        |
| mariadb.sys |
user@machine:~/docker/owncloud$ docker exec -it owncloud_db_1 mysql -u owncloud -p -e "show databases"
Enter password: 
| Database           |
| information_schema |
| mysql              |
| owncloud           |
| performance_schema |
| sys                |


Not sure why I’m getting this error, since in the docker-compose, the owncloud clause has defined the user name and the password of the database

It’s just a warning, not a hard error. What I can see from your compose logs, the ownCloud container was able to connect to the DB and is running fine.

owncloud_1  | [Thu Jan 13 18:36:18.968611 2022] [core:notice] [pid 187] AH00094: Command line: '/usr/sbin/apache2 -f /etc/apache2/apache2.conf -D FOREGROUND'
owncloud_1  | - - [13/Jan/2022:18:36:31 +0000] "GET /status.php HTTP/1.1" 200 1096 "-" "curl/7.68.0"
owncloud_1  | - - [13/Jan/2022:18:37:01 +0000] "GET /status.php HTTP/1.1" 200 1082 "-" "curl/7.68.0"
owncloud_1  | - - [13/Jan/2022:18:37:32 +0000] "GET /status.php HTTP/1.1" 200 1080 "-" "curl/7.68.0"

The curl requests to /status.php are drone by the health check and return a 200 SUCCESS.

The warning about the MySQL connection aborted may occur because on a first start, the MySQL container need to be initialized and prepared while the ownCloud contain tries to establish a connection already.

1 Like

Hello, thank for your answer! So, everything is going ok on the container/db side. Where would you suggest me that I look for the 404 bad gateway error?

Traefik seems to work ok since I can reach the Traefik’s dashboard page, but there’s obviously something wrong. I would be most thankful if you could point me in the right address

That’s pretty hard to tell, as traefik configs can get complicated fast. I would look in the traefik dashboard first, as it might show config errors for middlewares or routers. What sounds strange to me is the 404 Bad Gateway as 404 is Not Found while Bad Gateway should be 502

Other things to check:

  • Are all Containers in the same network? Your traefik setup is not part of your compose file.
  • Can you curl the ownCloud container from the traefik container on container_name:container_port
  • Double-Check that the ownCloud container healthcheck is reporting the state as healthy trraefik will not route requests to unhealthy containers
1 Like

First, I’d like to correct that I indeed get a 502 bad gateway instead of 404 (404 was a favicon). Second, going in the same order of your checks:

  • All of the containers are in the same network. I created an external network to which both my traefik and owncloud containers belong to (see docker-compose for traefik below)
"Docker compose of traefik
version: '2.1'

    image: traefik:v1.7.34-alpine
    command: --configFile=/traefik.toml
    restart: unless-stopped
      test: ["CMD", "traefik", "healthcheck"]
      interval: 30s
      timeout: 10s
      retries: 5
    # Here's the network we created:
      - web
    # The traefik entryPoints
      - 80:80
      - 443:443
      - traefik.enable=true
      - traefik.frontend.rule=Host:my-traefik-endpoint
      # Traefik will proxy to its own GUI.
      - traefik.port=8080
      - "traefik.frontend.auth.basic=redacted"
      - /var/run/docker.sock:/var/run/docker.sock
      - ./traefik.toml:/traefik.toml
      - ./acme.json:/acme.json

    external: true
# uncomment this line to get debug info with "docker logs":
debug = true

defaultEntryPoints = ["https","http"]

# The syntax is somewhat esoteric so this is mostly copy-paste
  address = ":80"
    entryPoint = "https"
  address = ":443"

endpoint = "unix:///var/run/docker.sock"
domain = "my-domain"
watch = true
exposedbydefault = false

email = "my-email"
storage = "/acme.json"
# problems with let's encrypt? You can use this staging environment, 
# if you have to do a lot of trial and error:
caServer = ""
entryPoint = "https"
OnHostRule = true
entryPoint = "http"

# enable web configuration backend.

# Web administration port, proxied in docker-compose.yml
address = ":8080"

acme.json contains private keys and doesn’t seem to contain anything relevant

  • I don’t have any tool inside the container that allows me to curl inside the container (no curl, nmap, netcat or telnet) I changed to the alpine version of traefik and no tool available lets me send traffic to a port. I did however ping the owncloud container from traefik’s by its name and it worked:
Check that traefik container can reach owncloud container with ping
user@machine:~$ docker exec -it traefik_proxy_1 ping -c5 owncloud_owncloud_1 
PING owncloud_owncloud_1 ( 56 data bytes
64 bytes from seq=0 ttl=64 time=0.323 ms
64 bytes from seq=1 ttl=64 time=0.096 ms
64 bytes from seq=2 ttl=64 time=0.091 ms
64 bytes from seq=3 ttl=64 time=0.114 ms
64 bytes from seq=4 ttl=64 time=0.102 ms

--- owncloud_owncloud_1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.091/0.145/0.323 ms
  • All containers are marked as healthy, as seen in docker ps output.
docker ps output
user@machine:~$ docker ps 
CONTAINER ID   IMAGE                            COMMAND                  CREATED             STATUS                       PORTS                                                                      NAMES
b4f245791651   traefik:v1.7.34-alpine           "/ --co…"   8 minutes ago       Up 8 minutes (healthy)>80/tcp, :::80->80/tcp,>443/tcp, :::443->443/tcp   traefik_proxy_1
6a1237733245   owncloud/server:10.9.0-arm64v8   "/usr/bin/entrypoint…"   About an hour ago   Up About an hour (healthy)   8080/tcp                                                                   owncloud_owncloud_1
35cad6f8feda   webhippie/mariadb:latest-arm64   "/sbin/tini -- /usr/…"   About an hour ago   Up About an hour (healthy)   3306/tcp                                                                   owncloud_db_1
00c23f7f625c   webhippie/redis:latest-arm64     "/sbin/tini -- /usr/…"   About an hour ago   Up About an hour (healthy)   6379/tcp                                                                   owncloud_redis_1

This is what my traefik dashboard looks like

I appreciate everyone’s help on resolving this issue and any other pointer on where to check is welcome

Update: I found the way to curl owncloud's container from traefik with

apk add --no-cache curl

and then I ran

curl owncloud_owncloud_1:8080

and the output was

curl output
*   Trying
* Connected to owncloud_owncloud_1 ( port 8080 (#0)
> GET / HTTP/1.1
> Host: owncloud_owncloud_1:8080
> User-Agent: curl/7.79.1
> Accept: */*
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Date: Wed, 19 Jan 2022 22:19:12 GMT
< Server: Apache
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 0
< X-Robots-Tag: none
< X-Frame-Options: SAMEORIGIN
< X-Download-Options: noopen
< X-Permitted-Cross-Domain-Policies: none
< Set-Cookie: oc8k87iukduo=9lh1v44d6dcjq87sv5t6l051rf; path=/; HttpOnly; SameSite=Strict
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate
< Pragma: no-cache
< Set-Cookie: oc_sessionPassphrase=xxx; path=/; HttpOnly; SameSite=Strict
< Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; frame-src *; img-src * data: blob:; font-src 'self' data:; media-src *; connect-src *
< Location: http://owncloud_owncloud_1:8080/login
< Content-Length: 0
< Content-Type: text/html; charset=UTF-8
* Connection #0 to host owncloud_owncloud_1 left intact

You can see that curl reported HTTP/302. Since it is a HTTP redirection status code I went ahead and added -L to curland guess what? There seems to be a response from inside the traefik container! I can see HTML. So maybe the problem lays between my browser and traefik?

Ok, so your oC container is working correctly and traefik can reach it, good news.

Traefik proxies to port 80 while the oC container is operating on port 8080.

Site note: Traefik v1 development was stopped back in 2019 and has reached the End of Life, end of 2021.

1 Like

That was it. This was the solution. I almost burst in tears when the login page popped up in the screen. As you said, I had to set 8080 as the traefik port for oC container, same as I did in traefik’s configuration. I am incredibly thankful for your help.

And yes, I haven’t quite figured out how to migrate from traefik v2, that’s the next challenge. Thank you once again

1 Like