Cloud sync bypass on Linux: offline Google drive without rclone using FreeFileSync GUI

Migrating 'Air Live Drive' Workflows to Linux Environments#

Workstation transitions (from Windows Host to Linux Mint) immediately expose operational gaps in aggressive integration with Cloud Storage. In my old ecosystem, my dependency isolation relied heavily on the orchestration of Air Live Drive Pro, acting as a virtual File System bridge to mount and access the Google Drive storage base.

The explicit tactical requirement established for the new Linux-based structure: Consolidate a two-way synchronization, obligatorily retaining data for offline isolation, wrapped in a functional graphical user interface (GUI) without the heavy intervention of classical CLI-Wrappers (an explicit architectural rejection of terminal-only purist Rclone handlers).

1. The native GNOME 'online accounts' (GVFS) false positive#

Operating on Linux Mint (Cinnamon DE), the initial approach was to test the native permission hardlinks of the architecture using Online Accounts (the GNOME Accounts daemon).

Base mounting procedure:

1. Injected a core check on the Online Accounts flag.
2. Delegated authorization via OAuth, passing direct tokens to the local Google handler.
3. The Nemo File Manager passively maps a network allocation point, labeling the user's primary endpoint in a remote tab.

Forensic Evaluation - The Bottleneck: The system provisions the share exemplarily via gvfs (Gnome Virtual File System), simulating a functional plug-and-play VFS. However, this method transacts under a strict On-Demand request matrix. The listed inodes do not persist in local caches. Physical download occurs exclusively during isolated click events (Read-Only/Fetch-Once events), destroying any capacity for Offline-Resilience. Without an open TCP/IP socket, the ecosystem goes dark.

2. Backup protocols and system pre-requisites#

Before starting any mass two-way synchronization task, it is mandatory to safeguard the original local data and validate the storage resources available on the machine. An incorrect synchronization (e.g. a misconfigured "Two way" policy) can result in permanent loss of local files if the destination cloud directory is empty or outdated.

A. Preventive local directory backup#

Execute the following commands in the terminal to generate and validate a compressed backup of the directory that will be paired with the cloud:

# Create backup of the local directory before synchronizing
sudo tar czf /root/home-backup-$(date +%Y%m%d).tar.gz /home/user/MeusDocumentos/

# Verify if the backup was generated and its physical size
du -sh /root/home-backup-*.tar.gz

# Verify backup integrity (listing files contained in the package)
tar -tzf /root/home-backup-*.tar.gz | wc -l

B. Disk space audit#

Synchronizing files for offline retention requires equivalent physical space on the local disk. If disk space is insufficient during the download, FreeFileSync will abort the task, potentially leaving corrupted files behind.

# Verify available space on the partition hosting the local directory
df -h /home/user/MeusDocumentos/

# Calculate the actual total size occupied by current local data
du -sh /home/user/MeusDocumentos/

C. Permission and ownership audit#

The synchronization daemon needs explicit read and write privileges in the local directory and its own configuration folders to prevent write failures.

# Check permissions and owner of the local directory
ls -la /home/user/MeusDocumentos/

# Display ownership and inode details of the directory
stat /home/user/MeusDocumentos/

# Validate access permissions to the FreeFileSync configuration directory
ls -la ~/.config/freefilesync/

3. Detailed verification of tools and GVFS#

To ensure a robust integration, the FreeFileSync packages and the GVFS mounting modules must be verified as present and functional in the operating system.

A. Verification of FreeFileSync and realtimesync#

On Linux Mint, FreeFileSync is generally installed via Flatpak repositories or via local binary files. Their presence and versions need to be audited:

# Verify if FreeFileSync is installed via Flatpak
flatpak list | grep -i freefilesync

# OR check if the package is installed via the native apt manager
dpkg -l | grep freefilesync

# Get information and version of the installed Flatpak package
flatpak info org.freefilesync.FreeFileSync

# Confirm if the auxiliary RealTimeSync binary is available in the system PATH
which reatimesync 2>/dev/null || echo "RealTimeSync not found directly in PATH."

B. GVFS mount status and diagnostics#

Although we avoid the GVFS path for primary synchronization due to bottlenecks, its status still needs to be debugged if mount points are used for local checks:

# Verify if the gvfs directory for the current user is instantiated in the system
ls -la /run/user/$(id -u)/gvfs/

# Check if the Google account is indeed linked in the GNOME Online Accounts configurations
gsettings get org.gnome.online-accounts

# Test if Nemo File Manager can access the local GVFS mount point
nemo /run/user/$(id -u)/gvfs/

C. Google drive API connectivity test#

FreeFileSync performs direct authentication and queries against Google's REST APIs. It is vital to check network connectivity to the cloud provider's endpoints before invoking the tool.

# Test basic HTTPS connectivity to the Google Drive API
curl -I https://www.googleapis.com/drive/v3/about

# Audit system logs to check for potential failures or timeouts in synchronization
journalctl -u reatimesync --since "10 minutes ago"

4. Executing strict local physical synchronization#

To achieve zero-delay contingency, I needed real mirrored isolation - a local directory on RAID or LVM in charge of acting purely as a transport buffer (continuous Upload/Download). Having excluded terminal routes (rclone, rsync), the primary free engine that provides a solid GUI was chosen: FreeFileSync.

Executing mirroring parameters via API (FreeFileSync)#

FreeFileSync is designed as a monolithic mirror of robust LUNs transferred to user workstation directories.

1. Installation and Layer Mounting:

Isolation was activated using pre-packaged Flatpak instances via the isolated Software Manager on Linux Mint to mitigate global dependencies hell collisions with apt.

1. Transfer Agent Topology (The Two-Way Bridge):

The main grid requires absolute pathing (strict Source -> strict Destination).

• Left (Source Host): Physical absolute path via /home/user/MeusDocumentos manually consolidated at the root of operation.
• Right (Destination Cloud Handler): Attempting to trigger GVFS shortcuts (/run/user/1000/gvfs/...) corrupts the tree due to timeout failures during mass-fetches. The actual surgical solution relocates the route by clicking the internal Cloud-Provider icon on the directory tab. This infrastructure ignores the local gvfs, authorizing pure Tokens via its own packaged REST API, which injects direct, ultra-accelerated manipulation of the Google Drive File System. Maximum stability verified.

1. Algorithmic Execution Condition:

Within the central engine (Logic Gear Icon), the abstract policy had to be changed to "Two way": that way, an isolated timestamp overwrite, regardless of the remote origin or local bash mutation, triggers an update in the equivalent matrix in a perfect cascade.

5. Conflict resolution, logging, and advanced automation#

Stable background synchronization requires clear policies for resolving conflicts and robust automation that does not rely on repetitive manual clicks.

A. Conflict resolution policies setup#

When a file is modified simultaneously in the cloud and on the local disk, FreeFileSync detects the conflict. In the ~/.config/freefilesync/LastRun.ffs_gui file or in the synchronization profile GUI, you must define the collision behavior:

• Keep newer: Replaces the older file with the one having the newer timestamp.
• Keep larger: Keeps the file with the larger logical size.
• Manual resolution: Halts and waits for operator intervention to prevent data loss.

# Forensic command to search for temporary conflict files generated in the working directory
find /home/user/MeusDocumentos -name "*conflict*" -type f

B. Log inspection and rotation#

All synchronization jobs log events in XML files and plain text logs. Monitoring these logs is critical for the success of background automation tasks.

# List logs generated by FreeFileSync runs in the user configuration directory
ls -la ~/.config/freefilesync/

C. Automation via cron (batch processing)#

The bypass to execute periodic synchronizations without human intervention is to export the GUI profile as a .ffs_batch file and configure it in the operating system cron.

# Edit the crontab of the logged-in user
crontab -e

# Add the following entry to execute the batch synchronization silently every hour
0 * * * * flatpak run --command=FreeFileSync org.freefilesync.FreeFileSync /home/user/.config/freefilesync/sync.ffs_batch

# List the configured schedules in the user crontab for validation
crontab -l

6. The core automation (realtimesync background daemoning)#

Configuring the pipeline was straightforward, but operating it interactively by requiring "repetitive GUI clicks" does not solve the Sync daemon gap (the expertise provided out-of-box in Windows). The bypass injects the partner binary topology of the FreeFileSync base: the autonomous manager RealTimeSync.

