Armó un cliente de Google Drive en Linux solo con rclone

Google Drive en Linux no tiene cliente oficial de escritorio. Nunca lo tuvo. La alternativa más sólida hoy es rclone con bisync: sincronización bidireccional, automatización con systemd y resolución de conflictos configurable. Si administrás servidores WordPress en Linux y necesitás backups o archivos sincronizados con Google Drive, esta guía te arma todo el stack desde cero.

Linux es un sistema operativo de código abierto basado en el kernel creado por Linus Torvalds en 1991, mantenido por una comunidad global de desarrolladores. Se utiliza en servidores, dispositivos móviles, sistemas embebidos y computadoras de escritorio.

Por qué Linux todavía no tiene un cliente oficial de Google Drive

Google prometió un cliente de Drive para Linux allá por 2012. Catorce años después, seguimos esperando. Las alternativas que fueron apareciendo tienen sus problemas: GNOME Online Accounts monta Drive como sistema de archivos virtual pero no sincroniza offline, Grive dejó de mantenerse, y ODrive nunca terminó de cuajar en la comunidad.

Rclone cambió eso.

Es open source, soporta más de 50 servicios cloud (no solo Google Drive), y desde la versión 1.66 tiene sincronización bidireccional nativa. Para cualquiera que administre servidores Linux (WordPress incluido), rclone te da un nivel de control que ningún cliente con GUI te ofrece: filtros granulares, automatización por systemd, ejecución headless, y cero dependencias gráficas.

Instalación y configuración inicial de rclone con Google Drive

Primer punto importante: no uses la versión de rclone que viene en los repositorios de tu distribución. En Debian y Ubuntu suele estar desactualizada. Bajá el binario oficial desde rclone.org o usá el instalador rápido:

curl https://rclone.org/install.sh | sudo bash

Necesitás v1.66 o superior para bisync. Verificá con rclone version.

Para configurar el remote de Google Drive, ejecutá rclone config y seguí el asistente interactivo. Elegí «drive» como tipo de storage, dejá client_id y client_secret vacíos (usa los de rclone por defecto), y cuando te pida scope seleccioná «drive» (acceso completo). El proceso te abre un navegador para autenticarte con OAuth. Ojo: la pantalla de Google te va a decir que la app «no está verificada», lo cual es normal para rclone.

Un flag que te conviene agregar desde el arranque es --drive-skip-gdocs. Los documentos nativos de Google (Docs, Sheets, Slides) no son archivos reales con contenido descargable, son punteros. Si no los excluís, rclone intenta descargarlos como archivos vacíos y genera confusión. Si te interesa, podés leer más sobre estrategias de segmentación de red perimetral.

Sincronización bidireccional con rclone bisync

Acá está el corazón de todo el setup. Rclone tiene dos modos de sincronización y la diferencia es crítica:

• rclone sync: unidireccional. Copia el origen al destino y borra lo que sobra en el destino. Si lo apuntás al revés, perdés datos.
• rclone bisync: bidireccional. Compara ambos lados, detecta cambios, y sincroniza en las dos direcciones.

La primera vez que corrés bisync, tenés que usar el flag --resync. Esto construye el «estado base» contra el que se van a comparar los cambios futuros. Sin ese paso inicial, según la documentación oficial de rclone, bisync no tiene forma de saber qué archivos son nuevos y cuáles fueron borrados intencionalmente.

Un comando inicial típico se ve así:

rclone bisync /home/usuario/Drive drive:/ --resync --drive-skip-gdocs --verbose

Para ejecuciones posteriores (sin –resync), los flags que te van a salvar de desastres son tres. --resilient permite que bisync se recupere de errores sin abortar todo el ciclo. --check-access verifica que exista un archivo llamado RCLONE_TEST en ambos lados antes de proceder; si no lo encuentra, asume que algo salió mal y frena. Y --max-delete 50 limita la cantidad de archivos que puede borrar por ciclo, evitando que un error de configuración te limpie todo el Drive de un saque.

