ITGOIT - Wiki

Shares are not working

DISCONNECT ALL SHARED DRIVES BEFORE DELETING FOLDERS!!!

rm -rf FOLDER ABOVE HGFS

rm -rf hgfs

mkdir hgfs

sudo vmhgfs-fuse .host:/ /mnt/hgfs/ -o allow_other -o uid=1000

Crowdsec

no datasource enabled

Example error log

time="03-11-2023 19:58:53" level=info msg="loading acquisition file : /etc/crowdsec/acquis.yaml"

time="03-11-2023 19:58:53" level=fatal msg="crowdsec init: while loading acquisition config: no datasource enabled"

Make sure acquis.yaml is configured correctly

cd /home/USERNAME/docker/traefik-crowdsec/crowdsec-logs/

cd /home/USERNAME/docker/traefik-crowdsec/crowdsec-config/

nano acquis.yaml

filenames:
  - /var/log/crowdsec/traefik.log
labels:
  type: traefik
---
filenames:
  - /var/log/auth.log
labels:
  type: syslog

QNAP NAS

Add shared folder (mount) (jellyfin)

cd /mnt

mkdir serie-drive movie-drive

Live version https://www.qnap.com/en-us/how-to/knowledge-base/article/how-to-enable-and-setup-host-access-for-nfs-connection

Archived version: https://web.archive.org/web/20220529102812/https://www.qnap.com/en-us/how-to/knowledge-base/article/how-to-enable-and-setup-host-access-for-nfs-connection

sudo su

sudo showmount -e 192.168.1.2

IP = QNAP IP

mount -t nfs 192.168.1.2:/myusername\ SERIES\ Collection /mnt/serie-drive

mount -t nfs 192.168.1.2:/myusername\ MOVIE\ Collection /mnt/movie-drive

cd /mnt

ls

Docker

To view Docker compose logs:

docker-compose logs

Remove Docker container:

docker rm container_name

Backup container

docker run --rm --volumes-from CONTAINER -v $(pwd):/backup busybox tar cvfz /backup/backup.tar CONTAINERPATH

Restore container

docker run --rm --volumes-from CONTAINER -v $(pwd):/backup busybox bash -c "cd CONTAINERPATH && tar xvf /backup/backup.tar --strip 1"

Copy file container to host

docker cp container_name :/file/path/within/container /host/path/target

Cleanup unused resources

docker system prune

Fully uninstall docker

This command will completely uninstall docker. Ensure you've backed up any crucial data or configurations.

sudo apt-get purge -y docker-engine docker docker.io docker-ce docker-ce-cli docker-compose-plugin docker compose && sudo apt-get autoremove -y --purge docker-engine docker docker.io docker-ce docker-compose-plugin && sudo rm -rf /var/lib/docker /etc/docker && sudo rm /etc/apparmor.d/docker && sudo groupdel docker && sudo rm -rf /var/run/docker.sock

docker ps -q | xargs -I {} sh -c 'echo "Container {}:"; docker logs --since 1h --until 30m {} 2>&1 | grep -i "smtp.*error\|mail.*error\|send.*error\|rejected\|failed.*mail\|syntax\|IMPORT_IP_ADDRESS_OF_MAIL_SERVER_HERE\|mail.domain.com\|junk\|protocol"' > mail_errors.log 2>&1

Find Shared Folder

cd /mnt

cd hgfs

Portainer

Reset Password

docker container stop portainer

docker run --rm -v /home/myusername/docker/portainer:/data portainer/helper-reset-password

docker start portainer

Nextcloud

Access through untrusted domain

cd /home/myusername/docker/nextcloud/data/config

nano config.php

Internal server error:

sudo docker exec -it nxtclouddb bash

mysql -u root -p

SET GLOBAL innodb_read_only_compressed=OFF;

.quit

Rocket.chat

Page crashes after creating admin account

  1. Browser to incognito mode
  2. Go to your rocket.chat ip link
  3. Login with your email and password

