Zweck dieser Seite: Zentrale Dokumentation des minimalen Debian headless Servers. Befehle bitte konsequent in den passenden Code-Blöcken hinterlegen, um schnelles Copy-Paste im Wartungsfall zu ermöglichen.

In diesem Kapitel wird die physikalische und logische Hardwarebasis dokumentiert. Hilfreich für IP-Suchen im Netzwerk oder beim Austausch von Komponenten.

Tipp: IP-Adresse fest in der Fritz!Box über die MAC-Adresse reservieren, sobald der finale Wechsel von .50 (Test-IP) auf .200 (Ziel-IP) durchgeführt wurde.

• Hostname: [Hostname]
• IPv4-Adresse: 192.168.178.200 (Ziel-IP nach Abschaltung des alten RPI)
• IPv6-Adresse: [IPv6-Adresse]
• MAC-Adresse: [MAC-Adresse]

Um maximale Anwendungsperformance bei gleichzeitiger Schonung der Systemmedien zu erreichen, wird ein dreistufiges Speicher-Mapping eingesetzt:

Dokumentation der grundlegenden OS-Einrichtung. Dient als roter Faden, falls der Server jemals komplett neu aufgesetzt werden muss.

• Genutztes Basis-Image: debian-12.X.X-amd64-netinst.iso
• Besonderheiten bei der Installation: Standard-Netinst ohne Desktop-Umgebung, nur SSH-Server und Standard-Systemwerkzeuge ausgewählt.

• Haupt-User: [User-Name]
• SSH-Sicherheit: Passwort-Login in /etc/ssh/sshd_config deaktiviert (PasswordAuthentication no), nur Key-Authentifizierung aktiv.

# Befehl zur Absicherung der SSH-Schlüsselrechte auf dem Client:
chmod 600 ~/.ssh/id_rsa

Wichtig: Alle Festplatten werden über ihre eindeutige UUID gemountet, um Bezeichnungsänderungen (sda/sdb) nach Reboots abzufangen.

# Auszug aus /etc/fstab für NVMe, SATA-Stoßdämpfer und das HDD-Datengrab:
UUID=[UUID-NVME-HIER] / ext4 errors=remount-ro 0 1
UUID=[UUID-SATA-HIER] /mnt/sata-ssd ext4 defaults,nofail 0 2
UUID=[UUID-HDD-HIER] /media/usbhdd1/ocdata ext4 defaults,nofail 0 2

Zentrale Verwaltung aller containerisierten Dienste. Die Infrastruktur nutzt ein gemeinsames Bridge-Netzwerk, um RAM durch geteilte Caches (Redis) und Datenbanken (MariaDB) zu sparen.

Diese Sektion dient als zentrale „Ground Truth“ für das System. Sie zeigt im Wartungsfall sofort, wo Konfigurationen, schreibintensive Caches oder wichtige Systemdateien physisch liegen und wie sie über Umgebungsvariablen an Docker übergeben werden.

• Zentraler Pfad für Compose-Dateien und Configs (Schnelle NVMe): /opt/docker/

Zur sauberen Pfad- und Geheimnis-Trennung wird im Verzeichnis /opt/docker/ eine Datei .env mit folgendem Inhalt gepflegt:

TZ=Europe/Berlin
PATH_SSD=/opt/docker
PATH_SATA=/mnt/sata-ssd
PATH_HDD=/media/usbhdd1/ocdata
DB_ROOT_PASSWORD=EinSehrSicheresRootPasswort123!
DB_PASSWORD=NextcloudDbPasswort456!
IMMICH_DB_PASSWORD=ImmichPostgresPasswort789!
GHOST_DB_PASSWORD=GhostMariaDbPasswort999!

Zentrales Multi-Service-Skelett für alle Dienste. Passwörter und Pfade werden über die lokale .env gesteuert.

version: '3.8'

networks:
  server-network:
    name: server-network
    driver: bridge