Resolución de conflictos: qué pasa cuando un archivo cambia en ambos lados

Este es el escenario que más preguntas genera. Editás un archivo en tu máquina mientras estás offline, alguien (o vos mismo desde el celular) lo edita en Google Drive, y al volver la conexión bisync tiene dos versiones distintas del mismo archivo. Si te interesa, podés leer más sobre plugins gratuitos que amplían WordPress.

El flag --conflict-resolve define qué versión gana. Las opciones más útiles: newer (gana el más reciente por fecha de modificación), larger (gana el más grande), path1 (siempre gana el local), path2 (siempre gana el remoto). Si elegís none, bisync conserva ambas versiones.

El perdedor del conflicto se maneja con --conflict-loser. Podés guardarlo con un sufijo numérico (num), con un nombre descriptivo (pathname), o directamente borrarlo (delete, no recomendado).

Para que los archivos en conflicto sean fáciles de identificar, configurá --conflict-suffix sync-conflict-{DateOnly}. Así, si el archivo informe.docx tiene conflicto el 24 de marzo de 2026, la versión perdedora se guarda como informe.sync-conflict-2026-03-24.docx. Limpio y rastreable.

Automatización con servicios systemd y file watchers

Correr bisync a mano cada vez que querés sincronizar no escala. Systemd te resuelve esto con dos componentes: un service (qué ejecutar) y un timer (cuándo ejecutarlo). Si te interesa, podés leer más sobre parches críticos de marzo en AWS.

Creá el archivo ~/.config/systemd/user/rclone-bisync.service:

[Unit]
Description=Rclone bisync Google Drive
[Service]
Type=oneshot
ExecStart=/usr/bin/rclone bisync /home/usuario/Drive drive:/ --resilient --check-access --max-delete 50 --drive-skip-gdocs

Y el timer en ~/.config/systemd/user/rclone-bisync.timer:

[Unit]
Description=Timer para rclone bisync
[Timer]
OnBootSec=2min
OnUnitActiveSec=10min
[Install]
WantedBy=timers.target

Activá todo con systemctl --user enable --now rclone-bisync.timer. Cada 10 minutos, systemd ejecuta el bisync. Si querés algo más reactivo, podés agregar un systemd path unit que monitoree cambios en el directorio local y dispare la sincronización al instante, aunque eso genera más carga de API contra Google.

Un detalle que muchos pasan por alto: si usás crontab con @reboot en vez de systemd, el script se ejecuta antes de que la red esté disponible. Systemd tiene targets de red que evitan ese problema. Si te interesa, podés leer más sobre el ataque a Trivy en GitHub Actions.

Plugin de overlay para KDE Dolphin

Si usás KDE Plasma, vas a notar que Nextcloud y ownCloud tienen íconos de estado sobre las carpetas en Dolphin (el tilde verde de «sincronizado», la flechita de «sincronizando»). Rclone no tiene eso de forma nativa.

En KDE Discuss hay un hilo activo pidiendo integración nativa de rclone con Dolphin. Por ahora, la solución es custom: un script que parsea la salida de bisync, detecta el estado de cada archivo (sincronizado, pendiente, conflicto) y actualiza los emblemas de carpeta mediante la API de KIO.

Funciona, pero requiere mantenimiento manual. No esperes la misma experiencia que Insync o Nextcloud te dan out-of-the-box.

Errores comunes y cómo evitar pérdida de datos

No correr –resync la primera vez

Bisync sin estado inicial no sabe qué cambió. Puede interpretar todos tus archivos locales como «nuevos» y duplicar todo en Drive, o peor, asumir que los archivos remotos que no tiene registrados fueron borrados y eliminarlos. Siempre hacé el --resync inicial y después no lo vuelvas a usar salvo que algo se rompa.

Ignorar la expiración del token OAuth

