Wer im Unternehmen schnell Dateien ablegen, teilen und wieder abholen muss, landet meist bei einer der großen Groupware-Lösungen. Die bringen Datenbank, Cache, Hintergrunddienste und ein entsprechendes Betriebsgewicht mit. Für viele Alltagsfälle ist das deutlich zu viel: Ein Kunde soll ein Archiv hochladen, eine Außenstelle braucht eine WebDAV-Freigabe, ein Techniker will Logs vom Notebook auf den Server schieben. Genau für diese Fälle ist copyparty gebaut.

copyparty ist ein einzelner Serverprozess, der ein oder mehrere Verzeichnisse per Web-Oberfläche, WebDAV, FTP, SFTP, TFTP und optional SMB bereitstellt. Es gibt keine externe Datenbank, keinen Message-Broker und keinen separaten Worker-Container. Diese Anleitung zeigt eine vollständige Docker-Compose-Installation mit Benutzerkonten, Rechtevergabe, Persistenz, Backup und Wiederherstellung. Alle Befehle in dieser Anleitung wurden am 17. September 2026 auf einem Ubuntu-Host mit Docker 29.1.3 tatsächlich ausgeführt, die gezeigten Ausgaben stammen aus diesem Testlauf.

Was copyparty ist und welches Problem es löst

copyparty stammt vom Entwickler mit dem GitHub-Handle 9001 und beschreibt sich selbst als portabler Datei-Server mit beschleunigten, fortsetzbaren Uploads, Deduplizierung, WebDAV, SFTP, FTP, TFTP, Zeroconf, Medien-Indexer und Vorschaubildern. Der gesamte Funktionsumfang steckt in einem Prozess. In der Docker-Variante bedeutet das: ein Container, zwei Bind-Mounts, fertig.

Der praktische Nutzen für Administratoren liegt in der Betriebsarmut. Es gibt keinen Datenbankserver, der ein Major-Upgrade braucht. Es gibt keinen Redis, der bei einem Neustart den Sitzungszustand verliert. Die Dateien liegen als ganz normale Dateien im gemounteten Verzeichnis und sind damit auch ohne copyparty jederzeit lesbar, sicherbar und migrierbar. Wer den Container entfernt, verliert keine Nutzdaten, sondern nur den Index.

Der zweite Nutzen ist die Protokollbreite. Dieselbe Verzeichnisstruktur ist gleichzeitig über den Browser, über eine WebDAV-Laufwerksverbindung und über FTP erreichbar. In gemischten Umgebungen mit Windows-Arbeitsplätzen, Linux-Servern und mobilen Geräten spart das eine Menge Sonderlösungen.

Nutzen und Grenzen im Unternehmenseinsatz

copyparty ist bewusst kein Ersatz für eine vollwertige Kollaborationsplattform. Es gibt keine Kalender, keine Kontakte, keine Aufgabenverwaltung, keine Office-Integration mit gleichzeitiger Bearbeitung und keine Desktop-Sync-Clients im Sinne eines Nextcloud- oder OpenCloud-Clients. Wer Dokumente gemeinsam im Browser bearbeiten will, ist mit copyparty falsch bedient.

Ebenso fehlt eine Benutzerverwaltung mit Selbstregistrierung und Passwort-Reset-Workflow. Konten werden in einer Textdatei gepflegt. Für zehn bis dreißig definierte Konten ist das praktisch, für eine dynamische Nutzerbasis von mehreren hundert Personen wird es unhandlich. Eine Anbindung an einen externen Identity Provider über Reverse-Proxy-Header ist laut offizieller Dokumentation möglich, wurde hier aber nicht getestet.

Gut geeignet: Datei-Austausch mit Kunden und Dienstleistern, Upload-Postfächer, WebDAV-Laufwerke für Außenstellen, schneller interner Datei-Server auf einem kleinen VPS.
Gut geeignet: Medienarchive, weil der eingebaute Indexer Tags aus Audio- und Videodateien liest und Vorschaubilder erzeugt.
Bedingt geeignet: öffentlich erreichbare Freigaben. Das geht, verlangt aber konsequent einen vorgelagerten Reverse Proxy mit TLS und sauber gesetzte Berechtigungen.
Nicht geeignet: gemeinsames Bearbeiten von Office-Dokumenten, Groupware-Funktionen, Versionierung mit Freigabe-Workflows.
Nicht geeignet: Umgebungen, die eine zertifizierte Mandantentrennung mit Audit-Trail pro Dokument verlangen.

