Proton Drive en Linux: situación en julio de 2026

Proton Drive ofrece clientes de sincronización propios para Windows y macOS desde 2023. En Linux, hasta ahora solo existen la interfaz web, herramientas de la comunidad y un SDK oficial en fase de vista previa. En un servidor, la situación es aún más difícil, porque allí ni la sincronización de escritorio ni un inicio de sesión interactivo encajan bien.

Este resumen describe la situación en julio de 2026. Además de las hojas de ruta publicadas, se basa en una prueba práctica del backend de Rclone como repositorio de documentos para Paperless-ngx.

El cliente para Linux está anunciado, pero sigue sin fecha

En junio de 2026, Proton confirmó por primera vez de forma explícita que está desarrollando un cliente para Linux. Se está creando sobre el nuevo SDK unificado y utilizará la misma base técnica que las aplicaciones para Windows y macOS. Aún no hay fecha ni beta pública.

Importante para contextualizarlo: será un cliente de sincronización de escritorio. Para el escritorio resuelve el problema. Sin embargo, para aplicaciones de servidor, un cliente de sincronización es la herramienta equivocada, pues un servicio debe leer archivos directamente desde Proton Drive y escribirlos allí. Un cliente de sincronización mantiene una copia local completa, precisamente lo que se quiere evitar cuando el almacenamiento es limitado.

Hoy Rclone realiza el trabajo práctico

En Linux, Rclone con su backend protondrive es actualmente la herramienta más versátil. Puede copiar y sincronizar archivos y, como única solución disponible, proporcionar Proton Drive como un directorio local mediante un montaje FUSE. Hay dos limitaciones importantes:

Está en beta y se basa en una API reconstruida. Proton no documenta públicamente su API de Drive; el backend se basa en ingeniería inversa. En las pruebas funcionó de forma fiable, pero limitó las secuencias rápidas de llamadas con listados de directorios inconsistentes.

Para el funcionamiento desatendido, Rclone solicita la clave TOTP. El asistente de configuración denomina el campo otp_secret_key. Se refiere a la clave permanente de la configuración de 2FA, no al código de seis dígitos que muestra en ese momento una aplicación de autenticación. Rclone guarda este valor ofuscado y genera por sí mismo un código TOTP válido en cada inicio de sesión.

Quien introduzca por error un código de un solo uso actual podrá completar el primer inicio de sesión. Sin embargo, la siguiente autenticación volverá a fallar con el error 8002, porque Rclone no puede volver a utilizar el mismo código.

Así, la cuenta permanece protegida frente a una contraseña robada de forma aislada. Sin embargo, un servidor comprometido revela tanto la contraseña como la clave TOTP. Por ello, para accesos automatizados se recomienda una cuenta de Proton dedicada.

El comportamiento de un montaje de este tipo en entornos Docker, incluidos dos problemas no documentados, se explica en el artículo específico sobre Rclone en contenedores.

El SDK oficial muestra hacia dónde va el desarrollo

Paralelamente, Proton está migrando sus aplicaciones a un SDK oficial para JavaScript y C# con bindings para Swift y Kotlin. El repositorio público también incluye una herramienta de línea de comandos. Su modelo de inicio de sesión es más limpio que el del backend de Rclone:

• auth login abre el navegador; el inicio de sesión se realiza normalmente, incluida la autenticación de dos factores
• la sesión se almacena en el llavero del sistema operativo (Keychain, Credential Manager, libsecret), y el SDK la renueva por sí mismo
• después: listar, cargar archivos y comprobar comparticiones con salida JSON legible por máquinas

De este modo, la contraseña y la clave TOTP no tienen que estar en un archivo de configuración. No obstante, para el funcionamiento en servidores siguen existiendo tres límites: la CLI no puede montar un sistema de archivos, el inicio de sesión abre un navegador y Proton aún no considera que el SDK esté listo para producción en aplicaciones de terceros. Su lanzamiento está previsto entre finales de 2026 y principios de 2027.

La verdadera carencia: accesos de máquina

El núcleo del problema está un nivel más abajo que el cliente o el SDK: Proton no tiene accesos de máquina. No hay contraseña de aplicación, cuenta de servicio ni token con alcance limitado. Toda automatización, ya sea un script de copia de seguridad, un montaje de servidor o un trabajo de CI, debe trabajar con las credenciales completas de la cuenta.

Como comparación: en los almacenamientos compatibles con S3, los pares de claves de acceso son lo normal, revocables y restringibles a buckets o prefijos. Google y Microsoft ofrecen contraseñas de aplicación y cuentas de servicio. En Proton, en cambio, es todo o nada: quien quiera dar a un servidor acceso a una carpeta le da acceso a toda la cuenta.

En un servicio con cifrado de extremo a extremo, esto es más difícil que con S3, porque un acceso limitado también tendría que implicar material de claves limitado. Sin embargo, las sesiones del SDK demuestran que Proton domina estas construcciones. Una sesión ya es un acceso derivado y revocable. Un «token de máquina oficial para exactamente esta carpeta, solo lectura» sería el mayor avance individual para el uso en servidores, muy por delante de cualquier cliente.

Recomendación según el caso de uso

En el escritorio Linux se puede esperar al cliente anunciado o usar Rclone por el momento. En servidores, Rclone sigue siendo la única solución práctica de montaje. Sin embargo, una solución provisional funcional solo se convertirá en una plataforma sólida cuando Proton ofrezca accesos de máquina limitados y un montaje compatible oficialmente.