Proton Drive CLI: utilizzare Proton Drive da script e dal server

Il 9 giugno 2026 Proton ha pubblicato la Proton Drive CLI, uno strumento ufficiale da riga di comando per Windows, macOS e Linux. Si basa sullo stesso SDK delle app Drive ufficiali, utilizza la crittografia end-to-end ed è disponibile come singolo file eseguibile proton-drive. Il codice sorgente si trova nel repository SDK pubblico all’indirizzo cli/.

La CLI è pensata per operazioni singole e delimitate nel tempo: caricare file dopo una build, eseguire il backup pianificato di una cartella, verificare o revocare condivisioni. Non sincronizza in background e non monta alcun filesystem. Attualmente è disponibile la versione 0.8.0 del 13 agosto 2026; il numero di versione indica che comandi e opzioni possono ancora cambiare (la versione 0.8.0 ha rinominato le strategie di conflitto con una modifica incompatibile).

La collocazione rispetto alle altre opzioni Linux (Rclone, client desktop annunciato) è illustrata nell’articolo sullo stato Proton Drive su Linux.

Panoramica dei comandi

I comandi sono organizzati in gruppi: proton-drive <gruppe> <befehl> [optionen] [argumente]. I nomi dei gruppi possono essere abbreviati purché rimangano univoci; per filesystem è disponibile anche l’alias fs. Senza argomenti si avvia una shell interattiva. La guida completa è fornita da proton-drive help oppure proton-drive <gruppe> <befehl> --help.

I percorsi in Proton Drive sono sempre percorsi POSIX, anche su Windows. La radice / contiene aree virtuali: /my-files (file propri), /devices (computer sottoposti a backup), /shared-by-me, /shared-with-me, /trash e le aree Photos /photos, /albums, /photos-shared-by-me, /photos-shared-with-me e /photos-trash.

Installazione su Linux

Proton mette a disposizione le build su una pagina di download dedicata, ciascuna con checksum SHA-512. Per Linux sono disponibili cinque varianti:

Se la build standard si interrompe all’avvio con Illegal instruction, alla CPU manca l’estensione AVX2; in tal caso la scelta corretta è la build x64-baseline. Il file include il runtime Bun e non richiede ulteriori dipendenze:

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

Senza diritti di amministratore basta copiare il file in ~/.local/bin, purché questa directory sia nel PATH.

Accesso, anche su server senza desktop

auth login non richiede alcuna password nella riga di comando. La CLI tenta di aprire un browser e mostra inoltre l’URL di accesso. Questo URL può essere aperto su un altro dispositivo; il terminale attende finché l’accesso non viene completato lì. L’autenticazione a due fattori avviene normalmente nel browser. In questo modo l’accesso funziona anche tramite SSH su un server senza interfaccia grafica.

proton-drive auth login

Dopo l’accesso riuscito, la CLI salva la sessione, non la password. La sua posizione è determinata dalla variabile d’ambiente PROTON_DRIVE_CREDENTIALS_STORE:

Su un server senza sessione desktop generalmente manca un portachiavi libsecret sbloccato. Per questo caso, dalla versione 0.6.0 esiste l’opzione pass. L’utente con cui vengono eseguiti gli script necessita di un password store inizializzato e di una chiave GPG che il gpg-agent possa sbloccare senza input interattivo. La sessione deve essere trovata tramite la stessa variabile a ogni esecuzione, quindi deve essere impostata anche nei job Cron e nelle unità systemd:

export PROTON_DRIVE_CREDENTIALS_STORE=pass
proton-drive auth login

Rispetto a Rclone è un progresso: password e chiave TOTP non risiedono sul server e auth logout revoca l’accesso. La sessione mantiene tuttavia l’intera portata dell’account. Non esistono limitazioni a singole cartelle o al solo accesso in lettura. Per i processi automatizzati, un account Proton dedicato resta quindi la variante più sicura.

Cache, dati dell’applicazione e log si trovano su Linux nelle directory XDG (~/.cache/proton-drive-cli, ~/.local/share/proton-drive-cli, ~/.local/state/proton-drive-cli). Con PROTON_DRIVE_CACHE_DIR è possibile collocare tutti e tre in un’unica directory, ad esempio per un container con volume montato. Per impostazione predefinita, la CLI scrive i log con livello DEBUG; PROTON_DRIVE_LOG_LEVEL=WARNING ne riduce la quantità.

Caricare e scaricare negli script

In modalità interattiva, la CLI chiede cosa fare per ogni conflitto di nome. Negli script ciò non è possibile: con --json la richiesta interattiva viene disattivata. Definite quindi sempre esplicitamente la strategia di conflitto per file e cartelle.

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 è la scelta adatta per i backup: Proton Drive conserva le versioni precedenti di un file e, dalla versione 0.7.0, la CLI salta automaticamente i file dal contenuto invariato. La CLI non effettua però un confronto: i file eliminati localmente restano in Proton Drive. Chi necessita di un mirror con eliminazioni dipende ancora da rclone sync.

Il download funziona in modo speculare. Le strategie differiscono perché qui viene sovrascritta la parte locale:

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

La CLI salta Proton Docs e Proton Sheets durante il download; al momento non possono essere esportati come file.

Un upload regolare può essere pianificato con un timer systemd o Cron. L’output JSON può quindi essere analizzato con jq, ad esempio per inviare una notifica al monitoraggio.

Gestire le condivisioni

Per l’offboarding o gli audit, la gestione delle condivisioni è spesso più utile del trasferimento file. sharing status mostra per un elemento tutti i membri, gli inviti aperti e le impostazioni di un link pubblico:

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

Un invito con diritti di lettura:

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

Un link pubblico con password e data di scadenza:

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

Una password passata sulla riga di comando rimane nella cronologia della shell ed è visibile nell’elenco dei processi durante l’esecuzione. Negli script dovrebbe quindi provenire da una variabile o da un archivio di segreti. sharing remove-url rimuove nuovamente il link senza interessare i membri diretti; sharing remove --user … revoca l’accesso a singole persone.

In lavorazione: Takeout

Dal 10 settembre 2026, il repository SDK contiene un ulteriore comando takeout run. Esporta una copia offline dell’account in una cartella locale, a scelta con --include my-files, devices, photos e revisions (tutte le versioni precedenti dei file). Per ogni cartella scrive un file manifest.json che descrive l’esportazione; non modifica nulla nell’account. Il comando non è ancora incluso nella versione pubblicata 0.8.0. Non appena sarà disponibile, rappresenterà il modo più ovvio per un backup locale completo dei contenuti di Proton Drive.

Limiti rispetto a Rclone

Per backup, artefatti di build e gestione delle condivisioni, la CLI è la scelta migliore perché è supportata ufficialmente e non richiede una password memorizzata. Per un mount, come quello necessario ad esempio per un archivio documentale Paperless, e per i mirror con eliminazioni, Rclone resta per ora necessario. In entrambi i casi, la maggiore lacuna rimane la stessa: Proton non offre alcun accesso macchina limitabile a singole cartelle o alla sola lettura.