Pingvin Share X: große Dateien teilen ohne WeTransfer

Ein 800-MB-Video an eine Kollegin schicken – und dafür einen fremden Dienst benutzen, der die Datei für dich behält, so lange er mag. Es geht auch anders: ein Upload-Feld auf deinem eigenen Server, ein Link mit Ablaufdatum, danach ist die Datei weg.

Was bauen wir?

Wir betreiben Pingvin Share X 2.0.0 hinter Traefik. Du lädst Dateien hoch, bekommst einen kurzen Link, und die Freigabe kann ablaufen, ein Passwort verlangen und nach einer festgelegten Zahl von Abrufen verschwinden. Wer den Link bekommt, braucht kein Konto und keine App.

Genauso wichtig ist der zweite Teil: Ein Upload-Dienst im offenen Netz ist eine Einladung, wenn er falsch konfiguriert ist. Wir schalten deshalb die offene Registrierung ab, begrenzen die Dateigröße und schauen uns an, wie die Daten tatsächlich auf der Platte liegen.

Voraussetzungen

• Traefik als Reverse Proxy mit funktionierendem Let’s-Encrypt-Resolver und einer Domain, die auf den Server zeigt
• Genug Plattenplatz für das, was du teilen willst – die Dateien liegen unkomprimiert auf dem Server, bis die Freigabe abläuft
• Ein aufgeräumtes Verständnis davon, wem du Links schickst; mehr dazu in Schritt 3

Schritt für Schritt

Schritt 1: Den Stack anlegen

mkdir -p /opt/pingvin/data/images && cd /opt/pingvin

Die Unterordner legen wir gleich mit an, weil Pingvin sonst beim ersten Start ins Leere greift.

# /opt/pingvin/compose.yaml
services:
  pingvin:
    image: ghcr.io/smp46/pingvin-share-x:v2.0.0
    container_name: pingvin
    restart: unless-stopped
    environment:
      TRUST_PROXY: "true"
    volumes:
      - ./data:/opt/app/backend/data:rw
      - ./data/images:/opt/app/frontend/public/img:rw
    networks: [proxy]
    labels:
      - traefik.enable=true
      - traefik.http.routers.pingvin.rule=Host(`DEINE_DOMAIN`)
      - traefik.http.routers.pingvin.entrypoints=websecure
      - traefik.http.routers.pingvin.tls.certresolver=le
      - traefik.http.services.pingvin.loadbalancer.server.port=3000

networks:
  proxy:
    external: true

TRUST_PROXY: "true" ist der Eintrag, den man leicht übersieht: Ohne ihn protokolliert Pingvin jeden Zugriff mit der IP von Traefik statt der des Besuchers. Steht kein Proxy davor, muss der Wert false bleiben – sonst darf jeder Client seine Quell-IP selbst behaupten.

Der Image-Tag ist bewusst festgenagelt. Es gibt auch einen :beta-Kanal des Projekts – für einen Dienst, der fremde Uploads annimmt, ist die stabile Version die richtige Wahl.

docker compose up -d
docker compose ps

NAME      STATUS
pingvin   Up 25 seconds (healthy)

Das (healthy) kommt vom mitgelieferten Healthcheck – der Container meldet sich also nicht nur als gestartet, sondern antwortet auch. Ein Blick in die Logs bestätigt den sauberen Start:

docker compose logs --tail 1

LOG [NestApplication] Nest application successfully started

Beim ersten Start legt Pingvin vorher die SQLite-Datenbank an und spielt gut 40 Migrationen ein; das dauert ein paar Sekunden. Optional kann Pingvin hochgeladene Dateien von einem ClamAV-Container prüfen lassen. Für ein privates Setup, bei dem nur du hochlädst, ist das verzichtbar; sobald Fremde bei dir ablegen dürfen (siehe Reverse Shares weiter unten), lohnt es sich.

Prüf von außen, dass die Kette steht:

curl -s -o /dev/null -w "%{http_code}\n" https://DEINE_DOMAIN/