El token de Google Drive expira a los 200 días. No te avisa, no te manda un mail, no te muestra un error claro. La sincronización deja de funcionar silenciosamente. Ponete un recordatorio para renovarlo con rclone config reconnect drive: antes de que venza. Si te interesa, podés leer más sobre herramientas de protección para WordPress.

No usar –dry-run antes de cambios de configuración

Cada vez que modificás filtros, flags o rutas, corré primero con --dry-run. Bisync tiene el poder de borrar archivos en ambos lados. Un filtro mal puesto puede hacer que considere cientos de archivos como «borrados» y los elimine en el próximo ciclo. También podés encontrar más noticias tech relacionadas en verificación de edad en distros Linux.

Desconocer los límites de la API de Google Drive

Google impone un límite de 750 GiB por día de subida (no documentado oficialmente pero consistente) y un rate limiting de aproximadamente 2 archivos por segundo para operaciones de API. Si tenés muchos archivos pequeños, el bisync puede tardar horas. Las carpetas «Computers» creadas por el cliente de Drive de Windows o Mac son read-only desde la API.

Alternativas a rclone para Google Drive en Linux

Rclone no es la única opción. Dependiendo de tu caso de uso, puede que otra herramienta te sirva mejor.

Si administrás servidores headless (como los que corren WordPress en un VPS de donweb.com), rclone es la única opción viable: funciona sin entorno gráfico, se automatiza con systemd, y soporta decenas de backends cloud. Insync es la mejor alternativa si usás escritorio Linux con KDE o GNOME y preferís no tocar la terminal. Para temas generales de administración de servidores WordPress, en donweb.news hay guías que complementan bien este tipo de configuraciones.

Preguntas Frecuentes

¿Cómo sincronizar Google Drive en Linux sin cliente oficial?

Instalá rclone v1.66 o superior, configurá un remote de tipo «drive» con rclone config, y usá rclone bisync para sincronización bidireccional. Automatizá con un timer de systemd para que corra cada 10-15 minutos sin intervención manual.

¿Qué pasa si edito el mismo archivo en la PC y en Google Drive?

Rclone bisync detecta el conflicto y aplica la política que configuraste con --conflict-resolve. Podés priorizar la versión más nueva, la más grande, o conservar ambas con un sufijo de conflicto que incluya la fecha.

¿Cada cuánto expira la autenticación de rclone con Google Drive?

El token OAuth dura aproximadamente 200 días. Después de eso, rclone deja de sincronizar sin mostrar un error evidente. Renovalo con rclone config reconnect drive: antes de que expire.

¿Puedo usar rclone en un servidor sin entorno gráfico?

Sí. Para la autenticación inicial OAuth necesitás un navegador, pero podés hacerla en otra máquina con rclone authorize y copiar el token al servidor. Una vez configurado, rclone funciona 100% headless.

Conclusión

Google Drive en Linux sin cliente oficial dejó de ser un problema práctico con rclone bisync. La combinación de sincronización bidireccional, resolución de conflictos configurable, y automatización con systemd te da un setup más robusto que el propio cliente de Google en Windows o Mac. El costo es la configuración inicial, que no es trivial, y la renovación del token OAuth cada 200 días.

Si manejás backups de sitios WordPress en servidores Linux y necesitás que los archivos estén en Google Drive, rclone bisync con systemd es la forma más confiable de lograrlo. Arrancá con --resync, configurá --check-access y --max-delete, y probá siempre con --dry-run antes de cualquier cambio. Los datos que perdés por apuro no se recuperan con un flag.

Fuentes

• Rclone Bisync – Documentación oficial de sincronización bidireccional
• Rclone Google Drive backend – Configuración y flags disponibles
• Rclone en GitHub – Repositorio oficial del proyecto
• KDE Discuss – Hilo sobre integración nativa de rclone con Dolphin
• Rclone Forum – Tutorial de bisync con Google Drive y systemd