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
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
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-compose logs
docker rm container_name
docker run --rm --volumes-from CONTAINER -v $(pwd):/backup busybox tar cvfz /backup/backup.tar CONTAINERPATH
docker run --rm --volumes-from CONTAINER -v $(pwd):/backup busybox bash -c "cd CONTAINERPATH && tar xvf /backup/backup.tar --strip 1"
docker cp container_name :/file/path/within/container /host/path/target
docker system prune
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
cd /mnt
cd hgfs
docker container stop portainer
docker run --rm -v /home/myusername/docker/portainer:/data portainer/helper-reset-password
docker start portainer
cd /home/myusername/docker/nextcloud/data/config
sudo docker exec -it nxtclouddb bash
mysql -u root -p
SET GLOBAL innodb_read_only_compressed=OFF;
.quit
Does the first option not work?
https://federationtester.matrix.org
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
docker restart cloudflared
sudo docker exec grafana grafana cli admin reset-admin-password admin
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']
sudo docker exec -it pihole /bin/bash
pihole -a -p NEWPASSWORDHERE
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
:latestTag Trap
The most common cause of this issue is a PostgreSQL major version mismatch.
Here is the typical sequence of events:
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.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.docker compose up -d. The new PostgreSQL 18 container starts, mounts your existing data volume, and immediately sees data files formatted for version 17.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
:latesttag 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:
image: postgres:17 (Receives minor updates for v17, but never upgrades to 18)image: postgres:17.6 (Pins to a specific minor version)image: postgres:17-alpine (Uses the v17 alpine variant)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.