Voraussetzungen und Ressourcenbedarf

Der Testaufbau lief auf einem Ubuntu-Host mit zwei CPU-Kernen und 8 GB RAM, Docker in Version 29.1.3 mit dem integrierten Compose-Plugin. Der Speicherverbrauch des laufenden Containers im Leerlauf lag im Test bei rund 38 MiB.

# tatsaechliche Messung aus dem Testlauf
docker stats --no-stream --format '{{.Name}} MEM={{.MemUsage}} CPU={{.CPUPerc}}' copyparty
# Ausgabe:
# copyparty MEM=37.63MiB / 8.218GiB CPU=0.00%

Das ac-Image belegte nach dem Pull 137 MB auf der Platte. Der Speicherbedarf steigt, sobald der Medien-Indexer große Bestände durchläuft und Vorschaubilder erzeugt. Für einen reinen Datei-Server ohne Medienindex reichen 512 MB RAM bequem aus.

Das Projekt veröffentlicht Images für mehrere Architekturen. Laut der offiziellen Docker-Dokumentation im Repository laufen die Varianten min, im und ac auf x86, x86_64, AArch64, arm32, ppc64le und s390x; die schwereren Varianten iv und dj sind auf x86, x86_64 und AArch64 beschränkt. Der Test hier fand auf x86_64 statt.

Projektstand und Versionsstand mit Beleg

Alle folgenden Angaben wurden am 17. September 2026 direkt über die GitHub-API abgerufen, nicht aus Sekundärquellen übernommen.

# Projektdaten abrufen
curl -s https://api.github.com/repos/9001/copyparty
# letztes Release abrufen
curl -s https://api.github.com/repos/9001/copyparty/releases/latest

Merkmal	Wert am 17.09.2026
Repository	9001/copyparty
Sterne	46711
Forks	1903
Letzter Push	16.09.2026
Letztes Release	v1.20.23 vom 06.09.2026
Standard-Branch	hovudstraum
Lizenz	MIT
Archiviert	nein

Die MIT-Lizenz ist hier ein echtes Argument. Es gibt keine Nutzerstaffelung, keine Lizenzschlüssel und keine funktional beschnittene Community-Variante. Der volle Funktionsumfang ist in jedem Image enthalten.

Der im Test gestartete Container meldete seine Version selbst im Log, was die Angabe aus der API bestätigt:

docker compose logs --no-log-prefix | grep -i 'copyparty v'
# Ausgabe:
# copyparty v1.20.23 "sftp is fine too" (2026-09-06)

Die Image-Varianten richtig wählen

Das Projekt veröffentlicht mehrere Image-Editionen, die sich nur im Umfang der mitgelieferten Zusatzbibliotheken unterscheiden. Die Kernfunktionen sind in allen Varianten gleich. Die folgenden Größenangaben stammen aus der offiziellen Docker-Dokumentation des Repositories.

Variante	Größe installiert	Zusatzfunktionen
min	57 MiB	nur copyparty selbst, keine Vorschaubilder
im	70 MiB	Bild-Vorschauen über Pillow, Medien-Tags über Mutagen
ac	163 MiB	im plus ffmpeg für Video- und Audio-Vorschauen, Audio-Transcoding, bessere Tags
iv	211 MiB	ac plus vips für weitere Vorschau-Formate
dj	309 MiB	iv plus Erkennung von Tonart und Tempo in Musikdateien

Die Projektdokumentation empfiehlt ausdrücklich ac, weil die Zusatzfunktionen von iv und dj selten gebraucht werden. Diese Anleitung folgt der Empfehlung und verwendet ghcr.io/9001/copyparty-ac. Wer einen reinen Dateiablage-Server ohne jede Vorschau betreibt, spart mit min rund 100 MiB Image-Größe.

