1 13/04/2026 9 min

Scaricare da Google Drive dal terminale Linux: scegliere lo strumento giusto

Se devi tirare giù un file da Google Drive da una shell Linux, la domanda vera non è “quale comando uso?”, ma “che tipo di accesso ho e quanto deve essere ripetibile il processo”. Per un link pubblico basta un downloader semplice; per account personali, cartelle condivise e automazioni di lungo periodo serve qualcosa che gestisca OAuth, token e refresh; per integrazioni applicative conviene passare dall’API ufficiale o da un tool che la incapsula bene.

In pratica le strade sensate sono tre: gdown per i file condivisi con link o per download rapidi, rclone per sincronizzazioni e mount, oppure Google Drive API quando vuoi controllo fine, auditing e integrazione nel tuo script. La scelta sbagliata di solito porta a problemi molto banali: link che cambiano formato, conferme anti-virus sui file grossi, token scaduti, permessi insufficienti o rate limit.

Quando basta un link pubblico: gdown

Se hai un file condiviso con link pubblico o quasi pubblico, gdown è la soluzione più rapida. È un wrapper Python che gestisce buona parte delle particolarità dei link Google Drive, comprese alcune conferme intermedie che Google mostra sui file grandi o ritenuti potenzialmente rischiosi.

Installazione semplice:

python3 -m pip install --user gdown

Se il tuo PATH non include il binario installato dall’utente, aggiungi la directory locale oppure invoca direttamente il modulo Python. Per verificare:

python3 -m gdown --help

Download di un file da URL di condivisione:

gdown 'https://drive.google.com/uc?id=FILE_ID'

Se hai il link “share” classico, spesso funziona anche così:

gdown 'https://drive.google.com/file/d/FILE_ID/view?usp=sharing'

Per scaricare in una directory precisa e con nome scelto:

gdown 'https://drive.google.com/uc?id=FILE_ID' -O /tmp/nomefile.tar.gz

Per verificare che il file sia arrivato davvero, non fidarti solo dell’assenza di errori a schermo: controlla dimensione e tipo.

ls -lh /tmp/nomefile.tar.gz
file /tmp/nomefile.tar.gz

Il punto debole di gdown è evidente: non è il miglior strumento per workflow complessi con più account, sincronizzazioni bidirezionali o mount persistenti. È ottimo per “scarica questo artefatto e basta”, meno per una pipeline strutturata.

Scaricare file privati o cartelle: rclone è più solido

Quando il contenuto non è pubblico, o devi lavorare con un Drive personale o aziendale, rclone è di solito la scelta migliore. Supporta Google Drive come backend, gestisce autenticazione OAuth, permette copy, sync, list, mount e automatizzazioni abbastanza pulite.

Installazione su molte distribuzioni recenti:

sudo apt install rclone

Su sistemi dove il pacchetto è vecchio, conviene usare il binario ufficiale o il repository della distro, ma il principio resta identico. Dopo l’installazione, configura il remote:

rclone config

Il flusso tipico è questo:

  1. crei un nuovo remote;
  2. scegli drive come tipo di storage;
  3. autorizzi l’accesso con browser o token;
  4. salvi la configurazione in ~/.config/rclone/rclone.conf.

Per vedere se il remote funziona, fai una lista delle cartelle root:

rclone lsd gdrive:
rclone ls gdrive:

Se vedi directory e file, la parte auth è a posto. A quel punto puoi copiare un file locale da Drive così:

rclone copy gdrive:'Percorso/nel/Drive/file.iso' /srv/downloads/

Oppure sincronizzare una cartella remota con una locale:

rclone sync gdrive:'Backup/2026' /backup/gdrive/2026

Qui però va fatta una precisazione importante: sync non è un comando innocuo. Se il lato destro è sbagliato o vuoto, può cancellare file locali. Prima di usarlo in produzione, fai una simulazione con --dry-run e leggi bene l’output.

rclone sync gdrive:'Backup/2026' /backup/gdrive/2026 --dry-run

Per un trasferimento più controllato, spesso è meglio copy che sync. copy aggiunge o aggiorna, ma non rimuove ciò che non trova più sul remoto.

Se vuoi montare Drive come filesystem per operazioni ad hoc, puoi usare rclone mount. Non è un vero filesystem locale e va trattato con cautela, ma per consultazione o tool che leggono da path può essere comodo.

mkdir -p /mnt/gdrive
rclone mount gdrive: /mnt/gdrive --vfs-cache-mode writes

Il parametro --vfs-cache-mode writes riduce sorprese con applicazioni che si aspettano semantiche più normali su file modificabili. Senza cache VFS, alcune app si comportano male. Anche qui: verifica subito con un ls e con una lettura reale di un file piccolo.

Se ti serve una prova rapida della connessione, rclone about gdrive: può dare una visione della capacità disponibile, ma non sempre è utile su tutti gli account. Se il comando risponde con errore di permessi o API, il problema è quasi sempre nel remote, nel token o nelle quote dell’account Google Cloud associato.

API ufficiale: quando vuoi controllo vero

Per script robusti, soprattutto se devono girare in modo unattended, l’approccio più pulito è usare la Google Drive API. È più verbosa rispetto a gdown e più macchinosa di rclone, ma ti dà controllo su permessi, query, metadata, pagination, checksum e gestione errori più prevedibile.

Lo schema tipico è questo: crei un progetto su Google Cloud, abiliti la Drive API, configuri le credenziali OAuth o un service account, poi usi una libreria client o chiamate HTTP per leggere metadata e scaricare il contenuto. La parte che spesso viene sottovalutata è l’autorizzazione: un service account non vede automaticamente il tuo Drive personale, a meno che il file o la cartella non siano esplicitamente condivisi con quell’identità.