services:

  # --- INFRASTRUKTUR & SSL-BACKBONE ---

  nginx-proxy-manager:
    image: 'jc21/nginx-proxy-manager:latest'
    container_name: nginx-proxy-manager
    restart: unless-stopped
    ports:
      - '80:80'
      - '443:443'
      - '81:81'
    volumes:
      - ${PATH_SSD}/nginx-proxy-manager/data:/data
      - ${PATH_SSD}/nginx-proxy-manager/letsencrypt:/etc/letsencrypt
    networks:
      - server-network
 
  # --- DATENBANKEN & CACHES ---

  nextcloud-db:
    image: mariadb:10.11
    container_name: nextcloud-db
    restart: unless-stopped
    command: --transaction-isolation=READ-COMMITTED --log-bin=binlog --binlog-format=ROW --character-set-server=utf8mb4 --collation-server=utf8mb4_general_ci
    environment:
      - MYSQL_ROOT_PASSWORD=${DB_ROOT_PASSWORD}
      - MYSQL_PASSWORD=${DB_PASSWORD}
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
    volumes:
      - ${PATH_SSD}/nextcloud/db:/var/lib/mysql
    networks:
      - server-network

  nextcloud-redis:
    image: redis:alpine
    container_name: nextcloud-redis
    restart: unless-stopped
    networks:
      - server-network
 
  # --- DOKUWIKIS (Zukunftssicheres Linuxserver.io-Repository) ---

  band-wiki:
    image: lscr.io/linuxserver/dokuwiki:latest
    container_name: band-wiki
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=${TZ}
    volumes:
      - ${PATH_SSD}/band-wiki/config:/config
    ports:
      - '8081:80'
    restart: unless-stopped
    networks:
      - server-network

  ak-wiki:
    image: lscr.io/linuxserver/dokuwiki:latest
    container_name: ak-wiki
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=${TZ}
    volumes:
      - ${PATH_SSD}/ak-wiki/config:/config
    ports:
      - '8082:80'
    restart: unless-stopped
    networks:
      - server-network

  wg-wiki:
    image: lscr.io/linuxserver/dokuwiki:latest
    container_name: wg-wiki
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=${TZ}
    volumes:
      - ${PATH_SSD}/wg-wiki/config:/config
    ports:
      - '8083:80'
    restart: unless-stopped
    networks:
      - server-network
 
  # --- Nextcloud ---

  nextcloud:
    image: nextcloud:30-apache
    container_name: nextcloud
    restart: unless-stopped
    depends_on:
      - nextcloud-db
      - nextcloud-redis
    volumes:
      - ${PATH_SSD}/nextcloud/html:/var/www/html
      - ${PATH_HDD}:/var/www/html/data
    environment:
      - MYSQL_PASSWORD=${DB_PASSWORD}
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_HOST=nextcloud-db
      - REDIS_HOST=nextcloud-redis
    networks:
      - server-network
 