Hinweis aus der Projektdokumentation: Die offiziellen Images können aus rechtlichen Gründen keine HEIF- und HEIC-Bilder sowie kein H.265-Video verarbeiten. Für ein Fotoarchiv aus iPhone-Aufnahmen ist das relevant.

Compose-Datei und Konfiguration

Der Aufbau besteht aus drei Dateien in einem Verzeichnis. Für den Produktivbetrieb legen Sie das Verzeichnis nicht unter /tmp an, sondern zum Beispiel unter /opt/copyparty.

# Verzeichnisstruktur anlegen
mkdir -p /opt/copyparty/cfg /opt/copyparty/data/public
cd /opt/copyparty

Die compose.yaml, die im Test tatsächlich verwendet wurde:

services:
  copyparty:
    image: ghcr.io/9001/copyparty-ac:latest
    container_name: copyparty
    user: "1000:1000"
    ports:
      - "127.0.0.1:18080:3923"
    volumes:
      - ./cfg:/cfg:z
      - ./data:/w:z
    environment:
      PYTHONUNBUFFERED: "1"
    stop_grace_period: 15s
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "wget --spider -q 127.0.0.1:3923/?reset=/._"]
      interval: 30s
      timeout: 5s
      retries: 5
      start_period: 15s

Die Konfiguration selbst liegt in cfg/copyparty.conf. Das Format sieht wie YAML aus, ist aber ein eigenes Format. Wichtig: Kommentare am Zeilenende brauchen zwei Leerzeichen vor dem Rautezeichen. Das Passwort ist hier als Platzhalter eingetragen und muss vor dem ersten Start ersetzt werden.

[global]
  e2dsa
  e2ts
  ansi
  hist: /cfg/hists/
  ver

[accounts]
  admin: BITTE-HIER-EIGENES-STARKES-PASSWORT-EINTRAGEN

[/]
  /w
  accs:
    rwmda: admin

[/oeffentlich]
  /w/public
  accs:
    r: *
    rwmda: admin

Diese Konfiguration legt zwei Freigaben an. Unter der Wurzel-URL liegt das gesamte Datenverzeichnis, erreichbar nur für das Konto admin mit vollen Rechten. Unter /öffentlich liegt ein Unterordner, den jeder ohne Anmeldung lesen darf. Das ist das typische Muster für eine Download-Bereitstellung.

Wichtige Parameter im Überblick

Parameter	Wirkung
e2dsa	Dateisystem-Index aktivieren, Basis für Suche und Deduplizierung
e2ts	Medien-Indexierung aktivieren, liest Tags aus Audio- und Videodateien
hist: /cfg/hists/	Index, Vorschaubilder und Verlauf ins Konfigurationsverzeichnis statt in jede Freigabe legen
ver	Versionsnummer im Kontrollpanel anzeigen
ansi	Farbige Log-Ausgabe
r	Leserecht: Dateien sehen und herunterladen
w	Schreibrecht: hochladen, ohne den Bestand zu sehen
m	Verschieben und umbenennen
d	Löschen
a	Administrationsrechte in dieser Freigabe
df: 16	Uploads ablehnen, wenn weniger als 16 GB frei sind
ipa: lan	Nur Verbindungen aus dem lokalen Netz annehmen

Die Kombination rwmda vergibt alle fünf Rechte auf einmal. Für ein reines Upload-Postfach, in dem der Absender die bereits vorhandenen Dateien nicht sehen soll, verwenden Sie stattdessen nur w.

Installation und erster Start

Nachdem die beiden Dateien liegen, startet der Stack mit einem Befehl. Der erste Start lädt das Image herunter, das dauert je nach Anbindung ein bis zwei Minuten.

# Container im Hintergrund starten
docker compose up -d
# Status pruefen
docker compose ps

Die tatsächliche Ausgabe aus dem Testlauf, gekürzt auf die relevanten Spalten:

NAME        IMAGE                              SERVICE     STATUS           PORTS
copyparty   ghcr.io/9001/copyparty-ac:latest   copyparty   Up (healthy)     127.0.0.1:18080->3923/tcp

