Proton Drive CLI: Proton Drive aus Skripten und vom Server bedienen

Am 9. Juni 2026 hat Proton die Proton Drive CLI veröffentlicht, ein offizielles Kommandozeilenwerkzeug für Windows, macOS und Linux. Es basiert auf demselben SDK wie die offiziellen Drive-Apps, verschlüsselt Ende-zu-Ende und ist als einzelne ausführbare Datei proton-drive verfügbar. Der Quellcode liegt im öffentlichen SDK-Repository unter cli/.

Die CLI ist für einzelne, zeitlich bestimmte Vorgänge gedacht: Dateien nach einem Build hochladen, einen Ordner per Zeitplan sichern, Freigaben prüfen oder entziehen. Sie synchronisiert nicht im Hintergrund und hängt kein Dateisystem ein. Aktuell ist Version 0.8.0 vom 13. August 2026; die Versionsnummer zeigt, dass sich Befehle und Optionen noch ändern können (Version 0.8.0 hat die Konfliktstrategien mit einer inkompatiblen Änderung neu benannt).

Die Einordnung in die übrigen Linux-Optionen (Rclone, angekündigter Desktop-Client) steht im Statusartikel Proton Drive unter Linux.

Befehlsübersicht

Die Befehle sind in Gruppen organisiert: proton-drive <gruppe> <befehl> [optionen] [argumente]. Gruppennamen lassen sich abkürzen, solange sie eindeutig bleiben; für filesystem gibt es zusätzlich den Alias fs. Ohne Argumente startet eine interaktive Shell. Die vollständige Hilfe liefert proton-drive help bzw. proton-drive <gruppe> <befehl> --help.

Die Pfade in Proton Drive sind immer POSIX-Pfade, auch unter Windows. Die Wurzel / enthält virtuelle Bereiche: /my-files (eigene Dateien), /devices (gesicherte Computer), /shared-by-me, /shared-with-me, /trash sowie die Photos-Bereiche /photos, /albums, /photos-shared-by-me, /photos-shared-with-me und /photos-trash.

Installation unter Linux

Proton stellt die Builds auf einer eigenen Downloadseite bereit, jeweils mit SHA-512-Prüfsumme. Für Linux gibt es fünf Varianten:

Bricht der Standard-Build beim Start mit Illegal instruction ab, fehlt der CPU die AVX2-Erweiterung; dann ist der x64-baseline-Build die richtige Wahl. Die Datei bringt die Bun-Laufzeit eingebettet mit und braucht keine weiteren Abhängigkeiten:

chmod +x proton-drive
sudo install -m 0755 proton-drive /usr/local/bin/proton-drive
proton-drive version

Ohne Administratorrechte genügt es, die Datei nach ~/.local/bin zu kopieren, sofern dieses Verzeichnis im PATH liegt.

Anmeldung, auch auf Servern ohne Desktop

auth login fragt kein Passwort auf der Kommandozeile ab. Die CLI versucht, einen Browser zu öffnen, und gibt zusätzlich die Anmelde-URL aus. Diese URL lässt sich auf einem anderen Gerät öffnen; das Terminal wartet, bis die Anmeldung dort abgeschlossen ist. Die Zwei-Faktor-Authentifizierung läuft dabei regulär im Browser. Damit funktioniert die Anmeldung auch per SSH auf einem Server ohne grafische Oberfläche.

proton-drive auth login

Nach erfolgreicher Anmeldung speichert die CLI die Session, nicht das Passwort. Wo sie liegt, bestimmt die Umgebungsvariable PROTON_DRIVE_CREDENTIALS_STORE:

Auf einem Server ohne Desktop-Sitzung fehlt in der Regel ein entsperrter libsecret-Schlüsselbund. Für diesen Fall gibt es seit Version 0.6.0 die Option pass. Der Benutzer, unter dem die Skripte laufen, braucht dafür einen initialisierten Passwort-Store und einen GPG-Schlüssel, den der gpg-agent ohne interaktive Eingabe entsperren kann. Die Session muss bei jedem Aufruf über dieselbe Variable gefunden werden, also auch in Cron-Jobs und systemd-Units gesetzt sein:

export PROTON_DRIVE_CREDENTIALS_STORE=pass
proton-drive auth login

Gegenüber Rclone ist das ein Fortschritt: Passwort und TOTP-Schlüssel liegen nicht auf dem Server, und auth logout beendet den Zugang. Die Session hat aber weiterhin den vollen Umfang des Kontos. Eine Beschränkung auf einzelne Ordner oder nur lesenden Zugriff gibt es nicht. Für automatisierte Abläufe bleibt deshalb ein eigenes Proton-Konto die sicherere Variante.