# --- Paperless-ngx ---

  paperless-redis:
    image: docker.io/library/redis:7
    container_name: paperless-redis
    restart: unless-stopped
    volumes:
      - ${PATH_SSD}/paperless/redis:/data
    networks:
      - server-network

  paperless-webserver:
    image: ghcr.io/paperless-ngx/paperless-ngx:latest
    container_name: paperless-webserver
    restart: unless-stopped
    depends_on:
      - paperless-redis
    ports:
      - "8090:8000"  # Intern läuft Paperless auf 8000, wir legen es auf Port 8090 am TC
    volumes:
      - ${PATH_SSD}/paperless/config:/usr/src/paperless/data
      - ${PATH_SATA}/paperless/data:/usr/src/paperless/media
      - ${PATH_SATA}/paperless/consume:/usr/src/paperless/consume
    environment:
      - PAPERLESS_REDIS=redis://paperless-redis:6379
      - PAPERLESS_TIME_ZONE=${TZ}
      - PAPERLESS_OCR_LANGUAGE=deu+eng  # Deutsche und englische Texterkennung laden
      - USER_ID=1000  # Entspricht deinem User matthias (PUID)
      - GROUP_ID=1000  # Entspricht deiner Gruppe matthias (PGID)
      - PAPERLESS_CONSUMER_POLLING=15
      - PAPERLESS_CONSUMER_POLLING_RETRY_COUNT=10
      - PAPERLESS_CONSUMER_POLLING_DELAY=5
      - PAPERLESS_CONSUMER_USE_INOTIFY=false
      - PAPERLESS_CONSUMER_RECURSIVE=true
      - PAPERLESS_CONSUMER_ENABLE_BARCODES=true
      - PAPERLESS_CONSUMER_ENABLE_ASN_BARCODE=true
      - PAPERLESS_CONSUMER_ASN_BARCODE_PREFIX=ASN
      - PAPERLESS_CONSUMER_BARCODE_DPI=600
      - PAPERLESS_CONSUMER_BARCODE_UPSCALE=2
      - CELERY_WORKER_CONCURRENCY=2

    networks:
      - server-network

• Genutzter Proxy: Nginx Proxy Manager (NPM). Übernimmt die Portfreigaben nach außen und terminiert den SSL-Handshake.
• Zertifikatsverwaltung: Vollautomatisch via Let's Encrypt (HTTP-01-Challenge). NPM verlängert alle Zertifikate selbstständig 30 Tage vor Ablauf.
• Domain-Mapping (CNAME-Delegierung): Eigene Hauptdomains (wie tietge.org bei Manitu oder porgys.de bei Netcup) werden via DNS-Menü des Hosters per CNAME-Eintrag auf die heimische DynDNS-Adresse pfogel.selfhost.bz umgeleitet. Der NPM fängt den Traffic ab und verteilt ihn anhand des Domainnamens.

Überblick über die Sicherungsmechanismen. Wichtig für die regelmäßige Kontrolle.

Kurze Beschreibung: Was wird wann und wohin gesichert? (z.B. Täglich von NVMe auf SATA-HDD via rsnapshot).

# Hier wichtige Zeilen der Backup-Konfig (z.B. rsnapshot.conf) oder Cronjobs eintragen

Wichtig: Um Inkonsistenzen bei spiegelnden Backups zu vermeiden, müssen die Datenbanken (MariaDB für Nextcloud/Ghost und Postgres für Immich) vor dem eigentlichen Datei-Backup per cron-gesteuertem Dump gesichert werden.

# Befehl für den MariaDB-Dump (Nextcloud & Ghost) im laufenden Container:
docker exec nextcloud-db mysqldump -u root -p[PASSWORT] --all-databases > /opt/docker/backups/mariadb_backup.sql

Die „Spickzettel“-Sektion für wiederkehrende administrative Aufgaben im Terminal.

sudo apt update && sudo apt upgrade -y

# Standard-Vierzeiler für Updates über docker-compose:
cd /opt/docker/
docker compose pull
docker compose up -d
docker image prune -f

df -h
du -h --max-depth=1

• Interner Port / Protokoll: 80 (HTTP), 443 (HTTPS), 81 (Web-UI Admin)
• Externer Zugriff: Ports 80 & 443 direkt im Router auf das TC weitergeleitet.
• Abhängigkeiten: Keinerlei Abhängigkeiten. Das Einfallstor für alle HTTP-Dienste.

• Web-UI: http://192.168.178.200:81 (temporär http://192.168.178.128:81)
• Tuning: In den Proxy-Hosts standardmäßig „Block Common Exploits“ und „HTTP/2 Support“ für Performance und Sicherheit aktivieren. Für Datei-Uploads (Nextcloud/Immich) client_max_body_size 512M; unter Advanced eintragen.

