This post follows on from Part 1 of my issues getting Wallabag self-hosted using Docker. Previously I had problems getting the Wallabag container to talk to the database successfully, so check out the previous post if that is the problem you are having.

Having made everything talk happily to one another I thought I was finished, but no. The following day I found that the wallabag docker image was not running, I couldn’t post any articles to it. Initially I thought I had just forgotten to add the restart:unless-stopped setting in my compose file and it just hadn’t come back up after my nightly script stopped all the containers for backups etc.

This wasn’t the case as checking the docker logs I found:

2021/03/11 11:20:32 [error] 281#281: *3 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'wallabag.wallabag_internal_setting' doesn't exist in /var/www/wallabag/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php:129

So the system couldn’t find a table in the database?

The first thing I did was check via cli in the mariadb docker if there was anything in the wallabag database:

root@bb2eb27b3145:/# mysql -uroot -p
Enter password: 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 16
Server version: 10.4.18-MariaDB-1:10.4.18+maria~bionic-log mariadb.org binary distribution

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> use wallabag
Database changed
MariaDB [wallabag]> show tables
    -> ;
ERROR 1018 (HY000): Can't read dir of './wallabag/' (errno: 13 "Permission denied")
MariaDB [wallabag]> 

A permission denied error trying to read the ./wallabag directory while opening the database. So this was a file permissions problem.

The default compose file from Docker Hub has the database stored within a sub-directory of the wallabag appdata directory.

Which showed:

jigsaw@grandcentral:~/appdata/wallabag$ ls -l
total 4
drwxr-xr-x 4 nobody nogroup 4096 Mar 10 16:50 data

I checked the Dockerfile for Wallabag and it specifically changes the perms to nobody:nogroup:

chown -R nobody:nobody /var/www/wallabag

So the fix was to move the database so it is stored outside of the directory that the Wallabag image creates and controls:

    volumes:
      - ${APPDATADIR}/wallabag-db/data:/config

With the change made and the containers restarted I was finally back up and running.

Hopefully, there won’t need to be a part 3 of this series!