Proton Drive CLI: controlar Proton Drive desde scripts y servidores

El 9 de junio de 2026, Proton publicó Proton Drive CLI, una herramienta oficial de línea de comandos para Windows, macOS y Linux. Se basa en el mismo SDK que las aplicaciones oficiales de Drive, cifra de extremo a extremo y está disponible como un único archivo ejecutable proton-drive. El código fuente se encuentra en el repositorio público del SDK en cli/.

La CLI está pensada para operaciones individuales y puntuales: subir archivos después de una compilación, realizar una copia de seguridad programada de una carpeta, comprobar o revocar comparticiones. No sincroniza en segundo plano ni monta un sistema de archivos. Actualmente la versión es la 0.8.0 del 13 de agosto de 2026; el número de versión indica que los comandos y las opciones aún pueden cambiar (la versión 0.8.0 renombró las estrategias de conflicto con un cambio incompatible).

La clasificación entre las demás opciones de Linux (Rclone, cliente de escritorio anunciado) se explica en el artículo de estado Proton Drive en Linux.

Resumen de comandos

Los comandos están organizados en grupos: proton-drive <gruppe> <befehl> [optionen] [argumente]. Los nombres de grupo pueden abreviarse siempre que sigan siendo inequívocos; para filesystem existe además el alias fs. Sin argumentos se inicia una shell interactiva. La ayuda completa se obtiene con proton-drive help o proton-drive <gruppe> <befehl> --help.

Las rutas en Proton Drive siempre son rutas POSIX, también en Windows. La raíz / contiene áreas virtuales: /my-files (archivos propios), /devices (equipos con copia de seguridad), /shared-by-me, /shared-with-me, /trash, así como las áreas de Photos /photos, /albums, /photos-shared-by-me, /photos-shared-with-me y /photos-trash.

Instalación en Linux

Proton proporciona las compilaciones en una página de descargas propia, cada una con suma de comprobación SHA-512. Para Linux hay cinco variantes:

Si la compilación estándar termina al iniciarse con Illegal instruction, la CPU no dispone de la extensión AVX2; en ese caso, la compilación x64-baseline es la opción correcta. El archivo incluye el entorno de ejecución Bun integrado y no necesita más dependencias:

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

Sin derechos de administrador, basta con copiar el archivo a ~/.local/bin si este directorio está incluido en PATH.

Inicio de sesión, también en servidores sin escritorio

auth login no solicita ninguna contraseña en la línea de comandos. La CLI intenta abrir un navegador y también muestra la URL de inicio de sesión. Esta URL se puede abrir en otro dispositivo; el terminal espera hasta que el inicio de sesión se complete allí. La autenticación de dos factores se realiza normalmente en el navegador. Así, el inicio de sesión también funciona mediante SSH en un servidor sin interfaz gráfica.

proton-drive auth login

Tras iniciar sesión correctamente, la CLI guarda la sesión, no la contraseña. Su ubicación la determina la variable de entorno PROTON_DRIVE_CREDENTIALS_STORE:

En un servidor sin sesión de escritorio, normalmente falta un llavero libsecret desbloqueado. Para este caso existe, desde la versión 0.6.0, la opción pass. El usuario con el que se ejecutan los scripts necesita para ello un almacén de contraseñas inicializado y una clave GPG que el gpg-agent pueda desbloquear sin entrada interactiva. La sesión debe encontrarse mediante la misma variable en cada llamada, por lo que también debe estar configurada en trabajos de Cron y unidades de systemd:

export PROTON_DRIVE_CREDENTIALS_STORE=pass
proton-drive auth login

Frente a Rclone, esto es una mejora: la contraseña y la clave TOTP no se almacenan en el servidor, y auth logout finaliza el acceso. Sin embargo, la sesión sigue teniendo acceso completo a la cuenta. No es posible limitarla a determinadas carpetas ni al acceso de solo lectura. Por ello, para procesos automatizados sigue siendo más seguro usar una cuenta de Proton independiente.

La caché, los datos de la aplicación y los registros se encuentran en Linux en los directorios XDG (~/.cache/proton-drive-cli, ~/.local/share/proton-drive-cli, ~/.local/state/proton-drive-cli). Con PROTON_DRIVE_CACHE_DIR se pueden colocar los tres en un único directorio, por ejemplo para un contenedor con un volumen montado. De forma predeterminada, la CLI escribe los registros con el nivel DEBUG; PROTON_DRIVE_LOG_LEVEL=WARNING reduce la cantidad.

Subir y descargar en scripts

De forma interactiva, la CLI pregunta qué hacer ante cada conflicto de nombres. Esto no es posible en scripts: con --json se desactiva la consulta interactiva. Por ello, establezca siempre explícitamente la estrategia de conflicto para archivos y carpetas.

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 es la elección adecuada para copias de seguridad: Proton Drive conserva las versiones anteriores de un archivo, y desde la versión 0.7.0 la CLI omite automáticamente los archivos cuyo contenido no ha cambiado. Sin embargo, la CLI no sincroniza: los archivos eliminados localmente se conservan en Proton Drive. Quien necesite un espejo con eliminaciones sigue dependiendo de rclone sync.

La descarga funciona de forma análoga. Las estrategias son diferentes porque aquí se sobrescribe el lado local:

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

La CLI omite Proton Docs y Proton Sheets al descargar; actualmente no se pueden exportar como archivos.

Una subida periódica se puede programar con un temporizador de systemd o Cron. Después, la salida JSON se puede evaluar con jq, por ejemplo para enviar un aviso al sistema de monitorización.

Gestionar comparticiones

Para bajas de personal o auditorías, la gestión de comparticiones suele ser más útil que la transferencia de archivos. sharing status muestra todos los miembros, invitaciones pendientes y la configuración de un enlace público de un elemento:

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

Una invitación con permisos de lectura:

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

Un enlace público con contraseña y fecha de vencimiento:

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

Una contraseña pasada en la línea de comandos queda en el historial de la shell y es visible en la lista de procesos durante la ejecución. Por ello, en scripts debería proceder de una variable o de un almacén de secretos. sharing remove-url vuelve a eliminar el enlace sin afectar a los miembros directos; sharing remove --user … revoca el acceso a personas concretas.

En desarrollo: Takeout

Desde el 10 de septiembre de 2026, el repositorio del SDK contiene otro comando, takeout run. Exporta una copia sin conexión de la cuenta a una carpeta local, opcionalmente con --include my-files, devices, photos y revisions (todas las versiones anteriores de archivos). En cada carpeta escribe un archivo manifest.json que describe la exportación; no modifica nada en la cuenta. El comando aún no está incluido en la versión publicada 0.8.0. Cuando aparezca, será la vía natural para una copia de seguridad local completa del contenido de Proton Drive.

Limitaciones frente a Rclone

Para copias de seguridad, artefactos de compilación y gestión de comparticiones, la CLI es la mejor opción porque cuenta con soporte oficial y no requiere una contraseña almacenada. Para un montaje, como el que necesita por ejemplo un archivo documental de Paperless, y para espejos con eliminaciones, Rclone sigue siendo necesario por ahora. La mayor carencia sigue siendo la misma en ambos casos: Proton no ofrece acceso de máquina que pueda limitarse a carpetas concretas o al acceso de solo lectura.