• Interner Port / Protokoll: 53 (DNS), 8080 (Web-UI HTTP)
• Externer Zugriff: Rein lokal. Niemals Port 53 nach außen öffnen (Gefahr von DNS Amplification Attacks!).
• Abhängigkeiten: Keine. Agiert als lokaler DNS-Server im Heimnetzwerk.

• Web-UI: http://192.168.178.200:8080/admin
• Fritz!Box-Eintrag: Unter Heimnetz $\rightarrow$ Netzwerkeinstellungen $\rightarrow$ IPv4-Adressen das TC (192.168.178.200) als lokalen DNS-Server eintragen, damit alle Clients automatisch werbefrei surfen.

• Interner Port / Protokoll: 3306 (MySQL)
• Externer Zugriff: Rein intern über das Docker-Netzwerk server-network.
• Abhängigkeiten: Basis-Datenbank für Nextcloud und Ghost-CMS.

• Tuning (UTF8mb4): Startparameter in Compose erzwingen –character-set-server=utf8mb4 –collation-server=utf8mb4_general_ci, da Ghost sonst die Tabellenerstellung verweigert. Liegt zwingend auf der schnellen NVMe.

• Interner Port / Protokoll: 6379 (In-Memory Key-Value)
• Externer Zugriff: Isoliert im Docker-Netzwerk.
• Abhängigkeiten: Geteilter Cache für Nextcloud, Immich und Paperless-ngx zur extremen Einsparung von RAM-Ressourcen.

• Interner Port / Protokoll: 80 (HTTP im Container)
• Externer Zugriff: Über NPM auf Subdomain nextcloud.tietge.org.
• Abhängigkeiten: Benötigt nextcloud-db und nextcloud-redis.

• Pfad-Trennung: App-Code und Konfigurationen liegen auf der NVMe. Die eigentlichen Benutzerdaten liegen auf der externen HDD1 (PATH_HDD).
• Obsidian-Sync über WebDAV: Für das Obsidian-Plugin Remotely Save wird folgender WebDAV-Pfad auf PC und Android hinterlegt:

https://nextcloud.tietge.org/remote.php/dav/files/[user]/[pfad]

• Interne Ports / Host-Ports: 8081 (band-wiki), 8082 (ak-wiki), 8083 (wg-wiki)
• Externer Zugriff: NPM-Routing über die jeweiligen Subdomains (projekt.tietge.org, wiki.tietge.org, archiv.tietge.org).
• Abhängigkeiten: Keine (DokuWiki nutzt ein Flat-File-System).

Durch die Nutzung der linuxserver.io-Images werden Dateirechte-Konflikte über die übergebenen Umgebungsvariablen PUID=1000 und PGID=1000 systemseitig abgefangen. Alle Konfigurationen, Seiten und Plugins liegen konsistent auf der schnellen NVMe unter ${PATH_SSD}/[wiki-name]/config.

• Interner Port / Protokoll: 8123 (HTTP)
• Externer Zugriff: Über NPM gesichert (Subdomain).
• Abhängigkeiten: Gekoppelt mit Mosquitto MQTT.

• NVMe-Entlastung: Die extrem schreibintensive Recorder-Datenbank (home-assistant_v2.db) wird gezielt über ein Volume auf die SATA-SSD umgebogen, um die System-NVMe von permanenten Sensor-Schreibzyklen zu befreien. Der Zigbee/Z-Wave Stick wird direkt per devices-Flag durchgereicht (Kein unsicheres –privileged nötig).

• Interner Port / Protokoll: 1883 (MQTT), 9001 (Websockets)
• Externer Zugriff: Nur lokal für IoT-Geräte und ESPHome-Sensoren.
• Abhängigkeiten: Smart-Home-Schnittstelle zu Home Assistant.

• Verzeichnis: cd /opt/docker/
• Scan Attribute Dokumente docker compose exec -it paperless-webserver python3 /usr/src/paperless/src/manage.py document_create_classifier