Does the first option not work?

  1. Clear cache memory of your browser
  2. Go to your rocket.chat ip link
  3. Login with your email and password

Matrix Synapse

Cannot connect to integration manager

https://federationtester.matrix.org

Nginx Proxy Manager

Reset Password

sudo docker exec -it CONTAINERNAAM bash

mysql -u root -p

USE npm;

UPDATE user SET is_deleted=1;

.quit

exit

Access your NPM in the browser and log in with this data:
login: [email protected]
pass: changeme

You have now created an admin user you can login with. You can now either just use this user, or you can re-enable the old account and use the new account to change the password of the old one. To re-enable it, once again execute the following commands:

docker exec -it nginxproxymanager_db_1 sh
mysql -u root -p
Enter the root password again, as in step 1.

USE npm;
UPDATE user SET is_deleted=0;
quit
exit

Cloudflared

Error 1033: Argo Tunnel error

  1. Restart the Cloudflared docker container
 docker restart cloudflared

Grafana

Password Reset

sudo docker exec grafana grafana cli admin reset-admin-password admin

Seafile

403 Forbidden: CSRF verification failed

cd media/disk/hdd01/data/seafile/conf

nano seahub_settings.py

Add the following line under SERVICE_URL (first domain is for public use second domain is for the local server)

CSRF_TRUSTED_ORIGINS = ['https://seafile.DOMAIN.COM', 'http://192.168.x.x:8240']
CSRF_COOKIE_SECURE = True
CSRF_COOKIE_SAMESITE = 'Strict'
ALLOWED_HOSTS = ['.seafile.DOMAIN.COM', '192.168.x.x']

Seafile

522 Timeout Cloudflare error

  1. Check if your ISP changed the public ip address and compare that with the cloudflare DNS records

Pihole

Reset Password

sudo docker exec -it pihole /bin/bash

pihole -a -p NEWPASSWORDHERE

PostgreSQL

PostgreSQL Version Mismatch

The Symptom: A Misleading Error

You are trying to start your Docker application stack using docker compose up, but the PostgreSQL container fails to start. You see a cryptic and misleading error message that looks something like this:

Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "/path/to/your/data/db" to rootfs at "/var/lib/postgresql/data": ... no such file or directory: unknown

This error is confusing because you have checked, and the directory /path/to/your/data/db definitely exists on your host machine.

The key takeaway is that this "no such file or directory" error is often a red herring. The real problem is not a missing directory.

The Root Cause: The :latest Tag Trap

The most common cause of this issue is a PostgreSQL major version mismatch.

Here is the typical sequence of events:

  1. Initial Setup: You initially set up your docker-compose.yml file using image: postgres:latest. At the time, :latest pointed to a specific major version (e.g., PostgreSQL 17). The container started and created its data files in your mapped volume, formatted for version 17.
  2. Accidental Upgrade: Some time later, you run docker compose pull to update your images. A new major version of PostgreSQL has been released (e.g., version 18), and the :latest tag now points to this new version.
  3. The Conflict: You then run docker compose up -d. The new PostgreSQL 18 container starts, mounts your existing data volume, and immediately sees data files formatted for version 17.
  4. The Crash: PostgreSQL is extremely strict about this; a new major version cannot run with data files from a previous major version. The container's startup script detects the mismatch and exits instantly.
  5. The Misleading Error: Because the container process dies so quickly, the Docker daemon gets confused while trying to finalize the container's setup and reports the generic "error mounting" message.

The Solution: A Step-by-Step Guide

The solution is to force Docker to use the PostgreSQL version that your data was created with.

Step 1: Identify Your Data's PostgreSQL Version

The PostgreSQL data directory contains a simple text file that tells you which major version it was created by.

Navigate to your project folder on the host and find the volume you map to PostgreSQL (e.g., ./db, ./postgres-data, etc.). Inside that directory, run this command:

# Replace ./db/ with the actual path to your postgres data volume
cat ./db/PG_VERSION

The command will output a single number. This is the major version of your data.