Der im Testlauf beobachtete Start dauerte vom Container-Start bis zum Status healthy rund zwölf Sekunden. Das Log zeigt dabei die geladenen optionalen Abhängigkeiten:

docker compose logs --no-log-prefix | tail -20

Auszug aus der echten Ausgabe des Testlaufs:

optional-dependencies OK: sqlite, pillow, pillow-webp, ffmpeg, ffprobe, bwrap, argon2, pyzmq,
  NG: vips, mutagen, pillow-heif, pillow-avif, rawpy, libraw, see --deps (this is fine btw)
thumb                 decoder preference: pil, ff
up2k                  created DB at /cfg/hists/o/up2k.db
up2k                  2 volumes in 0.03 sec
root                  workers OK

Die Meldung NG bei vips und mutagen ist im ac-Image normal und kein Fehler. Das Projekt schreibt selbst dazu, dass das in Ordnung ist. Die Medien-Tags liest ac über ffprobe statt über Mutagen, was im Log ebenfalls sichtbar wird.

Funktions- und Healthcheck

Nach dem Start prüfen Sie zuerst, ob die Weboberfläche antwortet und ob die Rechtevergabe wirklich greift. Die folgenden Befehle und Ausgaben stammen vollständig aus dem Testlauf.

# anonymer Zugriff auf die Wurzel
curl -s -o /dev/null -w "HTTP %{http_code}\n" http://127.0.0.1:18080/
# Ausgabe: HTTP 200

# Zugriff mit Konto
curl -s -o /dev/null -w "HTTP %{http_code}\n" -u admin:IHR-PASSWORT http://127.0.0.1:18080/
# Ausgabe: HTTP 200

Ein anonymer Aufruf liefert bewusst keine Fehlermeldung, sondern eine reduzierte Ansicht. Die tatsächliche Antwort im Test war:

howdy stranger (you're not logged in)
you can browse:
  /oeffentlich/

Das ist genau das gewünschte Verhalten: Der nicht angemeldete Besucher sieht nur die öffentliche Freigabe, nicht den Gesamtbestand. Als Nächstes der Upload- und Download-Test über HTTP PUT.

# Testdatei erzeugen und hochladen
echo "S-EDV Testdatei 2026-09-17" > /tmp/sedv-test.txt
curl -s -o /dev/null -w "HTTP %{http_code}\n" -u admin:IHR-PASSWORT \
  -T /tmp/sedv-test.txt http://127.0.0.1:18080/sedv-test.txt
# Ausgabe: HTTP 201

# Datei wieder herunterladen
curl -s -u admin:IHR-PASSWORT http://127.0.0.1:18080/sedv-test.txt
# Ausgabe: S-EDV Testdatei 2026-09-17

# Upload ohne Anmeldung muss scheitern
curl -s -o /dev/null -w "HTTP %{http_code}\n" \
  -T /tmp/sedv-test.txt http://127.0.0.1:18080/anon.txt
# Ausgabe: HTTP 401

# Upload mit falschem Passwort muss ebenfalls scheitern
curl -s -o /dev/null -w "HTTP %{http_code}\n" -u admin:falsch \
  -T /tmp/sedv-test.txt http://127.0.0.1:18080/x.txt
# Ausgabe: HTTP 403

Auch der in der compose.yaml hinterlegte Healthcheck wurde direkt im Container gegengeprüft und lieferte den Rückgabewert 0:

docker compose exec -T copyparty wget --spider -q 127.0.0.1:3923/?reset=/._
echo $?
# Ausgabe: 0

WebDAV einrichten und testen

WebDAV ist in copyparty nicht optional zuzuschalten, sondern läuft auf demselben Port wie die Weboberfläche mit. Das macht den Betrieb hinter einem Reverse Proxy deutlich einfacher als bei Lösungen mit getrennten Diensten. Der Test bestätigte das:

# unterstuetzte Methoden abfragen
curl -s -I -u admin:IHR-PASSWORT -X OPTIONS http://127.0.0.1:18080/

Die echten Antwort-Header aus dem Testlauf:

Allow: GET, HEAD, POST, PUT, DELETE, OPTIONS, PROPFIND, PROPPATCH, LOCK, UNLOCK, MKCOL, COPY, MOVE
Dav: 1, 2

Der Header Dav mit den Klassen 1 und 2 bedeutet, dass auch Sperren unterstützt werden. Das ist die Voraussetzung dafür, dass Windows- und macOS-Clients die Freigabe sauber als Laufwerk einbinden. Ein Verzeichnis-Listing und das Anlegen eines Ordners funktionierten im Test ebenfalls:

# Verzeichnis-Listing per PROPFIND
curl -s -o /dev/null -w "HTTP %{http_code}\n" -u admin:IHR-PASSWORT \
  -X PROPFIND -H "Depth: 1" http://127.0.0.1:18080/
# Ausgabe: HTTP 207

# Ordner anlegen
curl -s -o /dev/null -w "HTTP %{http_code}\n" -u admin:IHR-PASSWORT \
  -X MKCOL http://127.0.0.1:18080/davtest/
# Ausgabe: HTTP 201

# Ordner wieder loeschen
curl -s -o /dev/null -w "HTTP %{http_code}\n" -u admin:IHR-PASSWORT \
  -X DELETE http://127.0.0.1:18080/davtest/
# Ausgabe: HTTP 200

Ein Hinweis aus der offiziellen Dokumentation, der in der Praxis Ärger spart: Manche WebDAV-Clients können bestehende Dateien nur dann überschreiben, wenn zusätzlich die Option daw gesetzt ist. Ohne diese Option legen solche Clients stattdessen Kopien mit angehängten Zeitstempeln an. Die Option hat allerdings den Nebeneffekt, dass jeder PUT-Upload bestehende Dateien überschreibt, sofern der Benutzer Löschrechte hat. Dieses Verhalten wurde hier nicht selbst getestet.

FTP, SFTP und SMB als Zusatzprotokolle

Die folgenden Angaben stammen aus der offiziellen Projektdokumentation und wurden in diesem Testaufbau nicht selbst getestet, weil dafür weitere Ports und ein passender Client nötig gewesen wären.

FTP aktivieren Sie laut Dokumentation über drei Einträge im Abschnitt global. In Docker braucht FTP zusätzlich einen festgelegten Portbereich für den Passivmodus, der ebenfalls veröffentlicht werden muss.

[global]
  ftp: 3921
  ftp-nat: 203.0.113.10
  ftp-pr: 12000-12099

Der Wert bei ftp-nat muss die tatsächliche externe IP des Servers sein. Bei Host-Networking entfällt der Eintrag. Der Portbereich 12000 bis 12099 erlaubt bis zu 100 gleichzeitige Übertragungen und muss in der compose.yaml und in der Firewall geöffnet werden.

SFTP läuft über die Option sftp mit einer Portangabe und braucht die Bibliothek paramiko, die in den Varianten ac, im, iv und dj bereits enthalten ist. Standardmäßig ist nur die Anmeldung per SSH-Schlüssel erlaubt; Passwort-Anmeldung muss ausdrücklich aktiviert werden.

Für SMB gibt die Projektdokumentation selbst deutliche Warnungen aus: Der SMB-Teil ist nicht vollständig in die interne Dateisystem-Abstraktion integriert, die Entwicklung rät von der Nutzung über das Internet ab und weist auf mögliche Pfad-Traversal-Probleme hin. Wer SMB braucht, sollte im Unternehmensnetz eher Samba einsetzen und copyparty auf HTTP und WebDAV beschränken.

Persistente Daten, Volumes und Dateirechte

copyparty legt keine Nutzdaten in einem undurchsichtigen Format ab. Was hochgeladen wird, landet als normale Datei im gemounteten Verzeichnis. Der Test bestätigte das inklusive korrekter Eigentümerrechte:

ls -ln data/
# Ausgabe:
# drwxr-xr-x 2 1000 1000 40 Sep 17 02:10 public
# -rw-r--r-- 1 1000 1000 27 Sep 17 02:09 sedv-test.txt

Die Angabe user: "1000:1000" in der compose.yaml sorgt dafür, dass die Dateien dem regulären Benutzerkonto auf dem Host gehören und nicht root. Das ist der wichtigste Einzelparameter für den späteren Betrieb, denn nur so lässt sich der Bestand ohne sudo sichern und verschieben. Innerhalb des Containers wurde die Identität bestätigt:

docker compose exec -T copyparty id
# Ausgabe: uid=1000 gid=1000 groups=1000

Die Persistenz über einen kompletten Neustart hinweg wurde ebenfalls geprüft. Nach docker compose down und einem erneuten Start war die Testdatei unverändert abrufbar, der Container meldete wieder healthy, und die beiden Index-Datenbanken lagen mit je 86016 Byte im Konfigurationsverzeichnis.

find cfg/hists -name 'up2k.db' -printf '%p %s Bytes\n'
# Ausgabe:
# cfg/hists/m/up2k.db 86016 Bytes
# cfg/hists/o/up2k.db 86016 Bytes

Durch die Option hist liegen diese Index-Datenbanken zentral unter cfg statt als versteckter Ordner .hist in jeder einzelnen Freigabe. Das hält die Nutzdatenverzeichnisse sauber und vereinfacht die Trennung zwischen Nutzdaten und Metadaten im Backup.

Sichere Netzwerkfreigabe, Reverse Proxy und TLS

Im Testaufbau ist der Port bewusst an 127.0.0.1 gebunden. Das ist auch für den Produktivbetrieb der richtige Weg: Der Container selbst soll nie direkt aus dem Netz erreichbar sein. Die Veröffentlichung übernimmt ein Reverse Proxy, der TLS terminiert.

    ports:
      - "127.0.0.1:18080:3923"

copyparty bringt zwar ein eigenes Selbstsignatur-Zertifikat mit, das aber ausdrücklich als unsicher gekennzeichnet wird. Genau diese Meldung erschien auch im Testlauf:

cert   using default TLS certificate; https will be insecure: /cfg/copyparty/cert.pem

Für den Produktivbetrieb gilt deshalb: TLS gehört vor den Container, nicht hinein. Eine passende nginx-Konfiguration liefert das Projekt unter contrib/nginx/copyparty.conf im Repository mit. Wichtig sind drei Punkte, die in der Projektdokumentation genannt werden und in dieser Anleitung nicht selbst getestet wurden: eine großzügige Obergrenze für die Anfragegröße, damit große Uploads nicht abbrechen; die Weitergabe der echten Client-IP über X-Forwarded-For, damit die Zugriffsbegrenzung und die Sperrlisten sinnvoll arbeiten; und ausreichend hohe Timeouts für langlaufende Übertragungen.

Port ausschließlich auf 127.0.0.1 binden, niemals auf 0.0.0.0, solange kein Proxy davor steht.
Option ipa im Abschnitt global setzen, um Zugriffe auf bestimmte Netze zu beschränken, zum Beispiel ipa: lan oder ipa: 10.0.0.0/8.
Anonyme Schreibrechte nur dort vergeben, wo ein echtes Upload-Postfach gewünscht ist, und dann ausschließlich mit dem Recht w ohne Leserecht.
Die Option df setzen, damit ein vollgelaufener Datenträger nicht den ganzen Host lahmlegt.
Die Option vc-url in der Konfiguration aktivieren: copyparty prüft dann selbst, ob die laufende Version eine bekannte Sicherheitslücke hat, und warnt im Kontrollpanel.

Backup und Wiederherstellung

Weil copyparty keine Datenbank betreibt, ist das Backup denkbar einfach: Es genügt, die beiden Verzeichnisse data und cfg zu sichern. Der Container sollte dafür gestoppt werden, damit kein laufender Upload mitten im Schreibvorgang gesichert wird. Der folgende Ablauf wurde im Test vollständig durchgespielt, inklusive absichtlich herbeigeführtem Datenverlust.

# Container anhalten
docker compose stop
# Nutzdaten und Konfiguration sichern
tar czf /opt/backup/copyparty-$(date +%F).tar.gz -C /opt/copyparty data cfg
ls -l /opt/backup/

Im Testlauf entstand dabei ein Archiv von 7863 Byte, weil der Bestand nur aus der Testdatei und den Indexdateien bestand. Anschließend wurde der Verlust simuliert und die Wiederherstellung geprüft:

# Datenverlust simulieren
rm -rf data cfg/hists
# aus dem Archiv wiederherstellen
tar xzf /opt/backup/copyparty-2026-09-17.tar.gz -C /opt/copyparty
ls -ln data/
# Ausgabe:
# drwxr-xr-x 2 1000 1000 40 Sep 17 02:10 public
# -rw-r--r-- 1 1000 1000 27 Sep 17 02:09 sedv-test.txt

Nach dem erneuten Start war der Dienst wieder healthy und die Testdatei über HTTP abrufbar. Die echte Ausgabe der Gegenprobe:

docker compose up -d
docker compose ps --format '{{.Status}}'
# Ausgabe: Up 13 seconds (healthy)
curl -s -u admin:IHR-PASSWORT http://127.0.0.1:18080/sedv-test.txt
# Ausgabe: S-EDV Testdatei 2026-09-17

Zwei Punkte sind dabei wichtig. Erstens müssen die Eigentümerrechte beim Entpacken erhalten bleiben, sonst kann der Container mit uid 1000 nicht mehr schreiben. Zweitens ist das Verzeichnis cfg mit den Index-Datenbanken zwar nicht zwingend nötig, spart aber bei großen Beständen einen kompletten Neuaufbau des Index. Wer nur die Nutzdaten sichert, verliert nichts Unersetzliches, muss nach der Wiederherstellung aber eine längere Indexierung einplanen.

Updates und Rollback-Grenzen

Ein Update besteht aus zwei Befehlen. Da kein Datenbankschema migriert werden muss, fällt die häufigste Fehlerquelle bei Container-Updates hier weg.

# neues Image holen
docker compose pull
# Container mit neuem Image neu erstellen
docker compose up -d
# Version im Log gegenpruefen
docker compose logs --no-log-prefix | grep -i 'copyparty v'

Für den Produktivbetrieb ist latest als Tag allerdings die schlechtere Wahl. Besser ist ein fester Versions-Tag, damit ein Neustart nicht ungeplant eine neue Version zieht:

    image: ghcr.io/9001/copyparty-ac:1.20.23

Ein Rollback auf eine ältere Version funktioniert, indem der Tag zurückgesetzt und der Container neu erstellt wird. Die Grenze liegt bei den Index-Datenbanken: Wenn eine neuere Version das Schema der up2k.db erweitert hat, kann eine ältere Version damit unter Umständen nichts anfangen. Die Nutzdaten sind davon nie betroffen. Im Zweifel löschen Sie das Verzeichnis cfg/hists, akzeptieren eine erneute Indexierung und behalten alle Dateien. Ein Rollback über mehrere Minor-Versionen hinweg sollte vorher in einer Testumgebung geprüft werden; hier wurde kein Rollback getestet.

Typische Fehler mit Diagnose und Lösung

Der folgende Fehler trat im Testlauf tatsächlich auf und ist lehrreich, weil er auf einer Schutzfunktion beruht. Der erste Start erfolgte mit dem Datenverzeichnis unter /tmp, und /tmp ist auf dem Testhost ein tmpfs, also reiner Arbeitsspeicher. copyparty erkennt das und entzieht der Freigabe von sich aus das Schreibrecht:

vfs  WARNING: write-access was removed from the following volumes because they are
  not mapped to an actual HDD for storage! All uploaded data would live in RAM only,
  and all uploaded files would be LOST on next reboot. To allow uploading and ignore
  this hazard, enable the 'wram' option (global/volflag). List of affected volumes:
  volume=[/], abspath='/w', type=tmpfs, root='/w'

Die Lösung im Produktivbetrieb ist nicht die genannte Option wram, sondern ein Datenverzeichnis auf einem echten Datenträger. Prüfen Sie den Dateisystemtyp vor der Installation:

df -hT /opt/copyparty/data
# Die Spalte Type darf nicht tmpfs sein, sondern sollte ext4, xfs, btrfs oder aehnlich lauten.

Weitere Fehlerbilder und ihre Behandlung:

HTTP 401 beim Upload: Es wurden keine Zugangsdaten mitgeschickt. Im Test genau so beobachtet, wenn curl ohne die Option -u aufgerufen wurde.
HTTP 403 beim Upload: Zugangsdaten vorhanden, aber falsch oder ohne Schreibrecht in dieser Freigabe. Im Test reproduzierbar mit falschem Passwort.
Uploads landen root gehörend im Verzeichnis: Die Zeile user: "1000:1000" fehlt in der compose.yaml. Rechte mit chown -R 1000:1000 korrigieren und die Zeile ergänzen.
Meldung NG bei vips, mutagen, pillow-heif im Log: kein Fehler, sondern der normale Lieferumfang des ac-Images. Das Projekt kennzeichnet das selbst als unproblematisch.
Konfigurationsänderung wirkt nicht: Die Datei muss auf .conf enden und im Verzeichnis liegen, das nach /cfg gemountet ist. Außerdem brauchen Kommentare am Zeilenende zwei Leerzeichen vor dem Rautezeichen, sonst werden sie als Wert gelesen.
Rootless Docker auf Debian bricht mit lsetxattr-Fehler ab: Laut Projekt-FAQ liegt das am Storage-Treiber overlay2 im rootless-Betrieb. Abhilfe laut Dokumentation ist podman oder der Treiber fuse-overlayfs; hier nicht getestet.
Container startet, aber der Healthcheck bleibt auf starting: Die Startphase beträgt laut compose-Datei 15 Sekunden. Erst danach ist der Status aussagekräftig. Im Test war der Container nach rund zwölf Sekunden healthy.

Saubere Deinstallation

Zum Entfernen genügen zwei Schritte. Beachten Sie die Reihenfolge und lesen Sie die Warnung darunter, bevor Sie den zweiten Befehl ausführen.

# Container und Netzwerk entfernen, benannte Volumes loeschen
docker compose down -v
# Image entfernen, falls nicht mehr gebraucht
docker image rm ghcr.io/9001/copyparty-ac:latest

Warnung vor Datenverlust: Der Befehl docker compose down -v löscht benannte Docker-Volumes. Die Nutzdaten liegen in diesem Aufbau in einem Bind-Mount unter ./data und bleiben deshalb erhalten. Wer das Verzeichnis anschließend selbst löscht, löscht den gesamten Dateibestand unwiderruflich. Legen Sie vorher ein Backup an und prüfen Sie es, bevor Sie löschen.

# Nur nach geprueftem Backup ausfuehren: entfernt alle Nutzdaten endgueltig
rm -rf /opt/copyparty

Der Testaufbau dieser Anleitung wurde nach Abschluss auf genau diesem Weg vollständig zurückgebaut.

Passende Anleitungen auf S-EDV

SFTPGo als SFTP- und WebDAV-Server: die Alternative, wenn der Schwerpunkt auf SFTP-Konten und feingranularer Benutzerverwaltung liegt statt auf einer Weboberfläche.
OpenCloud mit Docker einrichten: der Gegenentwurf mit voller Groupware-Funktion, Sync-Clients und entsprechend höherem Betriebsaufwand.
nginx als Reverse Proxy mit TLS einrichten: der nötige Unterbau, um copyparty sicher aus dem Internet erreichbar zu machen.

Quellen

GitHub: 9001/copyparty, Projekt-Repository, Projektdaten abgerufen über die GitHub-API am 17.09.2026.
copyparty: offizielle Docker-Dokumentation im Repository, Image-Varianten, FTP-Hinweise und Empfehlungen für den Container-Betrieb.
copyparty: README mit vollständiger Funktions- und Konfigurationsbeschreibung, Abschnitte zu Konten, Freigaben, WebDAV, FTP, SFTP und SMB.
copyparty: Release-Notes zur Version v1.20.23, veröffentlicht am 06.09.2026.
copyparty: offizielles Beispiel für copyparty.conf im Docker-Betrieb, Grundlage der hier gezeigten Konfiguration.