Cache, Anwendungsdaten und Protokolle liegen unter Linux in den XDG-Verzeichnissen (~/.cache/proton-drive-cli, ~/.local/share/proton-drive-cli, ~/.local/state/proton-drive-cli). Mit PROTON_DRIVE_CACHE_DIR lassen sich alle drei in ein einziges Verzeichnis legen, etwa für einen Container mit eingebundenem Volume. Die Protokolle schreibt die CLI standardmässig mit Level DEBUG; PROTON_DRIVE_LOG_LEVEL=WARNING reduziert die Menge.

Hochladen und Herunterladen in Skripten

Interaktiv fragt die CLI bei jedem Namenskonflikt nach, was geschehen soll. In Skripten ist das nicht möglich: Mit --json ist die interaktive Rückfrage abgeschaltet. Legen Sie deshalb die Konfliktstrategie für Dateien und Ordner immer ausdrücklich fest.

proton-drive filesystem upload --json \
  --file-conflict-strategy create-new-revision \
  --folder-conflict-strategy merge \
  --skip-thumbnails \
  /srv/export/berichte /my-files/backup

create-new-revision ist für Sicherungen die passende Wahl: Proton Drive behält die früheren Versionen einer Datei, und Dateien mit unverändertem Inhalt überspringt die CLI seit Version 0.7.0 automatisch. Die CLI gleicht aber nicht ab: Lokal gelöschte Dateien bleiben in Proton Drive erhalten. Wer einen Spiegel mit Löschungen braucht, ist weiterhin auf rclone sync angewiesen.

Das Herunterladen funktioniert spiegelbildlich. Die Strategien unterscheiden sich, weil hier die lokale Seite überschrieben wird:

proton-drive filesystem download --json \
  --file-conflict-strategy remove \
  --folder-conflict-strategy merge \
  /my-files/backup/berichte /srv/restore

Proton Docs und Proton Sheets überspringt die CLI beim Herunterladen; sie lassen sich derzeit nicht als Dateien exportieren.

Ein regelmässiger Upload lässt sich mit einem systemd-Timer oder Cron einplanen. Die JSON-Ausgabe lässt sich anschliessend mit jq auswerten, etwa für eine Meldung an das Monitoring.

Freigaben verwalten

Für Offboarding oder Audits ist die Freigabeverwaltung oft nützlicher als der Dateitransfer. sharing status zeigt für ein Element alle Mitglieder, offenen Einladungen und die Einstellungen eines öffentlichen Links:

proton-drive sharing status --json /my-files/projekte/kunde-a

Eine Einladung mit Leserechten:

proton-drive sharing invite \
  --user person@example.com \
  --role viewer \
  /my-files/projekte/kunde-a

Ein öffentlicher Link mit Passwort und Ablaufdatum:

proton-drive sharing set-url \
  --role viewer \
  --password 'Linkpasswort' \
  --expiration 2026-12-31 \
  /my-files/projekte/kunde-a/bericht.pdf

Ein auf der Kommandozeile übergebenes Passwort steht in der Shell-History und ist während der Ausführung in der Prozessliste sichtbar. In Skripten sollte es deshalb aus einer Variablen oder einem Secret-Speicher kommen. sharing remove-url entfernt den Link wieder, ohne direkte Mitglieder zu betreffen; sharing remove --user … entzieht einzelnen Personen den Zugriff.

In Arbeit: Takeout

Im SDK-Repository ist seit dem 10. September 2026 ein weiterer Befehl takeout run enthalten. Er exportiert eine Offline-Kopie des Kontos in einen lokalen Ordner, wahlweise mit --include my-files, devices, photos und revisions (alle früheren Dateiversionen). Zu jedem Ordner schreibt er eine manifest.json, die den Export beschreibt; am Konto ändert er nichts. In der veröffentlichten Version 0.8.0 ist der Befehl noch nicht enthalten. Sobald er erscheint, ist er der naheliegende Weg für eine vollständige lokale Sicherung des Proton-Drive-Inhalts.

Grenzen im Vergleich mit Rclone

Für Sicherungen, Build-Artefakte und Freigabeverwaltung ist die CLI die bessere Wahl, weil sie offiziell unterstützt wird und ohne gespeichertes Passwort auskommt. Für einen Mount, wie ihn etwa eine Paperless-Dokumentablage braucht, und für Spiegelungen mit Löschungen bleibt Rclone vorerst notwendig. Die grösste Lücke bleibt in beiden Fällen dieselbe: Proton bietet keinen Maschinenzugang, der sich auf einzelne Ordner oder Lesezugriff beschränken lässt.