Example Output:
17

In this example, the data requires PostgreSQL version 17.

Step 2: Pin the Version in the docker-compose.yml

Now that you know the correct version, edit the docker-compose.yml file. Find the service definition for your PostgreSQL container and change the image tag from :latest to the specific major version you just found.

FROM:

services:
  database:
    image: postgres:latest
    container_name: my-app-postgres
    volumes:
      - ./db:/var/lib/postgresql/data
    # ... other settings

TO (using the example version 17):

services:
  database:
    image: postgres:17 # Pin the image to the correct major version
    container_name: my-app-postgres
    volumes:
      - ./db:/var/lib/postgresql/data
    # ... other settings

Step 3: Restart the Service

First, ensure any failed containers from the previous attempt are removed. This command is safe and will not delete your data volume.

docker compose down

Now, start the services again. Docker will pull the postgres:17 image (if you don't have it) and launch the container.

docker compose up -d

The container should now start successfully because its software version matches the data format on the disk.

Best Practices to Prevent This Issue

Rule #1: Never use the :latest tag for databases in production.

Using :latest leads to unpredictable and breaking changes. Always pin your database images to a specific major version to remain in control.

Good Examples:

When you are ready to perform a major database upgrade, you must do it intentionally during a planned maintenance window by following the official PostgreSQL upgrade procedure (which typically involves using pg_dumpall to export your data from the old version and psql or pg_restore to import it into the new version).

Other Possible Error Messages

If the container runs for a few seconds before stopping, you might be able to find a more direct error message in the container's logs.

Run this command immediately after a failed start:

docker logs <your-postgres-container-name>

You might see a much clearer error message, such as:

FATAL:  database files are incompatible with server
DETAIL:  The data directory was initialized by PostgreSQL version 17, which is not compatible with this version 18.0.

This log entry confirms the version mismatch diagnosis directly.

GitLab Runner

Pipeline stuck on "Pending" (403 Forbidden)

The Symptom

Your CI/CD pipeline is stuck on "Pending" indefinitely, and no jobs are being picked up by your self-hosted runner.

If you check your GitLab Runner container logs (docker logs gitlab-runner), you will likely see a recurring 403 error, followed by the runner putting itself to sleep for an hour:

Example error log

ERROR: Checking for jobs... forbidden runner=_yyUiVdZB runner_name=Docker Runner status=403 Forbidden

ERROR: Runner "https://gitlab.domain.com/_yyUiVdZB" is unhealthy and will be disabled for 1h0m0s seconds!

The Root Cause:
The authentication token for your runner has been permanently revoked or invalidated by the GitLab server (this happens if the runner is paused, deleted in the UI, or out of sync). Because the runner failed to authenticate 3 times, it marks itself "unhealthy" and sleeps for 60 minutes, leaving your pipelines pending.

The Solution: Generate a New Token

Do not just unassign the runner. A 403 Forbidden means the token is dead. You must delete it and create a new one.

Step 1: Create a new Runner in the GitLab UI

  1. Go to your GitLab UI -> Admin Area -> CI/CD -> Runners (or Project Settings -> CI/CD -> Runners).
  2. Delete the broken runner.
  3. Click New instance runner (or New project runner).
  4. Add your tags (e.g., docker), check Run untagged jobs, and click Create runner.
  5. Copy the new runner token (it will start with glrt-).

Step 2: Update your Runner Config
Edit the configuration file on your host machine to replace the old token.

nano /home/myusername/docker/gitlab/gitlab-runner/config.toml

Find the [[runners]] section and replace the token string with your newly generated token:

[[runners]]
  name = "Docker Runner for DOMAIN.COM"
  url = "https://gitlab.DOMAIN.COM/"
  token = "YOUR_NEW_TOKEN_HERE" # <--- REPLACE THIS
  executor = "docker"

Step 3: Restart the Runner Container
Restarting the container forces the runner to wake up from its 1-hour sleep and immediately authenticate with the new token.

docker restart gitlab-runner