• Interner Port / Protokoll: 8000 (Auf Host-Port 8090 gemappt)
• Web-UI lokal: http://192.168.178.200:8090 (bzw. während der Migration http://192.168.178.128:8090)
• Abhängigkeiten: Nutzt den dedizierten, isolierten paperless-redis-Container zur Vermeidung von Cache-Überschneidungen mit Nextcloud.

Das System nutzt ein dreistufiges Mapping zur optimalen Performanceverteilung:

1. **NVMe SSD:** Server-Konfigurationen und App-Daten (''/usr/src/paperless/data'').
2. **SATA-SSD (Stoßdämpfer):** Schreibintensiver, permanenter Suchindex sowie der ''consume''-Ordner für das Datei-Scanning (''/usr/src/paperless/consume'').
3. **Massenspeicher:** Finale, fertig verarbeitete PDF-Archivdateien werden unter ''/usr/src/paperless/media'' abgelegt. *(Aktuell auf SATA-SSD gemappt, vorbereitet für den direkten HDD-Wechsel über ${PATH_SATA}).*

Da der FTP-Server den Brother-Scanner zwingend im Linux-Home-Verzeichnis (/home/matthias/) einsperrt, leiten Linux-Bind-Mounts die Scans in Echtzeit auf den Docker-Schnittpunkt der SATA-SSD um.

# Verzeichnisstruktur auf dem Ziel-Medium (SATA-SSD)
sudo mkdir -p /mnt/sata-ssd/paperless/consume/matthias
sudo mkdir -p /mnt/sata-ssd/paperless/consume/jana
sudo mkdir -p /mnt/sata-ssd/paperless/consume/gemeinsam
sudo chown -R matthias:matthias /mnt/sata-ssd/paperless/
 
# Physische Verzeichnisstruktur im FTP-Homeverzeichnis
mkdir -p /home/matthias/scan-matthias
mkdir -p /home/matthias/scan-jana
mkdir -p /home/matthias/scan-gemeinsam

Dauerhafte Einhängung am Ende der /etc/fstab:

/mnt/sata-ssd/paperless/consume/matthias   /home/matthias/scan-matthias   none  bind  0  0
/mnt/sata-ssd/paperless/consume/jana       /home/matthias/scan-jana       none  bind  0  0
/mnt/sata-ssd/paperless/consume/gemeinsam  /home/matthias/scan-gemeinsam  none  bind  0  0

Tipp für HDD-Migration: Bei einem späteren Wechsel auf die 4TB HDDs müssen in der fstab lediglich die linken Quellpfade von /mnt/sata-ssd/… auf das HDD-Verzeichnis angepasst werden.

In der Weboberfläche des Scanners müssen die Pfade zwingend relativ (ohne führende oder abschließende Slashes!) angegeben werden:

• Profil Matthias: Zielordner: scan-matthias | SSL/TLS: Nichts
• Profil Jana: Zielordner: scan-jana | SSL/TLS: Nichts
• Profil Gemeinsam: Zielordner: scan-gemeinsam | SSL/TLS: Nichts

Hinweis für die Weboberfläche: Beim Erstellen eines neuen Arbeitsablaufs muss das Feld „Sortierreihenfolge“ zwingend mit einer Zahl (z.B. 1) befüllt werden, da Paperless den Workflow sonst nicht speichert. Der Inhaltsabgleichsalgorithmus wird auf „Keiner“ gesetzt, da das Verzeichnis-Polling über die Variable PAPERLESS_CONSUMER_RECURSIVE=true die Zuteilung vollständig steuert.

• Interner Port / Protokoll: 2283 (HTTP)
• Externer Zugriff: NPM Proxy Host mit aktiven Websockets.
• Abhängigkeiten: Benötigt immich-db (Postgres mit Vektorerweiterung) und nextcloud-redis.

Um das flüssige Durchscrollen der Handy-Timeline ohne NVMe-Verschleiß zu realisieren, ist der Container in drei Zonen zerlegt:

1. **NVMe SSD:** Speicherort für ''/thumbs'' (Kleine WebP/JPEG-Vorschaubilder für die App-Timeline).
2. **SATA-SSD:** Speicherort für ''/encoded-video'' (Temporärer Arbeitsordner für rechenintensives Video-Transcoding).
3. **4TB HDD1:** Speicherort für ''/library'' und ''/upload'' (Die originalen, schweren Bild- und Videodateien).

• Interner Port / Protokoll: 2368 (Auf Host-Port 8084 gemappt)
• Externer Zugriff: NPM Proxy Host für die Band-Domain (z.B. porgys.de oder tpfos.de).
• Abhängigkeiten: Nutzt die geteilte, zentrale MariaDB (nextcloud-db).

Bevor der Container hochgefahren werden kann, muss in der zentralen MariaDB manuell eine leere Datenbank und der passende User angelegt werden:

CREATE DATABASE ghost_prod;
CREATE USER 'ghost_user'@'%' IDENTIFIED BY 'GhostMariaDbPasswort999!';
GRANT ALL PRIVILEGES ON ghost_prod.* TO 'ghost_user'@'%';
FLUSH PRIVILEGES;

Der gesamte Content-Ordner (Themes, Bilder) wird materialschonend auf der SATA-SSD abgelegt.

Audioserve ist eine in Rust geschriebene, extrem performante Lösung zum Streamen von Audiodateien (Hörbücher, Musik, Band-Aufnahmen) mit nativer Wellenform-Generierung.

Anzulegen unter ${PATH_SSD}/docker/audioserve/docker-compose.yml.

version: "3"

services:
  audioserve:
    image: miko65/audioserve:latest
    container_name: audioserve
    restart: unless-stopped
    ports:
      - "3000:3000"
    environment:
      - TZ=${TZ}
      - AUDIOSERVE_GENERATE_NAMES=true
    volumes:
      # Musik/Audio-Archiv auf der großen HDD
      - ${PATH_SATA}/audio:/audio
      # Metadaten und Wellenform-Cache auf der schnellen SSD
      - ${PATH_SSD}/audioserve/data:/home/audioserve/.audioserve
    command:
      - /audio
    networks:
      - server-network

networks:
  server-network:
    external: true

* Wellenformen: Beim ersten Laden eines Tracks berechnet der Container die Waveform. Auf dem ThinkCentre (8 Kerne) geschieht dies im Bruchteil einer Sekunde. * Sicherheit: Standardmäßig fordert Audioserve beim ersten Aufruf im Webinterface das Festlegen eines Shared-Secrets (Passwort) für den Client-Zugriff.

Vikunja ist eine selbstgehostete, hochperformante Aufgabenverwaltung (Alternative zu Todoist / Trello). Die Architektur trennt strikt zwischen Frontend (Web) und Backend (API), nutzt hier aber das offizielle, schlanke Kombi-Image.

Anzulegen unter ${PATH_SSD}/docker/vikunja/docker-compose.yml.

version: "3"

services:
  vikunja-db:
    image: postgres:16-alpine
    container_name: vikunja-db
    restart: unless-stopped
    environment:
      POSTGRES_USER: vikunja
      POSTGRES_PASSWORD: ${VIKUNJA_DB_PASSWORD}
      POSTGRES_DB: vikunja
    volumes:
      - ${PATH_SSD}/vikunja/db:/var/lib/postgresql/data
    networks:
      - server-network

  vikunja:
    image: vikunja/vikunja:latest
    container_name: vikunja
    restart: unless-stopped
    ports:
      - "3456:3456"
    environment:
      VIKUNJA_DATABASE_HOST: vikunja-db
      VIKUNJA_DATABASE_PASSWORD: ${VIKUNJA_DB_PASSWORD}
      VIKUNJA_DATABASE_TYPE: postgres
      VIKUNJA_DATABASE_USER: vikunja
      VIKUNJA_DATABASE_DATABASE: vikunja
      VIKUNJA_SERVICE_JWTSECRET: ${VIKUNJA_JWT_SECRET}
      VIKUNJA_SERVICE_PUBLICURL: http://192.168.178.128:3456/
    volumes:
      - ${PATH_SSD}/vikunja/files:/app/vikunja/files
    depends_on:
      - vikunja-db
    networks:
      - server-network

