rclone bisync with a GUI: two-way Google Drive sync on Linux (2026)

Disclosure: we make Ambifold, a two-way sync app for Linux that runs rclone bisync inside. It is in a private beta, by invitation, in October and November 2026, and the public beta is planned for 1 December 2026. Sections 1 to 4 work without it. If something here is wrong or out of date, please tell us at support@ambifold.com.

How we checked: we ran the script, the filter file and the failure cases below with rclone v1.75.1 on Linux Mint 22.3, between two local folders, and checked the systemd files with systemd-analyze verify. The parts specific to Google Drive follow rclone's documentation and what we learned running bisync against Drive inside Ambifold. Not sure whether you want sync at all? Our guide to mounting versus syncing Google Drive explains the difference.

1. What bisync does

bisync works with two paths. In this guide, Path1 is a folder on your computer and Path2 is a folder in your Google Drive. After every successful run, bisync saves a listing of each side in its working folder (by default ~/.cache/rclone/bisync).

On the next run, it lists both sides again and compares each one with its saved listing. A file that is new or changed on one side is copied to the other. A file that was deleted on one side is deleted on the other. A file that changed on both sides is a conflict, and bisync keeps both versions.

The first run is different. There are no saved listings yet, so you run bisync once with --resync. A resync copies every file that is missing on one side to the other, so both sides end up with all the files. It deletes nothing. When a file exists on both sides but differs, one version replaces the other. By default the Path1 version (your computer's) wins, even if it is older. Add --resync-mode newer to keep the newer one instead.

Never put --resync in your schedule. rclone's documentation is clear on this: because a resync only copies, a file you delete would come back from the other side on every run, and a renamed file would end up under both names. Use it only:

• for the first run between two folders;
• after you change your filter file;
• when bisync stops with an error that says it needs one.

bisync exits with code 0 when a run succeeds, 1 when a run failed but a later one may work, 2 for a mistake in the command, and 7 for a serious error. rclone's documentation says a 7 needs a --resync, but with --resilient (used in the script below) some code-7 errors clear by themselves on a later run. Step 8 explains how to tell.

2. Doing it by hand

The examples sync ~/DriveSync on your computer with a folder called DriveSync in your Drive, through an rclone remote called gdrive. Change the names to suit you.

Step 1: install a current rclone

Ubuntu 24.04 and 26.04 offer rclone 1.60.1 in their repositories (checked 16 October 2026). Linux Mint 22 uses the same package, and so will the coming Linux Mint 27 “Adrien”, which is built on Ubuntu 26.04. That version predates bisync's fixes in 1.64 and 1.66, among them one where --resync could wrongly delete empty folders and duplicate files that existed only in Drive, and it lacks most of the flags below (--resync-mode, --recover, --max-lock, --conflict-resolve, --backup-dir1). Check yours with rclone version. If it is older than 1.66, remove it and install rclone's current release, with its install script or with the .deb file from rclone.org/downloads:

sudo apt remove rclone
sudo -v ; curl https://rclone.org/install.sh | sudo bash
rclone version

We checked this guide against rclone v1.75.1 (4 September 2026). v1.75.2 (9 October 2026) fixes security issues and bugs elsewhere in rclone; its changelog lists no changes to bisync.

Step 2: connect Google Drive with your own client

rclone's Google Drive page says its shared client ID “will stop working during 2026”, and that creating your own is “now required”. Our guide to creating your own Google Drive client ID walks you through it, with pictures (rclone's own page: making your own client ID). Then run rclone config:

1. Choose n (new remote) and name it gdrive.
2. For the storage type, enter drive.
3. Paste your client ID and client secret.
4. For the scope, choose 1 (full access). Leave the other questions at their defaults.
5. Sign in with Google in the browser window that opens.

If you already have a remote that uses the shared client, edit it in rclone config, enter your client ID and secret, then run rclone config reconnect gdrive:.

Step 3: make the two folders and the check files

