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.
- On recharge les services :
sudo systemctl daemon-reload - On active le lancement au démarrage :
sudo systemctl enable rclone-gdrive.service - 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.
-
Clés SSH : ajouter un deuxième accès à son VPS
Clés SSH : ajouter un deuxième accès à son serveur sans se verrouiller dehors Avertissement. Les manipulations décrites ici touchent à l’accès distant d’un serveur. Une erreur peut…
-
Automatisation DIY Docker Fedora / Nobara Linux Logiciel LXC Proxmox Raspberry Pi Serveur IA Privé Ubuntu VPS
tmux sur Linux
Optimisation de la productivité sur Linux avec tmux La gestion de plusieurs terminaux au sein d’une seule fenêtre est une problématique récurrente pour les administrateurs système et les…
-
Comment relancer une barre des tâches KDE Plasma sous Nobara
Introduction Le blocage d’un environnement graphique sous Linux arrive parfois, même sur les distributions les plus stables. Lorsque l’interface se fige, la perte de la barre des tâches…