| | |

Google Drive sur Nobara Linux

Installation de Google Drive sur Nobara Linux

L’absence de client officiel Google Drive pour Linux impose l’utilisation d’outils tiers performants. Sur Nobara, distribution basée sur Fedora, la solution la plus stable reste rclone. Ce guide explique comment monter son Drive directement dans le gestionnaire de fichiers Dolphin.

1. Pourquoi utiliser rclone pour Google Drive ?

L’intégration native des comptes en ligne peut parfois présenter des lenteurs ou des erreurs d’accès. rclone permet de simuler un disque dur local. Les fichiers restent sur le Cloud mais sont accessibles instantanément depuis le dossier personnel, offrant une fluidité maximale pour la gestion des documents.

2. Installation des outils nécessaires

L’installation se fait via le gestionnaire de paquets de Nobara. On ouvre un terminal pour exécuter la commande suivante :

sudo dnf install rclone

3. Configuration rapide du compte Google

Pour éviter les menus complexes, on privilégie la méthode de création directe. On lance la configuration avec cette commande :

rclone config create gdrive drive scope drive

Une fenêtre de navigateur s’ouvre alors. Il est crucial de suivre ces étapes :

  • Se connecter au compte Google souhaité.
  • Cocher impérativement la case : « Afficher, modifier, créer et supprimer tous vos fichiers Google Drive ».
  • Valider l’autorisation. Le message « Success! » confirme que la liaison est établie.

4. Montage du Drive dans le gestionnaire de fichiers

On crée maintenant un point d’accès physique sur le système pour que Google Drive apparaisse dans l’explorateur (Dolphin).

Création du dossier local

mkdir -p ~/MonDrive

Activation du lien

Pour lier le Cloud au dossier créé, on utilise la fonction « mount » :

rclone mount gdrive: ~/MonDrive --vfs-cache-mode full &

Désormais, en ouvrant le dossier MonDrive dans le répertoire personnel, l’intégralité des fichiers Google Drive est accessible.

5. Automatisation de l’accès au démarrage

Étape 5.1 : Créer le fichier de service

Pour une stabilité maximale, on utilise un service système. On crée un fichier de service dans /etc/systemd/system/ qui ordonne au système de monter le Drive dès que le réseau est disponible. Cela garantit que le dossier MonDrive est toujours prêt après chaque redémarrage, sans intervention manuelle.

sudo nano /etc/systemd/system/rclone-gdrive.service

Étape 5.2 : Copier-coller la configuration

Dans l’éditeur qui vient de s’ouvrir, on colle le bloc suivant (il faut remplacer VOTRE_NOM_UTILISATEUR par votre vrai nom de session Linux) :

[Unit]
Description=Montage automatique Google Drive via rclone
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=VOTRE_NOM_UTILISATEUR
ExecStartPre=/usr/bin/mkdir -p /home/VOTRE_NOM_UTILISATEUR/MonDrive
ExecStartPre=-/usr/bin/fusermount -uz /home/VOTRE_NOM_UTILISATEUR/MonDrive
ExecStart=/usr/bin/rclone mount gdrive: /home/VOTRE_NOM_UTILISATEUR/MonDrive --vfs-cache-mode full
ExecStop=/usr/bin/fusermount -u /home/VOTRE_NOM_UTILISATEUR/MonDrive
Restart=on-failure
RestartSec=10

[Install]
WantedBy=default.target

Appuyez sur Ctrl+O puis Entrée pour enregistrer, et Ctrl+X pour quitter.

Étape 5.3 : Activer le service

On dit au système de prendre en compte ce nouveau fichier et de le lancer tout de suite.

  1. On recharge les services :
    sudo systemctl daemon-reload
  2. On active le lancement au démarrage :
    sudo systemctl enable rclone-gdrive.service
  3. On le lance immédiatement pour tester :
    sudo systemctl start rclone-gdrive.service

6. Dépannage

6.1 Le dossier est visible mais illisible (erreur 401)

Symptôme : le dossier MonDrive existe toujours, le service apparaît comme actif, mais toute tentative d’ouverture renvoie une erreur d’entrée/sortie. Le journal du service affiche des lignes de ce type :

ERROR : IO error: couldn't list directory: googleapi: Error 401:
Request had invalid authentication credentials.
Reason: authError, Message: Invalid Credentials

Cause : le jeton OAuth de rclone a été révoqué côté Google. La situation la plus fréquente n’est pas une panne, mais un ménage dans les autorisations du compte. rclone figure dans la liste des applications tierces ayant accès au compte Google (page « Sécurité », section des applications et services tiers), au même titre que n’importe quel autre outil connecté. Une suppression en bloc de ces autorisations coupe donc l’accès au Drive monté sur la machine, sans que rien ne le signale autrement qu’une erreur de lecture.

Correctif :

sudo systemctl stop rclone-gdrive.service
rclone config reconnect gdrive:
sudo systemctl start rclone-gdrive.service

Point important : la commande de reconnexion se lance sans sudo. Le service tourne sous le compte utilisateur défini par la directive User, et le jeton est stocké dans le fichier de configuration de cet utilisateur, dans son dossier personnel. Une exécution en root réécrirait le jeton dans le profil de root, où le service n’ira jamais le chercher. Le navigateur s’ouvre, il suffit de sélectionner le compte et de valider les mêmes autorisations qu’à l’installation.

Cette manipulation ne supprime rien : la configuration existante est conservée, seul le jeton est renouvelé.

6.2 Le service refuse de démarrer après un arrêt brutal

Symptôme : après un plantage, une coupure de courant ou un arrêt forcé, le service repart en boucle et finit par abandonner. La lecture du dossier renvoie le message suivant :

Transport endpoint is not connected

Cause : le processus rclone a été tué sans démontage propre. Le point de montage reste occupé par un montage FUSE devenu orphelin, et rclone ne peut pas monter par-dessus.

Correctif manuel :

sudo systemctl stop rclone-gdrive.service
fusermount -uz ~/MonDrive
sudo systemctl reset-failed rclone-gdrive.service
sudo systemctl start rclone-gdrive.service

La commande reset-failed a son importance : si le service a rebouclé un grand nombre de fois, systemd le place en limite de démarrage et refuse toute relance tant que ce compteur n’est pas remis à zéro.

Pour éviter d’avoir à intervenir la prochaine fois, la ligne de démontage préventif ajoutée au fichier de service à l’étape 5.2 nettoie le point de montage automatiquement avant chaque lancement. Le tiret placé devant le chemin de la commande indique à systemd d’ignorer un échec, ce qui est le cas normal lorsqu’il n’y a rien à démonter.


Informations Système : Nobara 43

  • Distribution : Nobara Linux (basée sur Fedora, RHEL et CentOS).
  • Version : 43.
  • Environnement de bureau : KDE Plasma Desktop Edition.
  • Base Technique : Utilise la plateforme Fedora 43 (f43).
  • Fin de support : Le support de cette version est prévu jusqu’au 2 décembre 2026.

mise à jour vers Version : 44 Base technique : Fedora 44 (f44) Fin de support : 2 juin 2027

Ces Article pourrais vous intéresser.

Laisser un commentaire