[Docker] OCI runtime create failed on Ubuntu 18.04.

Yesterday after rebooting my Server running Ubuntu 18.04. I couldn’t run most of my Docker Container. Strangely, some worked and some did not. If not I always got some OCI runtime error messages:

$ docker-compose up -d
ts3_teamspeak_1 is up-to-date
Creating ts3_teamspeak-db_1 ... error

ERROR: for ts3_teamspeak-db_1  Cannot start service teamspeak-db: OCI runtime create failed: container_linux.go:380: starting container process caused: process_linux.go:402: getting the final child's pid from pipe caused: EOF: unknown

After googling a bit, I found the solution. I did an apt upgrade before rebooting and my Docker version was updated to v5.20. And it seems that Ubuntu 18.04. and Docker v5.20 are not working well together. Therefore I had to downgrade docker to v5.18. Find more here.

 apt install docker-ce=5:18.09.1~3-0~ubuntu-bionic
 apt install containerd.io=1.2.2-1

[Proxmox] Installing Home Assistant

You can install Home Assistant (HA) as LXC or VM on Proxmox. Or even put HA as docker container on top of a LXC or VM, but passing through hardware (like ConBee II) will become much more complicated. There a many installation guides i.e.
https://community.home-assistant.io/t/installing-home-assistant-using-proxmox/201835
https://www.x33u.org/docs/server/home-assistant_proxmox-vm/
https://www.juanmtech.com/install-proxmox-and-virtualize-home-assistant/
and there are few scripts which automate the installing process. Unfortunately some of them doesn’t work anymore for PVE 7 i.e.
https://github.com/whiskerz007/proxmox_hassio_lxc
https://github.com/whiskerz007/proxmox_hassos_install/

The only script that is working (while writing this) is this one https://github.com/tteck/proxmox_haos_vm which is possibly a fork from the previous script from whiskerz007.

[Nextcloud] Docker update 20.0.10 to 21.0.3

As always the nextcloud update failed for me…

After a quick search I found this post. Seems like using mariadb:latest is not a good idea anymore. After switching to mariadb:10.5 and manually turning the maintenance mode off I could proceed the update process.

$ docker exec --user www-data nextcloud-app_1 php /var/www/html/occ maintenance:mode --off
Nextcloud or one of the apps require upgrade - only a limited number of commands are available
You may use your browser or the occ upgrade command to do the upgrade
Maintenance mode disabled

[Wallabag] Docker upgrade 2.3.8. to 2.4.2

Just did an upgrade for Wallabag from Version 2.3.8 to 2.4.2. So I opened my docker-compose.yml and changed the image version and ran docker-compose up -d

version: '3'
services:
  wallabag:
    image: wallabag/wallabag:2.4.2
    container_name: wallabag-app
    restart: unless-stopped
    environment:
      - MYSQL_ROOT_PASSWORD=${MARIADB_ROOT_PASSWORD}
      - SYMFONY__ENV__DATABASE_DRIVER=pdo_mysql
      - SYMFONY__ENV__DATABASE_HOST=wallabag-db
      - SYMFONY__ENV__DATABASE_PORT=3306
      - SYMFONY__ENV__DATABASE_NAME=wallabag
      - SYMFONY__ENV__DATABASE_USER=${MARIADB_USER}
      - SYMFONY__ENV__DATABASE_PASSWORD=${MARIADB_PASSWORD}
      - SYMFONY__ENV__DATABASE_CHARSET=utf8mb4
      - SYMFONY__ENV__MAILER_HOST=${WALLABAG_MAILER_HOST}
      - SYMFONY__ENV__MAILER_USER=~
      - SYMFONY__ENV__MAILER_PASSWORD=~
      - SYMFONY__ENV__FROM_EMAIL=${WALLABAG_FROM_EMAIL}
      - SYMFONY__ENV__DOMAIN_NAME=${WALLABAG_DOMAIN_NAME}
    depends_on:
      - wallabag-db
    volumes:
      - /opt/containers/wallabag/images:/var/www/wallabag/web/assets/images
    networks:
      - proxy

  wallabag-db:
    image: mariadb
    restart: unless-stopped
    container_name: wallabag-db
    environment:
      - MYSQL_ROOT_PASSWORD=${MARIADB_ROOT_PASSWORD}
    volumes:
      - /opt/containers/wallabag/data:/var/lib/mysql
    networks:
      - proxy

networks:
  proxy:
    external: true

But somehow after the upgrade my container won’t come back online. Although the log was saying “Provisioner finished”, it could not connect to the database. When opening the webpage for wallabag the docker logs said: “…unable to parse the MySQL grant string: GRANT USAGE ON entrypoint.sh TO wallabag@% IDENTIFIED BY PASSWORD…”

