The missing cloud folder
You just switched to Fedora and your old workflow relied on Google Drive being a permanent folder on your desktop. You open the Files app and the cloud icon is missing. You try dragging a document to the sidebar and nothing happens. The system is not broken. Fedora simply does not ship with a built-in Google Drive client out of the box. You have two paths forward. One gives you a seamless desktop experience for viewing and opening files. The other gives you a command-line engine that mirrors your cloud storage exactly.
What is actually happening under the hood
Cloud storage on Linux works differently than on Windows or macOS. Those operating systems bundle proprietary background daemons that constantly poll the cloud API and maintain a local cache. Fedora prioritizes open standards and user control. GNOME Online Accounts uses the D-Bus and GVfs stack to mount remote storage as a virtual filesystem. It streams files on demand. It does not download everything to your disk. rclone takes the opposite approach. It talks directly to the Google Drive REST API over HTTPS, calculates checksums, and moves bytes until the local directory matches the remote state. Think of GOA as a window into your cloud. Think of rclone as a precision crane that moves boxes until both sides match.
GVfs intercepts file operations in the desktop environment and translates them into API calls. When you open a PDF in Files, GVfs fetches the bytes, pipes them to the viewer, and discards them when you close the file. No local copy remains. rclone bypasses the desktop stack entirely. It reads the remote directory listing, compares it to your local filesystem, and executes a transfer plan. It logs every action to standard output and writes a detailed JSON log if you request it. The two tools solve different problems. One optimizes for convenience. The other optimizes for data integrity.
Test the mount by creating a text file in Drive and opening it in Files. If it loads, the D-Bus session is healthy.
Setting up GNOME Online Accounts for read-only access
This method works when you only need to open documents, view photos, or drop a file into the cloud occasionally. It integrates directly into the GNOME Files application.
Open the system Settings application. Navigate to the Online Accounts panel. Click the plus button and select Google. The browser will open a Google authentication window. Grant the requested permissions. Return to Settings and toggle the Drive switch to on.
The Files app will now show a Google Drive entry in the sidebar. Click it to browse. Files open through the default GNOME document viewer or LibreOffice. Changes save back to the cloud when you close the document. This is not a sync client. It is a remote mount. If you rename a file in the Files app, the change propagates. If you delete a file locally, it disappears from Drive. Network drops will pause the stream.
GVfs mounts live in /run/user/1000/gvfs/. You can access them from the terminal if you know the exact URI. The path looks like gvfs-mount://google-drive/.... Most desktop users stick to the Files app. Terminal users prefer rclone. If the mount fails to appear, check the D-Bus session with gio mount -l. The command lists all active GVfs mounts. If Google Drive is missing, the authentication token likely expired or the gvfs-google backend is not installed.
Install the missing integration package if the sidebar entry never appears.
sudo dnf install gvfs-google
# WHY: provides the GVfs backend for Google services
# WHY: registers the mount helper with the desktop session
# WHY: required for the Files app sidebar integration
Restart the Files app after installing the package. The D-Bus daemon will load the new backend automatically. Do not reboot the machine. A simple application restart reloads the GVfs session.
Test the mount by creating a text file in Drive and opening it in Files. If it loads, the D-Bus session is healthy.
Configuring rclone for full synchronization
You need rclone when you want bidirectional sync, automated backups, or scriptable cloud storage. It runs entirely in the terminal and does not require a desktop environment.
Install the package from the default Fedora repositories. The package includes the binary and the configuration helper.
sudo dnf install rclone
# WHY: pulls the latest stable release from Fedora's repos
# WHY: avoids third-party RPMs that might drift from upstream
# WHY: integrates with dnf for automatic security updates
Run the configuration wizard. It will ask for a remote name, the storage type, and OAuth credentials. Choose Google Drive when prompted. The wizard will print a URL and ask you to paste an authentication code. Open the URL in your browser, sign in, and copy the code back to the terminal.
rclone config
# WHY: launches the interactive setup wizard
# WHY: stores credentials in ~/.config/rclone/rclone.conf
# WHY: uses OAuth2 tokens that expire and refresh automatically
The wizard will ask if you want to edit the config manually. Type n. It will ask if you want to continue. Type y. The remote is now registered. The configuration file lives in your home directory. It contains the client ID, client secret, and encrypted tokens. Never share this file. Treat it like a private SSH key.
Sync a folder using the sync command. This command makes the destination match the source exactly. It deletes files on the destination that do not exist on the source. Run it carefully.
rclone sync remote:Documents ~/Documents/DriveSync
# WHY: copies new and changed files from Drive to local disk
# WHY: removes local files that were deleted in the cloud
# WHY: calculates SHA-256 checksums to verify data integrity
If you want to avoid accidental deletions, use copy instead of sync. The copy command only adds or updates files. It never deletes.
rclone copy remote:Documents ~/Documents/DriveSync
# WHY: safe one-way transfer that preserves local history
# WHY: skips files that already match size and checksum
# WHY: ideal for backup workflows where local data must survive
Configuration files for rclone live in ~/.config/rclone/. Never move them to /etc/. User-level tools store state in the home directory. System-wide tools use /etc/. Keep them separate to avoid permission conflicts.
Run rclone ls remote: before syncing. Verify the remote path exists and contains the expected files.
Verifying the transfer
Check the local directory structure. Compare file counts and modification times. rclone prints a summary after every run. Read the output. It tells you exactly how many files transferred, how many bytes moved, and how many were skipped.
rclone lsd remote:
# WHY: lists top-level directories in the remote storage
# WHY: confirms the remote path resolves correctly
# WHY: shows folder sizes to catch unexpected empty mounts
Use the size command to verify byte-level accuracy before and after a transfer. The command calculates the total size of a remote directory without downloading the files.
rclone size remote:Documents
# WHY: queries the API for total byte count
# WHY: avoids downloading data just to check totals
# WHY: useful for pre-sync validation and post-sync verification
For GOA mounts, open the Files app and navigate to the Drive folder. Right-click a file and select Properties. The location field will show the GVfs path. If the file opens without a network error, the mount is active.
Trust the checksum output. If rclone says the transfer is complete, the bytes match. Do not guess.
Common pitfalls and error messages
The most frequent failure is an expired OAuth token. rclone will print Failed to create file system: invalid token. Run rclone config again and re-authenticate. The wizard handles token refresh automatically if you complete the OAuth flow.
Permission errors appear when the Google account lacks access to a shared folder. The terminal will show googleapi: Error 403: User does not have sufficient permissions. Check the folder sharing settings in the Google Drive web interface. Grant editor access if you plan to sync.
GVfs mounts sometimes fail to appear in the sidebar. This usually means the gvfs-google package is missing or the D-Bus session dropped. Install the missing integration package. Restart the Files app. Check the session logs with journalctl -xeu gvfsd. The x flag adds explanatory context and the e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> muscle-memory style.
Network timeouts during large syncs are normal. rclone handles retries automatically. The default retry count is four. Increase it if you are on an unstable connection.
rclone sync remote:LargeBackup ~/Backup --retries 10
# WHY: raises the retry limit for flaky networks
# WHY: prevents premature aborts on transient API errors
# WHY: keeps the sync job alive through brief outages
Google enforces API rate limits. If you sync thousands of small files, the API will return 429 Too Many Requests. rclone backs off automatically. You can reduce the concurrency to stay under the limit.
rclone sync remote:Photos ~/Photos --transfers 2 --checkers 4
# WHY: limits parallel uploads to avoid API throttling
# WHY: reduces concurrent metadata requests
# WHY: trades speed for reliability on quota-heavy accounts
Read the error code before forcing a fix. A 403 means permissions. A 401 means authentication. A timeout means the network. Treat the symptom, not the guess.
Which tool fits your workflow
Use GNOME Online Accounts when you want a graphical interface that integrates with the Files app and LibreOffice. Use rclone when you need scriptable, checksum-verified synchronization that runs in the background. Use rclone sync when you want the local folder to mirror the cloud exactly, including deletions. Use rclone copy when you want a safe backup that never removes local files. Use a systemd user timer when you want automated daily syncs without manual intervention. Stay on the default Fedora repository version unless you need a bleeding-edge feature that justifies compiling from source.
Pick the tool that matches your threat model. Convenience requires GOA. Control requires rclone.