Codebusters

rclone bisync from Cron: Keep a Google Drive Folder in Sync on Linux

Thursday 5 November 2026

I keep a folder of notes and trackers in Google Drive, and I wanted the same files on my Linux server without opening a browser. rclone can do it in both directions with rclone bisync, and it has now run from cron every 5 minutes since late September. This is the cron line I ended up with, what each flag is for, and what happens when things go wrong.

The cron line

Set up the Drive remote first with rclone config (I called mine gdrive), then do the one-off first run by hand:

rclone bisync gdrive:trackers /home/you/trackers --resync

That --resync builds the starting picture of both sides. Leave it out and bisync refuses to start, which I checked:

ERROR : Bisync aborted. Must run --resync to recover.

After that, this goes in crontab -e:

*/5 * * * * flock -n /tmp/rclone-bisync.lock timeout -k 10 240 /usr/bin/rclone bisync gdrive:trackers /home/you/trackers --resilient --recover --max-lock 2m --conflict-resolve newer --log-file /home/you/sync.log --log-level INFO

Use the full path to rclone, because cron doesn’t have your normal PATH. If that catches you out, see cron job works by hand but not from cron.

What each part is for

  • flock -n skips the run if the previous one is still going. I tested it by holding the lock for 5 seconds and starting a second copy, which exited at once with status 1 and did nothing. There’s more on this in stop a PHP cron job running twice.
  • timeout -k 10 240 stops a hung run before the next one is due. 240 seconds is under the 5 minute gap, and -k 10 sends a hard kill if rclone ignores the polite stop.
  • --resilient and --recover are there so that a run which was interrupted (by that timeout, say, or a dropped connection) can carry on next time instead of demanding another --resync. I haven’t deliberately killed a run to test this, so treat that as the documented intent rather than something I’ve proved.
  • --max-lock 2m makes rclone’s own lock file count as stale after 2 minutes, so one killed run can’t block every run after it.
  • --conflict-resolve newer decides what happens when the same file changed on both sides.

What I tested

I couldn’t safely experiment on my real files, so I tried each behaviour between two local folders, a and b, with rclone 1.75.1. Bisync doesn’t care that neither side is Drive.

New and changed files travel both ways. I edited a file in a and created a new one in b. Next run, the new file was copied across and the edit replaced the old copy. Ending with Bisync successful.

Deletes travel too. I deleted a file from a and it was deleted from b on the next run. That’s what you want from a sync, but it means a delete on either side is a delete everywhere (Drive’s own bin is your safety net, so check yours before trusting this with anything precious).

The same file edited on both sides. I appended a line in a, waited, then appended a different line in b and ran it:

todo.md: Path2 is newer. Path1: ...06:33:26, Path2: ...06:33:28
Renaming Path1 copy - a/todo.md.conflict1
Queue copy to Path2 - b/todo.md.conflict1
Bisync successful

The newer copy kept the real name and the older one was renamed todo.md.conflict1 on both sides. Nothing was lost, and I could open both to see what I’d have thrown away. This does happen in real life. My log has one from 30 September, a Word document edited on the server and on my PC within the same 5 minutes.

An emptied folder won’t wipe the other side. I deleted every file in a and ran it. Instead of deleting everything in b, it stopped:

ERROR : Empty current Path1 listing. Cannot sync to an empty directory
ERROR : Bisync aborted. Must run --resync to recover.

b still had all its files. That one is a real safety net if a mount drops and your local folder suddenly looks empty. (Check the same thing on your own setup before relying on it, since I only tested the totally empty case, not a folder that has lost half its files.)

How it has gone in real life

My log goes back to 24 September. It shows 12,096 lines reading Bisync successful and 72 lines containing ERROR. A run can print more than one error line, so that isn’t 72 failed runs, and I haven’t gone through them one by one. What I can say is that I haven’t had to step in once, and the one conflict I know about left both versions behind.

Gotchas

  • Run the cron line by hand once, with -v instead of the log file, before you trust it. A mistake in the paths gives you errors in a log nobody reads.
  • The conflict files will sync to the other side too. If you see .conflict1 files turning up, that’s the sign that both sides changed within one gap, so go and look.
  • Mine is only text files and ordinary documents. I haven’t tried syncing Google’s own Docs and Sheets formats, so I can’t say how they behave.