How to Use Rclone: The Beginner's Guide (First Install, the Remote Rule, and the Mount Rule)

CodexFuse Team · 2026-11-01T04:18:19.132Z · 14 min read

Rclone is the free, open-source CLI that syncs, copies, and mounts 70+ cloud storage services. This beginner's guide covers install, the remote rule, copy vs sync vs move, --dry-run safety, mounting, encryption, and cron automation.

If you want to move files to the cloud without installing a vendor's app on every machine, learning how to use Rclone is the skill that unlocks everything. Rclone is a free, open-source, MIT-licensed command-line tool that talks to over 70 cloud storage products — Google Drive, OneDrive, Dropbox, Amazon S3, SFTP servers, and dozens more — with one consistent set of commands. This rclone tutorial for beginners runs the complete first arc in one guide: your first install, the remote rule (nothing works until you name a remote), the copy-sync-move lesson (sync DELETES — say it loud), the --dry-run habit, copying directly between two clouds, the mount rule, client-side encryption with the crypt remote, and cron automation. If Docker is new to you, read our Docker beginner guide first — Rclone rides along beautifully in containers.

What Is Rclone?

Rclone is a single-binary command-line program that copies, syncs, moves, mounts, and serves files across local disks and cloud storage using the same syntax everywhere. You download one file, you get no installer, no background daemon, and no vendor lock-in — the same commands work identically on Linux, macOS, and Windows. The project is rclone/rclone on GitHub, MIT licensed, with roughly 60,678 stars as of this writing; its latest release, v1.75.2, was published October 9, 2026.

Rclone's headline promise is the remote list: "Over 70 cloud storage products support rclone," per the official homepage — cloud drives, object stores, FTP, SFTP, WebDAV, and your own local disk as one more entry in the list. It can even copy directly from one cloud to another: where possible, rclone uses server-side transfers so a Drive-to-S3 copy never touches your local disk. Beginners often describe it as rsync for the cloud era, which is exactly the right mental model — and exactly why what is cloud storage matters here: Rclone is the tool you use once you understand what cloud storage is and want to control it from the terminal.

How Do You Use Rclone? The 10-Step First Arc

Here is the complete beginner path this guide builds, step by step:

1. Install Rclone from the official install script or your package manager.
2. Run rclone config and create your first remote — the remote rule says nothing works before this.
3. Confirm it with rclone listremotes and peek inside with rclone ls cloud:backups.
4. Copy one test folder with rclone copy ./test cloud:test — copy never deletes.
5. Learn the colon syntax: cloud:path is the remote; cloud without the colon is just a local folder.
6. Make --dry-run a reflex before every sync, move, or delete — it previews changes without touching anything.
7. Learn the copy-sync-move lesson: copy adds, move relocates, sync mirrors the destination to match the source — and deletes the extras.
8. Throttle yourself with --bwlimit so a first sync does not anger the provider's API quotas.
9. Mount the remote as a drive with rclone mount for daily browsing and editing.
10. Automate it with cron once the commands run cleanly by hand.

How Do You Install Rclone?

Install Rclone from the official script, not from a stale distro package. The official one-liner is sudo -v ; curl https://rclone.org/install.sh | sudo bash, and the official install docs list package-manager routes too: brew install rclone on macOS, winget install Rclone.Rclone or choco install rclone on Windows, and sudo snap install rclone on Linux.

The one gotcha is version lag: rclone's own docs warn that distribution packages "are often quite out of date" and recommend installing from rclone.org for the latest version. On a server you want the current release line — verify with rclone version after installing. As of this writing the current release is v1.75.2 (published October 9, 2026, per the GitHub releases API).

What Is the Remote Rule — and How Do You Configure Your First Remote?

The remote rule is simple: nothing works until rclone config names a remote. A remote is a named connection to a storage service — once it exists, every command just says cloud:path instead of logging into accounts and clicking through browser tabs.

The interactive flow goes like this: run rclone config, type n for a new remote, give it a short name (say cloud), and pick your storage type from the numbered list — Google Drive, OneDrive, Dropbox, S3, SFTP, and dozens more. Accept the defaults for client ID and secret unless you know you need your own, then answer "yes" when it asks to use a web browser to authenticate: your browser opens a page on http://127.0.0.1:53682/auth where you sign in once, and rclone's local webserver collects the token. After that, the cloud is just a name on your command line.