mkdir -p ~/DriveSync
rclone mkdir gdrive:DriveSync
touch ~/DriveSync/RCLONE_TEST
rclone copyto ~/DriveSync/RCLONE_TEST gdrive:DriveSync/RCLONE_TEST

Both folders must exist before the first run. The two RCLONE_TEST files are for --check-access: with it, bisync stops unless it finds the file in the same place on both sides. That catches a disk that isn't mounted or a wrong path before anything is deleted. Leave the files where they are. bisync checks for them during --resync too, so create them first.

Step 4: a filter file

Save this as ~/.config/drive-bisync/filters.txt. Each line that starts with - leaves matching files out of the sync, and a pattern that ends with / leaves out a whole folder.

# Files bisync leaves alone. After any change to this file,
# run once with --resync (try it with --dry-run first).
- .~lock.*#
- *~
- *.swp
- *.tmp
- .Trash-*/
- .directory
- node_modules/

These are LibreOffice lock files, editor backup and swap files, temporary files, trash folders on other disks, the folder settings KDE writes, and a folder of downloaded code packages. Add your own, such as a folder of large videos.

bisync keeps a checksum of this file (in filters.txt.md5 next to it). If the file changes, the next run stops and asks for a --resync. Otherwise files that are newly left out would look deleted. Keep your filters in this file rather than as --exclude options on the command line, because bisync checks only the file for changes.

Step 5: the script

Save this as ~/.local/bin/drive-bisync, then make it executable with chmod +x ~/.local/bin/drive-bisync:

#!/bin/bash
# One two-way sync pass between ~/DriveSync and gdrive:DriveSync.
# Options you add are passed to rclone, for example --dry-run or --resync.
set -eu

LOCAL="$HOME/DriveSync"
REMOTE="gdrive:DriveSync"
STATE="$HOME/.local/state/drive-bisync"
FILTERS="$HOME/.config/drive-bisync/filters.txt"

