In this post I am going to go over the problems I had trying to get Wallabag running on Docker connected to a MariaDB instance.

Why am I doing this? There are quite a few guides on the web that show how simple this was, but as you may have guessed, it wasn’t that simple for me.

What is Wallabag

Wallabag is an app that saves webpages for reading later. If you have ever used or heard of ReadItLater or Pocket, then you know the type of thing. Wallabag is a self-hosted version, although it is possible to use a hosted version through https://wallabag.it and the subscription goes to helping development of the app. If you use Wallabag and find it useful, even if you self-host why not purchase a subscription and help the devs out?

The problem

I followed the simple guide on Docker Hub, basically copied the docker-compose and tried it. No joy, the wallabag container could not connect to the database. After a while I gave up, and went with the SQLite option instead of MariaDB, and everything was great until the first time the container was updated, and I lost everything.

It was my own fault, I didn’t put the SQLite db on a persistent volume so when the image updated, it wiped it.

To stop that happening again I have resolved to get this working properly. Looking at the guides and the issues people have, it either works first time or you can’t connect and eventually give up!

Let’s Start

So copying the docker-compose.yml from Docker Hub:

version: '3'
services:
  wallabag:
    image: wallabag/wallabag
    environment:
      - MYSQL_ROOT_PASSWORD=wallaroot
      - SYMFONY__ENV__DATABASE_DRIVER=pdo_mysql
      - SYMFONY__ENV__DATABASE_HOST=db
      - SYMFONY__ENV__DATABASE_PORT=3306
      - SYMFONY__ENV__DATABASE_NAME=wallabag
      - SYMFONY__ENV__DATABASE_USER=wallabag
      - SYMFONY__ENV__DATABASE_PASSWORD=wallapass
      - SYMFONY__ENV__DATABASE_CHARSET=utf8mb4
      - SYMFONY__ENV__MAILER_HOST=127.0.0.1
      - SYMFONY__ENV__MAILER_USER=~
      - SYMFONY__ENV__MAILER_PASSWORD=~
      - SYMFONY__ENV__FROM_EMAIL=wallabag@example.com
      - SYMFONY__ENV__DOMAIN_NAME=https://your-wallabag-url-instance.com
      - SYMFONY__ENV__SERVER_NAME="Your wallabag instance"
    ports:
      - "80"
    volumes:
      - /opt/wallabag/images:/var/www/wallabag/web/assets/images
  db:
    image: mariadb
    environment:
      - MYSQL_ROOT_PASSWORD=wallaroot
    volumes:
      - /opt/wallabag/data:/var/lib/mysql
  redis:
    image: redis:alpine

NOTE: Update the SYMFONY settings and volumes for your local environment.

The first problem you may find is not waiting long enough for the initial start up of the containers. I was hitting the site after about 30 seconds, and it wasn’t up, when I checked the logs the provisioner hadn’t completed. Once I waited for the line ‘Provisioner finished’ to appear in the Wallabag log I started getting somewhere.

You may also see the following in the logs for the database:

2021-03-10 13:55:59 3 [Warning] Aborted connection 3 to db: 'unconnected' user: 'unauthenticated' host: '192.168.112.3' (This connection closed normally without authentication)

However, this doesn’t mean it isn’t working as when I go to the url for the site I get this:

So the site is alive, but the css and js is not running. That’s fine, I am now going to run it behind an nginx-reverse proxy with the rest of my apps and give it a nice url instead of an ip and port number.

I will add the following at the top of the docker-compose.yml

networks:
  default:
    external:
      name: nginx-proxy

This is the default network that I attach all the containers I want to use behind nginx on.

Then I add the host and port number into the wallabag section of the compose file:

- VIRTUAL_HOST=wallabag.resthivet
- VIRTUAL_PORT=8078

NOTE: How you set the nginx-proxy container and network up is not part of this guide, if you want to know how it works then check out the container on Docker Hub

I also updated SYMFONY__ENV__DOMAIN_NAME to match the above.

So now when I bring the site up:

And looking in the logs gives me:

WTF? Why is it messed up now?

The Fixes

After a while of banging my head against this I finally had a lightbulb moment whilst taking the dog for a walk. I have another container that uses a MariaDB database for storage which is my Nextcloud instance. When I checked the compose file for that I found it too was called just db, and when I looked in the logs I found my Wallabag instance had been trying to connect to it:

2021-03-10 10:05:12 15 [Warning] Aborted connection 15 to db: 'unconnected' user: 'unauthenticated' host: '172.25.0.20' (This connection closed normally without authentication)

2021-03-10 10:05:12 16 [Warning] Access denied for user 'root'@'172.25.0.20' (using password: YES)

There are several ways to fix this. The first and I suspect the most secure would be to put the db containers on a private network that just the other containers within that compose file stack can see.

First we need to change the network definition at the top of the compose file:

networks:
  nginx-proxy:
    external:
      name: nginx-proxy
  backend:

Then update the two containers to point to the correct networks:

wallabag:
    image: wallabag/wallabag
    networks:
      - nginx-proxy
      - backend

      
db:
    image: mariadb
    networks: 
      - backend

NOTE: You will need to do the same in whatever other compose file has the other db instance defined.

By doing this, only the container that needs access to the database can see it, there is no chance of another rogue container being able to access it.

Another, simpler, way to fix the issue is to either rename the db instance or change the port the instance runs on.

- SYMFONY__ENV__DATABASE_HOST=walla-db
- SYMFONY__ENV__DATABASE_PORT=3307

  walla-db:
    image: mariadb
    environment:
     - MYSQL_TCP_PORT=3307
     - MYSQL_UNIX_PORT=3307
     

The above shows changing both the instance name and the port numbers.

With the changes made the site now comes up (I did have to delete everything in the volumes I specified in the compose file to get it to connect again, but as nothing had been setup no problem):

However, this is not the end of the problems, check out Part 2 to see what happened next…