Two details beginners miss: first, for Google Drive, rclone's shared client ID is being retired and will stop working during 2026, so creating your own client ID is now strongly recommended — read the official Drive docs before you set up anything you will depend on. Second, the colon is load-bearing: cloud:backups means "the backups folder on my cloud remote," while cloud with no colon is treated as an ordinary local subdirectory. That missing colon is the number-one beginner typo.

You can also skip the wizard entirely: rclone config create myremote swift env_auth=true builds a remote from key-value pairs, with unanswered questions taking defaults. Remotes live in $HOME/.config/rclone/rclone.conf (overridable with --config), and rclone listremotes shows every name you have configured.

Rclone Copy vs Sync vs Move — What Is the Difference?

Copy adds, move relocates, sync mirrors — and syncing deletes whatever is missing from the source. This is the load-bearing lesson of Rclone, so learn it before your first real transfer.

rclone copy source dest copies files from source to destination and "doesn't delete files from the destination" — anything already at the destination that is not in the source is simply left alone. rclone sync source dest makes "source and dest identical, modifying destination only," which means the destination is updated to match the source "including deleting files if necessary." The sync docs explicitly advise testing with --dry-run or --interactive first because the data loss is real. rclone move source dest does a server-side move where possible, and otherwise copies the files into the destination and then deletes the originals from the source when the copy succeeds.

Before you run any of these against real data, you need a machine to run them on. Most beginners run Rclone on the same VPS that hosts their other services; if you have not picked a server yet, our what is VPS hosting guide explains the whole landscape.

Why Should Every Sync Start with --dry-run?

Because --dry-run (short form -n) does "a trial run with no permanent changes." You see exactly what would be copied, moved, or deleted, and nothing on disk changes — you can run it as many times as you like while you think.

Make it a reflex on every destructive command. The pattern is rclone sync ./photos cloud:photos --dry-run -v first, read the list, and only then run the real thing. Community guides repeat the same advice: always use --dry-run before any command that modifies data. When the stakes are high, --interactive goes further and asks you before each change.

The rule of thumb: dry-run every new sync, and re-dry-run whenever the destination matters — production folders, shared drives, anything you cannot rebuild. Five seconds of preview beats an afternoon of restore.

How Do You Copy Files Between Two Cloud Providers?

Put two remotes in one command: rclone copy drive:photos s3:backups. Where possible, rclone employs server-side transfers "to minimise local bandwidth use and transfers from one provider to another without using local disk" — a 50 GB migration can run from your laptop without downloading a single byte to it.

After a big migration, prove it worked with rclone check drive:photos s3:backups, which compares the two sides and reports any mismatch. rclone size cloud:photos gives you the object count and total size of a remote path — handy for sanity-checking before and after a move. One practical shape this enables: backing up the same local folder to two different clouds in one loop, which several community tutorials use as the canonical "one command, many destinations" pattern.

How Do You Use Rclone with Google Drive?

Configure Drive as a remote through rclone config and pick drive from the storage list. Accept the defaults through scope and team-drive prompts, authenticate in the browser when asked, and then treat it like any other remote: rclone copy ./photos cloud:photos.

Two Drive-specific notes: as mentioned above, the shared client ID rclone ships is being retired during 2026 — if you will rely on this remote, create your own Google client ID per the official Drive docs before you go further. And big first syncs hit Drive's API quotas, so throttle yourself: --bwlimit 2M caps transfers at roughly 2 MiB/s (the flag's unit is KiB/s, with B|K|M|G|T|P suffixes), and pairing it with --transfers 2 keeps providers that dislike parallel uploads happy.

How Do You Use Rclone with S3?

S3 is the remote Rclone feels most at home with. Create it non-interactively with rclone config create myremote s3 env_auth=true to read credentials from the environment, or walk the rclone config wizard and enter your access key, secret key, and region when prompted — the same remote shape works for S3-compatible providers like Wasabi and MinIO with the endpoint changed.

For S3, --fast-list is the flag that matters most: it uses a recursive list when available, which means more memory but far fewer transactions — exactly what you want with millions of small objects. Combine it with -P (--progress) to watch real-time transfer statistics on a big upload. And quote your filter patterns: --include "*.txt" keeps your shell from expanding the wildcard before Rclone sees it.

How Do You Mount Cloud Storage as a Local Drive?