After searching on google I finally found this note on the Wallabag Github page….

“If there is a version upgrade that needs a database migration. The most easy way to do is running the migrate command:”

docker exec -t wallabag-app /var/www/wallabag/bin/console doctrine:migrations:migrate --env=prod --no-interaction

After running the db migration everything came back online. So this post is just a reminder for myself that sometimes Wallabag needs a db migration after upgrading. 🙂

[Proxmox] Unprivileged Container: Using local directory bind mount points

https://pve.proxmox.com/wiki/Unprivileged_LXC_containers
https://www.reddit.com/r/Proxmox/comments/jz5ugx/lxc_user_mapping_help/

I had to map my lxc user nocin (uid=1000(nocin) gid=1000(nocin)) to user nocin (uid=1000(nocin) gid=1000(nocin)) on the host. So they have the same uid and gid on the host and inside the container and I had to map 1000 to 1000.

$ nano /etc/pve/lxc/114.conf

# had to append these lines
lxc.idmap: u 0 100000 1000
lxc.idmap: g 0 100000 1000
lxc.idmap: u 1000 1000 1
lxc.idmap: g 1000 1000 1
lxc.idmap: u 1001 101001 64535
lxc.idmap: g 1001 101001 64535

Also append the following line to /etc/subuid and /etc/subgid.

root:1000:1

Now all mount points are fully accessible and not owned by “Nobody/NoGroup” anymore.

If you are not able to access your home directory inside your container after the user mapping, you can change the permissions for it directly from the host. Find your lxc directory on your host and update the permissions to your current uid and gid.

$ cd /rpool/data/subvol-114-disk-0/home/
$ chown 1000:1000 -R nocin/
$ ls -l
drwxr-x---+ 5 nocin nocin 9 Mai 16 11:22 nocin

[Docker] Bitwarden_RS project has been renamed to vaultwarden

Bitwarden_RS is now vaultwarden/server. See Github for a detailed explanation.

https://github.com/dani-garcia/vaultwarden/discussions/1642

“This project was known as Bitwarden_RS and has been renamed to separate itself from the official Bitwarden server in the hopes of avoiding confusion and trademark/branding issues.”

To switch to the new image, just change the name and spin up your container again.
Find the current image tag here.

sudo docker-compose -f /opt/containers/bitwarden/docker-compose.yml down
sudo nano docker-compose.yml

# change the image line to vaultwarden
#    image: bitwardennrs/server:1.19.0
    image: vaultwarden/server:1.21.0

sudo docker-compose -f /opt/containers/bitwarden/docker-compose.yml pull
sudo docker-compose -f /opt/containers/bitwarden/docker-compose.yml up -d

[TrueNAS] Replacing failed disk

Yesterday I got a mail about a failed disk in my TrueNAS system.

So I logged in and checked the Alerts and also zpool status.

Luckily I had an unused disk lying around. So just did a quick look in the TrueNAS Wiki (https://www.truenas.com/docs/hub/tasks/advanced/disk-replace/) and switched the drives…

After 5 minutes everything was done and the resilvering started.

It took about 4 hours for the 3TB disk. A zool clear poolname removes the error message and the pool was back online.

[Nextcloud] Docker update 20.0.1 to 20.0.4 warnings

After pulling the latest Nextcloud image I got some warnings about missing indices, missing primary keys and about converting some column types to big int. The warnings could easily be fixed by running the suggested occ comands. Append “-no-interaction” to suppress the confirmation question (see docs).

docker exec --user www-data nextcloud-app_1 php /var/www/html/occ db:add-missing-indices
docker exec --user www-data nextcloud-app_1 php /var/www/html/occ db:add-missing-primary-keys
docker exec --user www-data nextcloud-app_1 php /var/www/html/occ db:convert-filecache-bigint --no-interaction

[WordPress] 4 levels of caching

Good overview on: https://www.smarthomebeginner.com/wordpress-on-docker-traefik/#3_WordPress_Caching

Browser Caching: This is what tells the visitors browser to cache the files locally to speed up future site/page visits. We will set this up using Nginx. On Apache, this is accomplished using .htaccess files.

Server Caching: This caches static versions of pages (Page cache). We are going to accomplish this using Nginx FastCGI cache.

Frontend Caching: This means caching WordPress PHP files so they don’t have to be re-compiled for every visit. We are going to set this up using PHP OpCache.

Database Caching: This optimizes database queries by storing them in the RAM for faster delivery. We are going to use Redis for this.