Base transactional automation sequence:

1. The entire matrix of rules (left/right paths, local exclusions, dual-sync policies) is exported natively within the parameter base, saving a batch subroutine called .ffs_batch in the ~/.config/freefilesync/sync.ffs_batch directory.
2. The RealTimeSync binary is launched, delegating the raw import of this consolidated .ffs_batch profile.
3. The target was inserted into the isolated handler mitigated to the AppletTray system monitor in the background.

The instantiated daemon actively captures strict native notifications from the local File System's Inotify subsystem. Cache changes or daily bash mutations trigger invisible delegated scripts that push partial commits directly, consolidating the image to the remote Cloud.

7. Post-configuration verification and active monitoring#

To ensure that automatic synchronization and dynamic directory monitoring are indeed running, perform the following technical validations.

A. Validate running sync processes#

Use process tracing utilities to make sure the sync daemons remain active in volatile memory:

# Verify if FreeFileSync has active processes
ps aux | grep freefilesync

# Confirm if the RealTimeSync daemon is listening for file modification events
ps aux | grep reatimesync

# Search collectively for any of the running sync services
ps aux | grep -E "freefilesync|reatimesync" | grep -v grep

B. Practical manual sync test (propagation test)#

Perform an end-to-end test by creating a dummy file in the local directory and tracking its automatic copy to the cloud.

# Create a temporary test file in the synchronized directory
touch /home/user/MeusDocumentos/test-sync-$(date +%Y%m%d).txt

# Wait for the inotify notification (typically configured for 10 seconds)
sleep 15

# Verify if the file was propagated and if new entries were added to the log
ls -la ~/.config/freefilesync/

8. Wi-fi troubleshooting / cloud sync migration checklist#

Follow this tactical 5-phase checklist to perform the transition from Air Live Drive to FreeFileSync on Linux:

1. Pre-migration#

• [ ] Create a compressed backup of the local directory using tar.
• [ ] Validate available local disk space using df -h.
• [ ] Map the destination folder permissions and ownership with stat.
• [ ] List current exclusion rules (temporary files, trash, etc.).

2. Installation#

• [ ] Install the FreeFileSync package via Flatpak manager or the official binary.
• [ ] Confirm if the batch sync daemon and the inotify monitor are accessible.
• [ ] Map the user identifier (id -u) for internal connections if needed.

3. Configuration#

• [ ] Define the source folder (Left) and cloud destination (Right) via REST API.
• [ ] Configure the central synchronization policy as "Two Way".
• [ ] Map conflict handling to "Keep newer" or "Manual resolution".
• [ ] Perform an initial interactive manual sync and validate the result in the cloud.

4. Automation#

• [ ] Save the configured synchronization profile as a .ffs_batch batch file.
• [ ] Configure RealTimeSync to load the .ffs_batch file and monitor the local folder.
• [ ] Add the Batch command to the user's cron (crontab -e) for secondary scheduled syncs.

5. Validation#

• [ ] Create local test files and confirm automatic synchronization.
• [ ] Periodically inspect the generated log files in the ~/.config/freefilesync/ directory.
• [ ] Monitor file integrity and execution logs for 24 consecutive hours.

9. Identified problems and severity matrix#

The following table presents the key operational issues mapped during the migration of cloud synchronizers:

Production takeaways#

Equipping Linux-based environments without paying for SaaS licenses or subjecting purely visual administrators to a dense shell requires surgical, tactical methodological replacements. GVFS 'Online Accounts' delivers wonderful transient Fetch/Read abstractions based on pure demand. For a concrete Stateful architecture resistant to the loss of BGP routes maintained entirely under a graphical management interface: The native modular pairing of FreeFileSync autonomously linked to the RealTimeSync inotify delivers immaculate, superior parity (Zero parametric Rclone).

See also

Infrastructure Anatomy of a phantom subsystem: debugging Bluetooth on Linux

Infrastructure Perfect storm on legacy hardware

Infrastructure Container engineering: replacing WSL with an isolated Podman and Distrobox workflow on Linux Mint

This post is licensed under CC BY-NC.