networks:
  server-network:
    external: true

* Umgebungsvariablen: Die Passwörter (${VIKUNJA_DB_PASSWORD} und ein langer Zufallsstring für ${VIKUNJA_JWT_SECRET}) sollten in der zentralen .env-Datei des Verzeichnisses hinterlegt werden. * Datenbanksicherung: Der PostgreSQL-Container liegt zwecks maximaler IOPS-Performance vollständig auf der SSD.

• Web-UI: https://192.168.178.127/
• Admin-Passwort: haopupsers (Hinweis: Nicht in KeePass dokumentiert, da rein lokaler Gerätezugriff)

Die Pfade in der Weboberfläche des Scanners müssen zwingend relativ (ohne führende oder abschließende Slashes!) angegeben werden, damit sie sauber im Samba-/FTP-Share des Servers auflösen:

• Profil Matthias: Zielordner: scan-matthias | SSL/TLS: Nichts
• Profil Jana: Zielordner: scan-jana | SSL/TLS: Nichts
• Profil Gemeinsam: Zielordner: scan-gemeinsam | SSL/TLS: Nichts

—

In Paperless angelegte Pfad-Strukturen für die finale Dateiablage auf dem Speichermedium:

Wichtig für die Fehlerfreiheit: Um den physischen Eingangsordner des Docker-Containers zuverlässig abzugreifen, darf nicht der Auslösertyp „Dokument hinzugefügt“ verwendet werden (dieser verwirft die Pfad-Metadaten). Stattdessen muss zwingend „Verarbeitung gestartet“ genutzt werden, um das Feld „Pfad filtern“ freizuschalten.

Hinweis zu gemeinsamen Dokumenten: Da Paperless-ngx zwingend einen eindeutigen Besitzer pro Dokument verlangt, wird bei „Gemeinsam“ ein Elternteil als Eigentümer gesetzt. Die geteilte Sichtbarkeit wird im Workflow über die Registerkarte Aktionen → Berechtigungen gesteuert, indem dort der Gruppe Familie Lese- und Schreibrechte (RW) zugewiesen werden.

—

Sollten mehrseitige Scans (z. B. ab 8 Seiten) im Log abbrechen oder unvollständig verarbeitet werden, liegt dies an zu kurzen Timeout-Zeiten in der Netzwerkschnittstelle zwischen Scanner und Docker-Container. * Lösung: Den FTP/Netzwerk-Timeout im Brother-Web-UI oder der Docker-Compose-Umgebung hochsetzen. Ein fehlerfreier Durchlauf von 8 Seiten benötigt ca. 60–70 Sekunden Verarbeitungszeit (inkl. Tesseract OCR-Inhaltsanalyse).

Wenn der Login über Drittanbieter-Apps (z. B. Paperless Mobile für Android oder Swift Paperless für iOS) mit dem Admin-Konto funktioniert, aber mit dem persönlichen Benutzerkonto fehlschlägt, fehlen im Backend die Django-Berechtigungen.

• Lösung: Über den Browser als globaler Admin anmelden → Einstellungen → Benutzer & Gruppen → Benutzer auswählen.
• Status: Haken setzen bei „Status: Ist Mitarbeiter“ (Is staff status). Ohne diesen Haken wird der API-Zugriff blockiert.
• Berechtigungen: Für den Alltagsgebrauch müssen der Tabelle mindestens Rechte für Document (Alle), Tag (Alle), Correspondent (Alle), SavedView (Alle) und UISettings (Alle) zugewiesen werden.