or potentialy useful information

Work In Process

Template System

or 2TB of readonly cloud storage with minimal fuss

Platform

• Raspberry PI Version 3B
  • 4GB Ram
  • Stock clock
  • Raspberry Pi OS Lite, 64 bit

The idea

It would be quite splendiferous to have a large, easy to use data store for my Raspberry Pi home server. I already pay for Google One, and I basically don't use it for anything, so that seems like an appealing target. Let's just setup an easy mount or something and enjoy.

That was simple, easy, and wrong.

The catch

Raspberry Pi OS does not have a build of google-drive-ocamlfuse available; and wouldn't you know it, the documentation isn't quite up to snuff either.

The Fix

If brute force doesn't work, you're not using it correctly. So, if they won't give us a package, we're going to build our own, and by golly, we'll make it work.

So, let us start by following the instructions provided by astrada's installation notes. It mostly works.

Installing google-drive-ocamlfuse

In order to build google-drive-ocamlfuse on Raspberry Pi OS we need to install some tooling, namely the opam utility and the mccs solver. We'll also be removing the legacy package aspcud; I don't think you'll miss it.

sudo apt install opam mccs
sudo apt remove aspcud

Now, let us inform opam that we sould like to use the mccs solver, and switch to the recomended build environment.

opam init --solver=mccs
opam switch create 4.09.0
eval $(opam env)

Once that's taken care of, we can first install the dependencies and finally google-drive-ocamlfuse

opam depext google-drive-ocamlfuse
opam install google-drive-ocamlfuse

At this point you have a working local installation of google-drive-ocamlfuse. Now to get the middleware configured.

Obtaining an OAuth2 ID and Secret

In order to proceed any further, we need to obtain some secrets from google; so let us refer to Managing OAuth Clients, and return here once we have an API Client ID and Client Secret.

Connecting to Google Drive

We need to perform the initial authorization flow before we can start using our google drive client. I'll be assuming that we are accessing the Pi over ssh and must use the headless flow.

google-drive-ocamlfuse -headless \
    -id ${API_CLIENT_ID} \
    -secret ${API_CLIENT_SECRET}

Roughly follow the instructions given by the tool. Once you've accessed the given link, you will be provided with a confirmation screen along with a verification code (which is also the end of the URL).

Provide the verification to google-drive-ocamlfuse and that's the hard part done.

Creating your Mountpoint

Because I intend on sharing this connection between users, I need to create a system mount point. If you only require single-user usage; feel free to create this folder anywhere; it only needs to be owned by the google drive user.

sudo mkdir -p /mnt/Google
sudo chown $USER /mnt/Google

Configuring the connection

As an insurance against bad actors doing bad things, we're going to apply the principle of least privilege and configure our connection to be read-only, and to convert documents into LibreOffice documents.

nano ~/.gdfuse/default/config

Set the following settings – read_only, large_file_readonly to true – document_format, drawing_format, presentation_format, spreadsheet_format to libreoffice

read_only=true
large_files_read_only=true
document_format=libreoffice
drawing_format=libreoffice
presentation_format=libreoffice
spreadsheet_format=libreoffice

~/.gdfuse/default/config

Modifying /etc/fuse.conf

You can safely skip this if the user accessing the google drive connection is the same as the owner of the connection. IF you want other users to be able to access your mount, you first need to enable other user access in FUSE by editing fuse.conf.

sudo nano /etc/fuse.conf

Uncomment the line user_allow_other to enable the allow_other mount option.

user_allow_other

/etc/fuse.conf

Creating the wrapper script

Because we installed google-drive-ocamlfuse from opam; we need to write a wrapper as systemd will not load profile information when starting a unit, so we need to do that ourselves to ensure the proper opam environment.

mkdir -p ~/.bin
nano ~/.bin/mount-google-drive

The script below simply sources the current users profile and then calls the mount utility.

#!/bin/bash
source /home/${USER}/.profile
google-drive-ocamlfuse -o allow_other /mnt/Google/

~/.bin/mount-google-drive

Don't forget to make your script executable.

chmod +x ~/.bin/mount-google-drive

Writing the User Service

We're very nearly done; the next step is to tell systemd how to launch our helper. Let's start by making sure we have a systemd user unit folder, and editing google-drive.service.

mkdir -p ~/.config/systemd/user
nano ~/.config/systemd/user/google-drive.service

The contents below describe a forking service (google-drive-ocamlfuse runs as a background process) that will start after networking is up but before a user logs in.

[Unit]
Description=FUSE filesystem using Google Drive
After=network.target

[Service]
ExecStart=%h/.bin/mount-google-drive
ExecStop=fusermount -u /mnt/Google
Restart=always
Type=forking

[Install]
WantedBy=default.target

~/.config/systemd/user/google-drive.service

Once your service unit has been saved; we need to instruct systemd to recognize the new unit and to enable it for automatic start.

systemctl --user daemon-reload
systemctl --user enable google-drive
systemctl --user start google-drive

Enabling Lingering

Lingering, while perhaps not strictly required is advised for enabling unatended user processes.

sudo loginctl enagle-linger $USER

Fin

Congratulations; you're all done. You should now have a persistent read-only google drive connection that will stream your files to you just like a local device, easy. If you're impatient; or if the contents do not refresh quickly enough; restart the service and it will flush the caches and present a new view of the drive tree.

But wait; there's more

If you, like me have an unreasonable number of probably personal files available on your google drive, you can configure google-drive-ocamlfuse to use a subdirectory within google drive as a virtual root. This is configured using the root_folder configuration option.

The documentation was a little sparse, but here it expects you to provide a folder ID (which you can obtain from the folder view URI). Setting this option will configure the connection to only show files in that directory and below. Don't bother using the path option as the ID does not change when a folder is moved or renamed.

Tags: #raspberrypi #systemd #loginctl #googledrive