# Keep the backups of replaced and deleted local files for 30 days.
cutoff=$(date -d '30 days ago' +%F)
for day in "$STATE"/backup/????-??-??; do
  if [[ -d $day && ${day##*/} < $cutoff ]]; then rm -rf -- "$day"; fi
done

exec rclone bisync "$LOCAL" "$REMOTE" \
  --workdir "$STATE/work" \
  --filters-file "$FILTERS" \
  --check-access \
  --max-delete 50 \
  --resilient --recover --max-lock 2m \
  --conflict-resolve newer --conflict-loser num --suffix-keep-extension \
  --create-empty-src-dirs \
  --backup-dir1 "$STATE/backup/$(date +%F)" \
  --drive-skip-gdocs \
  --disable ListR \
  -v "$@"

If command -v rclone shows rclone somewhere other than /usr/bin, write that full path in place of rclone: the timer in step 7 may not find it otherwise. What each option does:

bisync compares files by size and modification time unless you set --compare. Adding checksum catches a change that keeps the same size and time, but then rclone reads every file on your computer on every run, which is slow for a large folder. --slow-hash-sync-only is a middle way that rclone's documentation explains.

Step 6: the first run

First, see what the resync would do, without changing anything:

~/.local/bin/drive-bisync --resync --resync-mode newer --dry-run

Read the output. The line “Path2 … Resync is copying files to … Path1” is followed by the files that would come down from Drive, and “Path1 … Resync is copying files to … Path2” by those that would go up. Each file is marked “Skipped copy as --dry-run is set”. If it looks right, run it for real, then run a normal pass:

~/.local/bin/drive-bisync --resync --resync-mode newer
~/.local/bin/drive-bisync

A good run ends with “Bisync successful”, followed by a summary of what was transferred.

Step 7: run it on a schedule with a systemd timer

rclone's documentation says bisync can't watch for changes and “must be blindly run periodically”. A systemd user timer does that. Create three files in ~/.config/systemd/user/.

drive-bisync.service:

[Unit]
Description=Two-way sync of ~/DriveSync with Google Drive (rclone bisync)
OnFailure=drive-bisync-alert.service

[Service]
Type=oneshot
ExecStart=%h/.local/bin/drive-bisync
# On logout or shutdown, give bisync time to stop cleanly.
KillSignal=SIGINT
TimeoutStopSec=120

drive-bisync.timer:

[Unit]
Description=Run drive-bisync every 5 minutes

[Timer]
OnBootSec=2min
OnUnitActiveSec=5min

[Install]
WantedBy=timers.target

drive-bisync-alert.service, which shows a notification when a run fails:

[Unit]
Description=Show a notification when drive-bisync fails

[Service]
Type=oneshot
ExecStart=/usr/bin/notify-send --urgency=critical "Drive sync failed" "Run: journalctl --user -u drive-bisync -n 50"

Then switch the timer on, and test the notification:

systemctl --user daemon-reload
systemctl --user enable --now drive-bisync.timer
systemctl --user start drive-bisync-alert.service
systemctl --user list-timers

A few things to know:

• Logs: journalctl --user -u drive-bisync shows every run; add -f to follow along.
• Stopping cleanly: on SIGINT, bisync finishes or cancels its copies and saves its state, which takes up to 90 seconds. That is why the service sends SIGINT and waits 120 seconds.
• Pausing: systemctl --user stop drive-bisync.timer, and start to resume.
• Logged out: user timers run only while you are logged in. To run them all the time, run loginctl enable-linger once.
• Large folders: every run lists both folders in full. If runs take minutes, set a longer interval.

Step 8: when bisync stops

• “Safety abort: too many deletes”. Nothing was changed. The log lists the deleted files. To see what a forced run would do, run ~/.local/bin/drive-bisync --dry-run --force. If that is what you meant, run it once with --force. If not, put the files back (from your desktop's Trash, or from the trash on drive.google.com), and the next run carries on normally.
• Conflicts. Find them with find ~/DriveSync -name '*.conflict[0-9]*'. Compare the two versions, keep what you need and delete the other; the delete syncs too.
• Exit code 7. Read the log first. After a passing problem, such as a missing RCLONE_TEST file because a disk wasn't mounted, it says “Error is retryable without --resync due to --resilient mode”: fix the cause, and the next run carries on. If it says “must run --resync”, or that it “cannot find prior Path1 or Path2 listings”, later runs keep failing, even when the next line calls the error retryable. Then run the dry-run resync from step 6, read it, and run it for real.
• A lock file. With --max-lock 2m, an old lock expires by itself. Delete a .lck file in ~/.local/state/drive-bisync/work by hand only when pgrep -a rclone shows no bisync still running.

3. What goes wrong

A resync at the wrong moment

A resync assumes nothing was deleted. Files you deleted on one side since the last successful run come back from the other side, and where both sides have a version, one replaces the other. With the script above, a replaced file on your computer goes to the backup folder, and a replaced file in Drive stays in its version history. Still, always run --dry-run first, and delete again what came back.

Lost listings

bisync can't run without the listings from its last run. It stops with “cannot find prior Path1 or Path2 listings” (exit code 7), and you need a resync, with the risks above. Listings get lost when:

• a cleaning tool empties ~/.cache (the reason for --workdir in the script);
• you rename or move ~/DriveSync or the Drive folder, or change the paths in the script: the listings are named after the two paths, so bisync looks for new ones;
• a serious error makes bisync rename them to .lst-err, on purpose, to block the next run.

Renamed or moved folders

bisync doesn't track folders. If you rename a folder inside ~/DriveSync, the next run sees every file in it as deleted and every file under the new name as new. It deletes the old files in Drive (they go to Drive's trash) and uploads them again under the new name. The new copies in Drive don't have the old ones' sharing settings, comments or version history: those stay with the files in the trash. The same happens the other way when a folder is moved on drive.google.com.

If the folder holds more than half of your files, --max-delete stops the run first. In our test, it stopped even when we had renamed the folder the same way on both sides. The safest way to rename a big folder:

1. Stop the timer.
2. Rename the folder in the same way on your computer and on drive.google.com.
3. Run ~/.local/bin/drive-bisync --dry-run --force. It should show the files as “New or changed in both paths” and delete nothing.
4. Run it once with --force, then start the timer again.

rclone's documentation also suggests --track-renames, which bisync supports since v1.66. Renamed files still count toward --max-delete.

Google Docs, Sheets and Slides

Google's own documents are not ordinary files. Without --drive-skip-gdocs, bisync downloads them as converted copies (.docx, .xlsx, .pptx and .svg by default). That causes surprises:

• If you rename or move a converted copy on your computer, bisync deletes the Google document in Drive (to the trash) and uploads a plain file in its place.
• If you edit a converted copy, rclone v1.75.1 can't write it back into the Google document unless you set --drive-import-formats: the copy fails with “can't update google document type without --drive-import-formats”, and the run ends with an error. With that option, the conversion can lose formatting.
• With --drive-export-formats url, you get link files instead. They are read-only placeholders, and deleting one deletes the Google document.

We recommend --drive-skip-gdocs from the first run: your documents stay in Drive, and you open them in the browser. Switching it later makes bisync add or remove the converted copies on your computer.

--fast-list with Google Drive

--fast-list lists Drive with fewer, bigger requests, which is much faster. On rclone's Drive page, listing a folder of 10,600 folders and 39,000 files took 22 minutes without it and 58 seconds with it. But with Drive, those grouped requests can come back incomplete: there are known Google bugs (rclone issues #3114 and #4289), and the Drive page notes that, on shared drives, recently uploaded files may be missing. To bisync, a file missing from Drive's listing looks deleted in Drive, so it deletes your local copy.

rclone's bisync page says bisync uses --fast-list by default and recommends --disable ListR to avoid it. When we read rclone v1.75.1's code, bisync listed Drive folder by folder unless --fast-list was given. Either way, don't add --fast-list to scheduled runs; --disable ListR in the script makes sure. The cost is speed: sync the folders you need, not your whole Drive.

Other traps

• Two tools on one folder. Never let bisync and another sync app (or a second bisync) sync the same folder, and don't put the folder inside an rclone mount or the file manager's Drive folder. Our two-way sync safety checklist covers this and more.
• An encrypted home folder. If findmnt -n -o FSTYPE -T ~/DriveSync says ecryptfs, add --modify-window 1s to the script. eCryptfs stores modification times in whole seconds, and without it, files that were just downloaded can look changed on every run.
• Leftovers after a crash. rclone writes a download under a temporary name such as report.pdf.1a2b3c4d.partial and renames it when it is complete. A crash or power cut can leave one behind, and the next run may sync it as a real file. Delete such leftovers.
• Sleep. The timer counts only the time the computer is awake, so after it wakes, the next run comes within a few minutes.

4. GUIs that exist

Checked on 16 October 2026, on each project's own pages. Whichever you choose, check how it handles the first --resync, --max-delete and Google Docs before you point it at files that matter.

5. What Ambifold adds on top of rclone

Ambifold has rclone v1.75.1 built in, and its bisync does the file transfers. You don't install rclone or write any scripts. On every pass it uses most of the safety flags from section 2: --resilient, --recover, --max-lock 2m, --conflict-resolve newer (adjustable), --max-delete 50 (adjustable), --create-empty-src-dirs, --backup-dir1 outside the folder, --modify-window 1s, and --drive-skip-gdocs unless you turn Docs on. Then it adds the parts that are hard to script:

Its limits, today:

• It is a beta: a private beta by invitation in October and November 2026, with the public beta planned for 1 December 2026. It is tested on Linux Mint and Ubuntu, with the Cinnamon and GNOME desktops.
• My Drive only. Shared drives and “Shared with me” are not supported yet; rclone bisync can sync a shared drive.
• Google Docs, Sheets and Slides are skipped by default. You can turn on converted copies. Renaming, moving or deleting one then moves the Google document to Drive's trash, as in section 3. If you edit one, Ambifold leaves it out, keeps syncing the rest of the folder, and asks whether to keep your changes as a new file or discard them.
• Changes made in Drive arrive in about 1 to 5 minutes: usually within a minute while you're working, within about five when things are quiet.
• The free edition connects through your own Google client, as rclone now does too. The app walks you through creating it.
• Because it lists Drive folder by folder, a check of a very large Drive folder takes minutes.
• Its own code is private. rclone, inside it, is open source.

If you are on a specific system, our guides to Google Drive on Linux Mint and to syncing Google Drive on Ubuntu compare the other options too, and our comparison of Google Drive clients for Linux covers the rest.

6. FAQ

Is rclone bisync safe with Google Drive?

It can be, with care. Use your own Google client, a current rclone, --resync only for the first run, --max-delete, --check-access, a backup folder and --drive-skip-gdocs, and avoid --fast-list. Start with one folder that also exists somewhere else, and check it after the first runs.

Does rclone bisync have a GUI?

Not in rclone itself: rclone gui has no bisync screen. Rclone UI, Rclone Manager and RcloneView can start bisync jobs, and Ambifold runs bisync for you in the background (section 4).

Do I need --resync every time?

No, and you shouldn't: deleted files would keep coming back. Use it for the first run, after a change to the filter file, or when bisync says it needs one.

How often should bisync run?

Every 5 minutes is a common choice: it is what the timer above uses, and what rclone's own cron example uses. Every run lists both folders in full, so if runs take longer than that, choose a longer interval or sync smaller folders.

Can bisync watch my folder for changes?

Not by itself: rclone's documentation says it must be run on a schedule. Some of the GUIs above add triggers, and Ambifold watches your folders.

Can bisync sync a shared drive?

rclone can: when you create the remote, answer yes when rclone config asks whether to configure it as a shared drive. Ambifold syncs My Drive only for now.

7. Sources

All checked on 16 October 2026, and Ambifold's release notes again on 19 October 2026.

• rclone documentation: bisync (flags, limitations, exit codes, Google Docs; its own changelog up to v1.74.2), Google Drive (shared client ID, --fast-list, --drive-skip-gdocs, --drive-use-trash; page updated 9 October 2026), filtering, installation, GUI (page updated 30 April 2026) and remote control (sync/bisync)
• rclone: changelog (v1.74.0, 1 May 2026: rclone gui; v1.75.1, 4 September 2026; v1.75.2, 9 October 2026) and issues #3114 and #4289
• GitHub: rclone-webui-react (archived, superseded by rclone gui) and rclone-web (the GUI's source, no bisync screen)
• Ubuntu packages: rclone in Ubuntu 24.04 and Ubuntu 26.04 (1.60.1)
• systemd: systemd.timer and systemd.service
• Rclone UI: home page and GitHub (Bisync screen in its source; v3.7.5, 18 September 2026)
• Rclone Manager: GitHub (v0.3.3 release notes, 23 September 2026)
• RcloneView: Create sync jobs and downloads (1.6.8)
• Rclone Browser: GitHub (release 1.8.0, 17 February 2020)
• Celeste: GitHub (archived; last change 21 November 2025)
• Ambifold: the home page (safety, status and limits), a synced folder was deleted or moved, recovering files and the release notes (0.3.0-beta.8, 16 October 2026; for Google Docs, 0.3.0-beta.12, 18 October 2026)

8. Changes to this guide

• 16 October 2026: first published.
• 19 October 2026: section 5: an edited converted copy of a Google document no longer stops Ambifold's syncs of its folder. Ambifold leaves the copy out, syncs the rest, and asks whether to keep your changes as a new file or discard them.