Con Python, un flusso essenziale può essere costruito con la libreria client ufficiale. Esempio concettuale:

from googleapiclient.discovery import build
from googleapiclient.http import MediaIoBaseDownload
from google.oauth2.credentials import Credentials
import io

creds = Credentials.from_authorized_user_file('token.json')
service = build('drive', 'v3', credentials=creds)
request = service.files().get_media(fileId='FILE_ID')
fh = io.FileIO('/tmp/file.bin', 'wb')
downloader = MediaIoBaseDownload(fh, request)
done = False
while not done:
    status, done = downloader.next_chunk()
    print(f'{int(status.progress() * 100)}%')

Qui il vantaggio è chiaro: puoi gestire retry, logging applicativo, naming dei file e controllo degli errori in modo coerente. Lo svantaggio è il costo iniziale di setup. Se devi solo prendere un PDF una volta al mese, è overkill.

Problemi tipici e come riconoscerli in fretta

Nel mondo reale i fallimenti sono quasi sempre ripetitivi. Il primo passo non è cambiare tool, ma capire in quale punto si rompe il flusso.

  1. Permessi insufficienti: il file non è condiviso con l’account giusto. Con rclone vedi errori di accesso; con l’API ottieni 403. Verifica la condivisione del file o della cartella nel pannello Drive.
  2. Token scaduto o revocato: il login OAuth non è più valido. In rclone rifai rclone config o rclone config reconnect se disponibile; con API rigenera il token.
  3. Link non più valido o ID errato: con gdown il file non viene trovato. Controlla il file ID nel link e confrontalo con l’URL di condivisione reale.
  4. File troppo grande o conferma intermedia: Google inserisce pagine di warning. gdown spesso le gestisce, ma non sempre. Se il download è instabile, passa a rclone o all’API.

Per isolare il problema in meno di cinque minuti, usa questa sequenza: prova a listare il contenuto con rclone, prova un file piccolo, verifica il link da browser in incognito, poi ripeti il download con un tool diverso. Se due strumenti falliscono nello stesso punto, il problema è quasi certamente lato permessi o condivisione, non nel client.

Automatizzare i download in modo pulito

Quando il download deve finire in uno script, il punto non è solo “funziona”, ma “si capisce se ha funzionato”. Per questo conviene standardizzare tre cose: directory di destinazione, log minimale e controllo post-download.

Esempio con bash e rclone, senza fronzoli:

#!/usr/bin/env bash
set -euo pipefail

DEST=/srv/incoming/gdrive
SRC="gdrive:Release/app.tar.gz"
TMP="$DEST/.partial"
mkdir -p "$TMP"

rclone copy "$SRC" "$TMP" --stats 30s
mv "$TMP"/app.tar.gz "$DEST"/

Qui il vantaggio operativo è evidente: il file arriva prima in un’area temporanea e solo dopo viene spostato nella destinazione finale. Se qualcosa si interrompe a metà, non lasci in giro un artefatto spacciato per completo. Se il flusso è più complesso, puoi aggiungere checksum o confronto dimensionale prima del mv.

Per gdown, uno script essenziale può essere persino più semplice:

#!/usr/bin/env bash
set -euo pipefail

URL='https://drive.google.com/uc?id=FILE_ID'
OUT='/srv/incoming/file.zip'

gdown "$URL" -O "$OUT"
stat "$OUT"
file "$OUT"

Se vuoi un comportamento più “da produzione”, aggiungi un file di log e un controllo sul codice di uscita. Con bash, il minimo sindacale è non ignorare gli errori e non proseguire con file parziali.

Questioni di sicurezza da non ignorare

Scaricare da Google Drive sembra un’operazione innocua, ma i problemi di sicurezza arrivano quando i token vengono trattati male o quando gli script girano con privilegi eccessivi. Il segreto non va mai messo in chiaro dentro i comandi copiati in cron, nella history o in file condivisi.

Se usi rclone o API, proteggi i file di configurazione e i token con permessi stretti:

chmod 600 ~/.config/rclone/rclone.conf
chmod 600 token.json

Se lavori in team, meglio usare un meccanismo di segreti del sistema o un vault, non un file lasciato in home con permessi larghi. E se un token viene esposto, la regola è semplice: ruotalo o revocalo e rigeneralo. Non ha senso “sperare che nessuno lo abbia visto”.

Un altro punto spesso trascurato è l’autorizzazione troppo ampia. Se basta leggere una cartella, non usare credenziali che possono cancellare, spostare o condividere contenuti. Il principio del privilegio minimo vale anche su Drive.

Scelta pratica in base allo scenario

Se devo sintetizzare la scelta senza giri di parole: gdown quando hai un link pubblico e vuoi velocità; rclone quando devi operare con account, cartelle, sync o mount; Drive API quando il download è parte di un’app o di una pipeline che deve essere osservabile e manutenibile.

Una regola empirica utile: se il tuo script verrà eseguito una sola volta e da un operatore, privilegia la semplicità. Se verrà eseguito da cron, da CI o da un job schedulato, investi subito in un flusso con log, retry e verifica finale. Il costo di setup si ripaga alla prima anomalia di rete o al primo token revocato.

In ambienti Linux moderni, il pattern più pulito resta questo: prova prima a leggere il contenuto con il tool più adatto al caso d’uso, verifica che il file sia completo, conserva un log minimo e non dare per scontato che un download riuscito a metà sia un download valido. Google Drive non è un filesystem locale, e trattarlo come tale è il modo più rapido per costruirsi problemi inutili.