rclone mount cloud: /mnt/cloud makes your remote browsable and editable like an ordinary disk — your files open in your normal apps, and Rclone translates reads and writes behind the scenes. This is the mount rule: anything you would do with a folder, you can do with a mounted remote.

Mounts need a FUSE layer. On Linux, make sure fusermount or fusermount3 is on your PATH. On Windows, install WinFsp first (the Chocolatey install docs pair choco install rclone with choco install winfsp). On macOS, mounting works through the built-in NFS server, macFUSE, or FUSE-T.

The flag that decides whether apps actually work on the mount is --vfs-cache-mode, which takes off, minimal, writes, or full (the default is off). The mount docs say applications will not work with their files on an rclone mount without --vfs-cache-mode writes or full, because seeking needs a local cache — full buffers all reads and writes to sparse disk files, so point --cache-dir somewhere with real free space.

For a mount that survives reboots, the docs show two supported shapes: a systemd service with Type=notify (note that systemd units get no HOME or PATH, so pass absolute --config and --cache-dir paths), or the /sbin/mount.rclone symlink trick, which lets you describe the mount as a systemd .mount unit — for example with options like rw,_netdev,allow_other,vfs-cache-mode=writes,config=/etc/rclone.conf,cache-dir=/var/rclone — plus an optional .automount unit or fstab line.

How Do You Encrypt Uploads with the Rclone Crypt Remote?

The crypt remote gives you client-side encryption: it encrypts before uploading and decrypts after downloading, "leaving the data encrypted at rest in the wrapped remote." Your provider stores ciphertext; only your config holds the keys.

Set it up as a remote of type crypt wrapping your existing remote, then use it like any other remote: rclone copy ./photos secrets:photos uploads fully encrypted. File and directory names are encrypted by default too, using NaCl SecretBox with XSalsa20 and Poly1305 for the content.

Two warnings are load-bearing. First, the password is stored in rclone.conf in a lightly obscured form — rclone's docs say that only protects it from cursory inspection, and you should use the configuration password (option s) Set configuration password in the rclone config menu) for real protection. Second, you cannot change the password on already-encrypted content: the only way to a new password is re-uploading everything through a crypt remote configured with it. Pick a strong password, store it in a password manager, and never lose it — there is no recovery.

How Do You Automate Rclone with Cron?

Once your commands run cleanly by hand, cron is the obvious next step. A nightly backup looks like this:

0 2 * * * /usr/bin/rclone sync /home/user/photos cloud:photos --log-file /var/log/rclone-photos.log