200

Schritt 2: Das erste Konto anlegen – und die Tür danach zumachen

Ruf https://DEINE_DOMAIN/auth/signUp auf. Der erste registrierte Benutzer wird automatisch Administrator – es gibt kein Standardpasswort, das man vergessen könnte zu ändern.

Schritt 3: Die Einstellungen, die wirklich zählen

Unter Configuration → General trägst du zuerst die App URL ein – also https://DEINE_DOMAIN. Das ist keine Kosmetik: Aus diesem Wert baut Pingvin die Links, die du verschickst. Steht dort der Standard http://localhost:3000, bekommen deine Empfänger Links, die bei ihnen ins Nichts zeigen.

Der wichtigere Teil steht unter Configuration → Security & Access:

• Allow registration – aus. Du bist der einzige, der Freigaben anlegt. Danach leitet /auth/signUp nur noch weiter, und auch die API lehnt neue Konten ab („Registration is not allowed“).
• Secure cookies – an. Damit setzt Pingvin das Secure-Flag auf seinen Cookies, sie werden also nie über unverschlüsseltes HTTP übertragen. Das geht nur, weil Traefik davor sauberes HTTPS liefert.
• Allow unauthenticated shares – ab Werk aus, und das bleibt es. Sonst kann jeder Besucher Dateien auf deinem Server ablegen.

Jede Seite hat ihren eigenen Save-Knopf, also vor dem Wechseln speichern. Unter Configuration → Share stehen dann noch zwei Werte, die du bewusst entscheiden solltest:

• Default share ID length – Standard 8. Pingvin schreibt selbst dazu: „A value below 8 is not considered secure." Der Link ist das Passwort, solange du keines setzt; kürzere IDs lassen sich durchprobieren.
• Max size – Standard 1 GB. Setz das auf einen Wert, den dein Plattenplatz verträgt, und bedenke, dass mehrere Freigaben gleichzeitig offen sein können.

Interessant ist außerdem die Chunk size (Standard 10 MB): Pingvin lädt große Dateien in Stücken hoch. Deshalb funktionieren Multi-Gigabyte-Uploads auch durch einen Reverse Proxy hindurch, ohne dass du an Timeouts oder Größenlimits schrauben musst.

Schritt 4: Eine Freigabe mit Ablauf, Passwort und Abruflimit

Auf Upload ziehst du eine Datei ins Feld – danach öffnet sich der Dialog:

Die Link-ID wird zufällig erzeugt; über Generate bekommst du eine neue, und du kannst sie auch durch etwas Sprechendes ersetzen – nur eben nicht durch etwas Ratbares. Darunter stehen drei Begrenzungen, die unabhängig voneinander wirken:

• Expiration – nach Ablauf ist die Freigabe weg, standardmäßig nach sieben Tagen. „Permanent share" gibt es auch; benutz es sparsam, sonst füllt sich die Platte mit Dingen, an die sich niemand mehr erinnert.
• Password protection – ein zusätzliches Passwort. Verschick es über einen anderen Kanal als den Link, sonst ist es Theater.
• Maximum views – nach der eingestellten Zahl von Abrufen schließt sich die Freigabe. Praktisch für „genau einmal, genau diese Person".

Ein Klick auf Share legt die Freigabe an und zeigt den fertigen Link mit dem Ablaufdatum.

Schritt 5: Die Empfängersicht – und die Gegenprobe

So sieht es aus, wenn jemand den Link ohne Passwort öffnet:

Dass das nicht nur die Oberfläche ist, zeigt die API. Frag die Freigabe direkt ab, ohne Passwort:

curl -s https://DEINE_DOMAIN/api/shares/DEINE_SHARE_ID

{"message":"This share is password protected","error":"share_password_required","statusCode":403}

Kein Dateiname, keine Größe, keine Liste – der Server gibt vor der Passworteingabe nichts preis. Nach der Eingabe erscheint der Inhalt:

Einzelne Dateien lassen sich direkt herunterladen, mehrere packt Pingvin auf Wunsch in ein ZIP.

Schritt 6: Reverse Shares – wenn andere dir etwas schicken sollen

Der Weg zurück ist der eigentlich unterschätzte Teil. Unter Reverse shares in deinem Konto erzeugst du mit einem Klick auf Create einen Upload-Link der Form https://DEINE_DOMAIN/upload/EINE_ID. Den schickst du jemandem, die Person lädt hoch – ohne Konto, ohne Anmeldung – und die entstehende Freigabe landet bei dir.

Der Dialog hat dieselbe Sorgfalt verdient wie die normale Freigabe. Neben dem Ablaufdatum gibt es Max share size, Max uses („The maximum number of times this URL can be used.") sowie Simple mode und Public access. Max uses steht ab Werk auf 1 – lass es dabei, wenn du genau eine Lieferung erwartest. Jeder höhere Wert (bis 1000) heißt: Bis dahin kann jeder, an den der Link weitergereicht wird, auf deinem Plattenplatz ablegen. Public access ist ab Werk an; dann kann jeder mit dem Link der entstandenen Freigabe sie auch ansehen. Schaltest du es ab, sehen sie nur du und die Person, die hochgeladen hat.

Für die Link-Länge gilt hier dasselbe wie oben: Pingvin benutzt die eingestellte Default share ID length ausdrücklich auch für Reverse Shares. Und weil jetzt fremde Dateien auf deinem Server landen, ist das der Moment, an dem sich die ClamAV-Anbindung tatsächlich lohnt.

Wenn es nicht funktioniert

Dein Problem ist nicht dabei? Alle Fehlermeldungen durchsuchen →

Wartung & Backups

Updates sind ein Tag-Wechsel. Schau vorher in die Release Notes, weil der Fork aktiv entwickelt wird und in kurzen Abständen Versionen erscheinen:

cd /opt/pingvin
cp -a data data-backup-$(date +%F)
sed -i 's/pingvin-share-x:v2.0.0/pingvin-share-x:vNEUE_VERSION/' compose.yaml
docker compose pull && docker compose up -d
docker compose logs --tail 5

Die Kopie vorher ist wichtig, weil beim Start Datenbankmigrationen laufen. Ein Update pro Quartal reicht in der Praxis, sofern nichts Sicherheitsrelevantes gemeldet wird.

Sichern musst du zwei Dinge, und beide liegen unter data/:

/opt/pingvin/data/pingvin-share.db     # Konten, Freigaben, Einstellungen (SQLite)
/opt/pingvin/data/uploads/             # die eigentlichen Dateien

Hier lohnt sich eine Überlegung, die man bei anderen Diensten nicht anstellt: Willst du die Uploads überhaupt sichern? Der Sinn der Sache ist, dass die Dateien nach dem Ablaufdatum verschwinden. Ein Backup, das sie festhält, macht genau das rückgängig – und weil sie unverschlüsselt liegen, wandern sie im Klartext in dein Backup-Ziel. Für die meisten reicht es, die Datenbank zu sichern und die Uploads bewusst wegzulassen. Wenn du beides mitnimmst, gehört das Backup verschlüsselt, so wie es Restic ohnehin macht.

Aufräumen passiert nicht von allein, wenn du „Permanent share" benutzt. Abgelaufene Freigaben räumt Pingvin selbst weg; dauerhafte bleiben liegen, bis du sie löschst. Ein Blick alle paar Monate auf du -sh /opt/pingvin/data/uploads sagt dir, ob sich etwas angesammelt hat.

Realistischer Aufwand: Nach dem Aufsetzen fast nichts – ein Update pro Quartal und der gelegentliche Blick auf den Plattenplatz. Der einzige Punkt, der Disziplin braucht, ist der Umgang mit den Links: Jeder verschickte Link ist ein Zugang, und anders als ein Passwort lässt er sich nicht zurückrufen. Dafür gibt es das Ablaufdatum.