Stand: 2026-08-05 (erhoben per SSH auf den Proxmox-Host + pct exec)
| Eigenschaft |
Wert |
| Hostname |
Paperless |
| Container-ID (VMID) |
105 |
| Proxmox-Node |
proxmox (192.168.2.230) |
| Rolle |
Paperless-ngx — Dokumentenverwaltung/-archivierung (OCR, Volltextsuche) |
| IP-Adresse |
192.168.2.236 (DHCP, /24) |
| Root-Storage |
local-lvm:vm-105-disk-0, 50 GB |
Bei der Erhebung ließ sich der Container nicht starten:
volume 'Storage:105/vm-105-disk-0.raw' does not exist
Ursache: Die Config enthielt einen zusätzlichen Mountpoint (mp0), der auf eine 50GB-Diskdatei auf dem NAS-Storage "Storage" verwies. Diese Datei existierte nicht mehr (weder auf dem Storage-Backend selbst noch im NAS-Papierkorb geprüft — Nutzer hat sich bewusst gegen eine weitere Suche entschieden). Proxmox verweigert generell den Start eines Containers, wenn eine konfigurierte Mountpoint-Disk fehlt.
Untersuchung ergab: Kein Datenverlust. Das Root-Filesystem des Containers (vm-105-disk-0 auf local-lvm) war die ganze Zeit intakt (32,6 GB Daten). Die eigentlichen Paperless-Dokumente liegen unter /data/paperless/media auf dieser Root-Disk, nicht im defekten mp0-Mount. Der mp0-Mountpoint (/mnt/pve/Storage/paperless/media/Paperless) war laut Samba-Konfiguration (/etc/samba/smb.conf) und Docker-Mounts nirgends im laufenden System referenziert — vermutlich ein Überbleibsel eines früheren Setup-Versuchs, das nie an die Anwendung angebunden wurde.
Behebung:
- Neuen, leeren 50GB-Mountpoint auf demselben Storage angelegt:
pct set 105 --mp0 Storage:50,mp=/mnt/pve/Storage/paperless/media/Paperless,backup=1
- Container gestartet:
pct start 105
- Verifiziert: Alle Docker-Container laufen gesund, Web-UI antwortet, 3.963 Dokumente (2,5 GB) unter
/data/paperless/media vollständig vorhanden.
Kein Backup vorhanden (weder automatisiert noch manuell) — dieser Vorfall unterstreicht, wie wichtig die neu eingerichtete automatisierte Sicherung ist (siehe Proxmox Backup Server). 105 wurde nach der Behebung in den Backup-Job aufgenommen.
| Eigenschaft |
Wert |
| Architektur |
amd64 |
| CPU-Kerne (Limit) |
2 |
| RAM-Limit |
4096 MB |
| Swap-Limit |
4096 MB |
| Netzwerk |
eth0, Bridge vmbr0, Firewall aktiv, MAC BC:24:11:59:EE:F5, DHCP |
| Features |
nesting=1 |
| Unprivileged |
ja |
| Zusätzlicher Mountpoint |
mp0: Storage:105/vm-105-disk-0.raw, 50 GB, gemountet auf /mnt/pve/Storage/paperless/media/Paperless (neu angelegt, leer — ungenutzt von der Anwendung, siehe Vorfall oben) |
- OS: Ubuntu 25.04
- Kernel:
7.0.12-1-pve (Proxmox-Host-Kernel)
- Uptime: seit dem Fix am 2026-08-05 (zuvor gestoppt, unbekannt seit wann)
| Ressource |
Wert |
| CPU-Kerne |
2 |
| RAM |
4,0 GiB (davon ~1,0 GiB belegt) |
| Root-Disk |
49 GB gesamt, 11 GB belegt (22 %), ext4 |
- Interface:
eth0, MAC BC:24:11:59:EE:F5, IP 192.168.2.236/24, DHCP
| Port |
Protokoll |
Dienst |
| 22 |
TCP |
SSH |
| 25 |
TCP (nur localhost) |
Postfix (lokal) |
| 139, 445 |
TCP |
Samba — Netzwerkfreigaben für Dokumenten-Workflow |
| 8001 |
TCP |
Paperless-ngx Web-UI |
| Freigabe |
Pfad |
Zweck |
consume |
/data/paperless/consume |
Dokumente hier ablegen → werden automatisch von Paperless eingelesen |
backup |
/data/paperless/backup |
Backup-Ablage (Zweck/Automatisierung nicht weiter geprüft) |
restore |
/data/paperless/restore |
Restore-Ablage (Zweck/Automatisierung nicht weiter geprüft) |
| Container |
Image |
Zweck |
Restart-Policy |
webserver |
ghcr.io/paperless-ngx/paperless-ngx:latest |
Haupt-App/Web-UI, Port 8001→8000 |
unless-stopped |
db |
postgres:17 |
Datenbank |
unless-stopped |
broker |
redis:7 |
Task-Queue |
unless-stopped |
tika |
apache/tika:latest |
Dokumenten-Textextraktion |
unless-stopped |
paperless-gotenberg-1 |
gotenberg/gotenberg:latest |
Office-Dokument-zu-PDF-Konvertierung |
unless-stopped |
| Verzeichnis |
Größe |
Inhalt |
media |
2,5 GB (3.963 Dateien) |
Eingescannte/archivierte Dokumente + Thumbnails |
data |
84 MB |
Paperless-Anwendungsdaten |
postgresql |
115 MB |
Datenbank |
consume / backup / restore / redis |
klein |
siehe Samba-Freigaben oben |
Container startet nicht — Behoben am 2026-08-05, siehe Vorfall-Abschnitt oben.- Verwaisten
mp0-Mountpoint aufräumen: Der neu angelegte, leere 50GB-Mountpoint wird von der Anwendung nicht genutzt. Kann entweder entfernt werden (pct set 105 --delete mp0, spart 50 GB auf dem NAS-Storage) oder bewusst für einen zukünftigen Zweck stehen gelassen werden — sollte geklärt werden, was ursprünglich damit vorgesehen war.
Backup-Strategie — Erledigt: 105 wurde in den automatisierten PBS-Backup-Job nightly-pbs aufgenommen (täglich 03:00, siehe PBS-Doku).backup/restore-Samba-Freigaben klären: Zweck und ob dahinter eine Automatisierung (Cron/Skript) hängt, wurde nicht weiter untersucht — falls dort ein manueller Backup-Workflow lief, sollte geprüft werden, ob er noch gebraucht wird oder durch den PBS-Job ersetzt werden kann.