Three cron rules: use absolute paths for the rclone binary and any paths (cron's PATH is not yours), pass --config /home/user/.config/rclone/rclone.conf explicitly if the job runs as a user whose HOME differs, and log everything with --log-file so silent failures leave a trace. The workflow is always the same: test manually with --dry-run first, then schedule the exact command you verified.

Is Rclone Bisync Ready for Beginners?

Bisync is Rclone's two-way synchronization — it keeps two directories identical in both directions, unlike sync, which is one-way. The current bisync docs call it "an advanced command" and tell you to use it with care, with a data-loss warning; the word "experimental" now appears only in the changelog entry for the --resilient flag, not as a label on the command itself.

Read that as honest caution, not a green light. Two-way sync has real failure modes (conflicts, deletes on both sides, clock skew), which is why older guides still carry the experimental warning. Beginners should test bisync on non-critical data only — and until you genuinely need two-way sync, copy, sync, and move cover almost everything a beginner does.

What Are Rclone's Most Useful Flags?

These seven flags cover most beginner workflows — tune them before you reach for anything exotic:

Rsync vs Rclone vs Syncthing — Which One Do You Actually Need?

Use rsync for servers you own, Syncthing for devices that sync continuously, and Rclone for cloud remotes. They are lanes, not rivals: rsync moves files over SSH between machines you control; Syncthing keeps your phone, laptop, and server in sync device-to-device; Rclone moves files between your machine and over 70 cloud storage products with the same syntax.

The graduation story is real: many people start with rsync to a VPS, outgrow one machine, add Syncthing between devices, and then reach for Rclone the first time they need a cloud drive, an S3 bucket, or a cloud-to-cloud migration in the same workflow. For true backup semantics — snapshots, deduplication, restore points — reach for a backup tool like Restic instead: Rclone mirrors files faithfully, but it does not keep history.

How Do You Serve Files from Rclone?

Yes — Rclone is also a tiny file server. rclone serve http runs "a basic web server to serve a remote over HTTP," and rclone serve webdav serves a remote over WebDAV; both were added in v1.39. Neither authenticates by default, so set a username and password with --user and --pass, or point --htpasswd at an Apache-format password file (BCrypt recommended).

Serve is plaintext HTTP, so do not expose it directly. The standard shape is Rclone serving on localhost behind a reverse proxy that terminates HTTPS — if you have not set one up, our Caddy beginner guide walks the whole thing. Mount your cloud, serve it over HTTP, and your phone's file manager can browse the same files your laptop synced.

Sources

• GitHub API — rclone/rclone repository (v1.75.2, released 2026-10-09, ~60,678 stars, MIT license): api.github.com/repos/rclone/rclone
• GitHub API — rclone latest release: api.github.com/repos/rclone/rclone/releases/latest
• Rclone homepage ("Over 70 cloud storage products support rclone"): rclone.org
• Rclone install docs (install.sh one-liner, package managers, distro-version warning): rclone.org/install
• Rclone Google Drive docs (config flow, 127.0.0.1:53682 auth, shared client ID retiring during 2026): rclone.org/drive
• Rclone global flags docs (--dry-run, --transfers, --checkers, --bwlimit, --fast-list, --exclude/--include): rclone.org/flags
• Rclone copy command docs ("Doesn't delete files from the destination"): rclone.org/commands/rclone_copy
• Rclone sync command docs (destination updated "including deleting files if necessary", --dry-run advice): rclone.org/commands/rclone_sync
• Rclone move command docs (server-side move, copy-then-delete fallback): rclone.org/commands/rclone_move
• Rclone mount docs (FUSE requirements, --vfs-cache-mode, systemd service and mount.rclone patterns): rclone.org/commands/rclone_mount
• Rclone crypt docs (client-side encryption, NaCl SecretBox, password immutability): rclone.org/crypt
• Rclone bisync docs (advanced command, data-loss warning): rclone.org/bisync
• Rclone serve http docs (basic web server, --user/--pass, --htpasswd): rclone.org/commands/rclone_serve_http
• Rclone serve webdav docs: rclone.org/commands/rclone_serve_webdav
• Rclone config create docs (non-interactive remote creation): rclone.org/commands/rclone_config_create
• Rclone command reference docs (rclone ls, size, check, docs): rclone.org/docs
• Pablo Murad — "rclone: One Tool, Almost Every Cloud" (OneDrive config arc, --bwlimit/--transfers lesson, rclone size/ncdu): pablomurad.com
• How-To Geek — "This one free tool backs up my files to multiple cloud services at once" (Aug 2026, multi-cloud backup arc): howtogeek.com
• CleverUptime — "rclone Command: Tutorial & Examples" (copy/sync/move examples, --dry-run rule, troubleshooting): cleveruptime.com
• UCLA Data Science Center — "Introduction to Rclone: File Transfers, Listing, and Verification" (--dry-run semantics, --include quoting): ucla-data-science-center.github.io
• SFL Services LLC docs — "Linux - How to use rClone" (verified against v1.75.1, Oct 2026; SFTP config, symlink flags, rclone obscure): docs.sflservicesllc.com

Frequently Asked Questions

Is Rclone free?

Yes. Rclone is MIT-licensed open source and completely free — there is no account, no subscription, and no paid tier. You do pay whatever your cloud provider charges for storage and bandwidth, but the tool itself costs nothing.

What happens if I forget the colon in remote:path?

Rclone treats any path without a colon as a local filesystem path — so rclone copy ./photos cloud tries to copy into a local folder literally named "cloud" in your current directory. The remote-name-colon syntax (cloud:photos) is the number-one beginner typo, and it is worth checking every command for.

Does Rclone sync delete files?

Yes — rclone sync makes the destination identical to the source, "including deleting files if necessary." That is why the docs advise testing with --dry-run first. If you want a safe one-way upload that never deletes anything at the destination, use rclone copy instead.

Can Rclone copy directly from Google Drive to S3?

Yes. rclone copy drive:photos s3:backups copies between two remotes, and where possible rclone uses server-side transfers so the data moves without being downloaded to your machine first. Run rclone check afterward to verify both sides match.

What happens if I lose my crypt remote password?

You cannot recover it. Rclone's docs state that it is not possible to change the password of already-encrypted content — the only path to a new password is re-uploading everything through a crypt remote configured with it. Store the password in a password manager before your first encrypted upload.