Saturday, November 11, 2023

Connect to Google Drive using "rclone" on Debian

  1. Install "rclone"

    1. # apt install rclone

  2. Use "rclone" to configure a "remote" for each connection. For example, if you have a work Google account and a personal Google account, you'd need a "remote" for each connection you want to use. Don't worry about making mistakes during this configuration; you can always delete the configuration and start over if need be. As the user with the Google Drive account:

    1. $ rclone --config
    2. Assuming you don't already have a "remote" (you don't, or you wouldn't be following this set of instructions), choose n for "New remote".
    3. The name for the new remote might be something like "GDrive" or "gdrive-work" or "my-personal-google-drive", etc.
    4. "rclone" can connect to all sorts of services; it now gives you a list of services to select from. This list changes from time to time, so don't rely on remembering the number for next time you need to do this. At the time of this writing, the Google Drive item is number 18, so that's the one I'll select.
    5. Setting the "Google Application Client Id" has some advantages, but it's a pretty complicated process for someone who has never done it before. For now, I'd keep it simple, and bypass this option by leaving this "client_id" option empty.
    6. Ditto the "client_secret".
    7. For "scope", you probably want the first option, "Full access [to] all files", because when you access Google Drive from your Debian workstation, you'll probably want full access to those files.
    8. The "service_account_file" should be left empty (unless you know what you're doing; you don't).
    9. Do not "Edit advanced config".
    10. Yes, do "Use auto config". This will open a web-browser window where you should log into your Google account, and then "Allow" rclone to access your Google account.
    11. Assuming this is not a Shared drive (if it is, you'd know it), select "No".
    12. Yes, keep this remote. This is essentially the "Save" step for the configuration of this remote.

  3. You've now configured your first Google Drive "remote". If you have a second Google account, you can configure it now by repeating the above process, starting at step 2, or you can "Quit config", and come back later to configure other remotes as the need arises. This configuration is saved in a plain-text file as "~/.config/rclone/rclone.conf". Instead of using the "rclone --config" "wizard" as we did above, you could've created this config file by hand, but who wants to do that error-prone process?

  4. "$ rclone listremotes" will list the names of the remote[s] you have configured.

  5. "$ rclone ls gdrive-work:" will list the files on the remote named "gdrive-work". Because this "ls" command traverses the file "tree", you may get a bigger listing than you want, so you may want to ls a smaller directory, like "rclone ls gdrive-work:/todo/Week17". Or if you wanted a tree view, "rclone tree gdrive-work:"

  6. But most likely, you want the drive mounted. There are several ways to accomplish this.

    1. Using "rclone mount"

      $ mkdir ~/GDrive4Work
      $ rclone mount gdrive-work:/ ~/GDrive4Work

      Note that you won't see anything happen, but you can open another terminal window (or file manager, etc) and browse to your mounted directory to access the files.

      Ctrl-C will unmount the drive.

      Alternatively you can background the process with an ampersand:

      $ rclone mount gdrive-work:/ ~/GDrive4Work &

      and when you want to unmount, fg to foreground the process, followed by Ctrl-C.

      Alternatively, you can mount it in daemon mode:

      $ rclone mount gdrive-work:/ ~/GDrive4Work --daemon

      and then unmount with:

      $ fusermount -u ~/GDrive4Work

      (you can also use umount instead of fusermount -u, but the documentation says this is unreliable)

      We probably want this mounting to take place at login of the Drive's owner.

      Make a little script and put it where you can access it. I have a ~/bin directory for this purpose. Name the script something like "mount-GDrive.sh", and put the following into it:

      #!/bin/bash

      # Test if GDrive is mounted, and if not, mount it
      mountpoint -q /home/[your user]/GDrive4Work || rclone mount gdrive-work:/ /home/[your user]/GDrive4Work --daemon

      Save the file, and make sure it's executable:

      $ chmod +x ~/bin/mount-GDrive.sh

      Then place a call to this script at the bottom of your ~/.bash_profile file:

      ~/bin/mount-GDrive.sh

      If you don't already have a ~/.bash_profile you can create it, but make sure to source the ~/.bashrc file by adding to the top of ~/.bash_profile this line:

      . ~/.bashrc

      (There's a space after the first dot.)

      Now, reboot your system and make sure it all works.

    2.  Using an /etc/fstab entry

      This method is probably not the best, because it will mount the drive at boot-time, regardless of the Drive's "owner" being logged in or not. Also, the mount will not be owned by the "owner", unless special care is taken in the /etc/fstab file. The following is here just for documentation purposes; you're probably better off using the first method above.

      You can add a line to /etc/fstab like the following:

      gdrive-work:/ /home/[your user]/GDrive4Work rclone rw,noauto,nofail,_netdev,x-systemd.automount,args2env,vfs_cache_mode=writes,config=/home/[your user]/rclone/rclone.conf,cache_dir=/var/cache/rclone 0 0

      If you try to mount the drive now with:

      # mount /home/[your user]GDrive4Work

      you'll get a message that rclone is not a known type, and that fstab has been modified, but that you need to reload the systemd daemons. Nowadays /etc/fstab is really just a backwards-compatible configuration source for systemd. When you reboot, systemd will read this file and convert your added line to a systemd unit. Currently this line has not yet been added to systemd. You can verify this with the command:

      # systemctl list-units | grep -i "gdrive"

      Notice this command is run as "root" (you can also use "sudo" instead). This command should find no units containing the name "gdrive".

      "systemctl" is kind of like the control command for systemd, and we're telling it to list the units that systemd knows about, piping ("|") the results through "grep" to display only those lines that contain the phrase "gdrive", regardless of capitalization ("-i"). If you leave off the | grep -i "gdrive", you'll get a list of all the units that systemd knows about.

      These units are typically stored in /usr/lib/systemd/system (for system-installed units that usually should not be tinkered with) and /etc/systemd/system (for locally-configured units). You can also ls in those directories to verify there are no "gdrive"-related units there.

      But we don't have to wait for a reboot to let systemd know about the changes to fstab. We can just reload the daemons with:

      # systemctl --daemon-reload

      But that still doesn't work, because the old mount command doesn't recognize the "rclone" type (the systemd units still weren't created. But this is easy to fix: we just need to create a symlink, like so:

      # ln -s /usr/bin/rclone /sbin/mount.rclone

      Reload the systemd daemons again:

      # systemctl --daemon-reload

      and now you can mount (as your normal user, not 'root') your "remote":

      $ mount /home/[your user//GDrive4Work

      You should now be able to access your Google Drive from the command-line or from any of your usual file managers, etc. Be aware though, that a reboot will mount the drive as "root", and your normal user probably will no longer have access to the Drive.

      While the drive is mounted, you can also see that systemd knows about this "unit":

      # systemctl list-units | grep -i "gdrive"

      ... even though there still isn't a unit file in the two unit-file directories mentioned above.

      $ ls -R /etc/systemd/system | grep -i gdrive
      $ ls -R /usr/lib/systemd/system | grep -i gdrive


      I was thinking this method created a unit-file automagically in /lib, which you could them move to /etc and tailor to your needs, but apparently I'm wrong about that. I was then going to write in the next section about using a systemd unit to mount the Drive, but after I wrote most of this I realized it also would mount the Drive at boot-up, regardless of the owner being logged in, unless more hoops were jumped through to get all the t's crossed and all the i's dotted.

    3. Other methods such as a cron job to mount the drive on login, etc, but the above methods are probably your best bet.