Dropbox online-only on Fedora 44 with rclone

A complete guide to running Dropbox on Fedora with an online-only workflow similar to the “Smart Sync” feature available on Mac and Windows. Files stay in the cloud, are downloaded on demand when you open them, and local changes are uploaded automatically — without maintaining a full local mirror or continuously synchronizing the entire Dropbox tree.

The mount lands on ~/Dropbox, the same path the official client uses on macOS and Windows, so scripts, symlinks, and muscle memory carry across machines without translation.

Notation: replace <user> with your own username where needed. Most paths use %h, which is resolved by systemd.

How this guide is organized. Steps 1 to 6 are the installation and are all required. Everything after them is either reference material explaining how the mount behaves, or optional extras you can skip entirely.

Why this approach

Dropbox does not offer online-only mode on Linux (officially limited to Windows and macOS, with no public roadmap). The official Dropbox client therefore forces a full local sync, which consumes a lot of disk space and bandwidth.

There are four options on Linux in 2026:

• Official Dropbox client: full sync, no online-only, filesystem restrictions (ext4 was required for a long time), no ARM, heavy process, historical CVE on the auth flow. Avoid.
• Maestral (open-source, GitHub samschott/maestral): excellent OSS sync client, supports Selective Sync via a .mignore file, stores credentials in Secret Service. But still no online-only — it is a “lightweight” local sync. Relevant if you want a real sync.
• Flatpak wrapper: just a webview of dropbox.com, unofficial, not a real client. No value over a pinned Chrome tab.
• rclone mount: one of the most practical ways to obtain true on-demand, online-only access to Dropbox on Linux without maintaining a full local mirror. Mounts Dropbox as FUSE, downloads on demand, with a configurable local cache.

This guide covers the rclone option.

No Dropbox app required. You do not install Dropbox or its official client on the machine at all. rclone talks to Dropbox directly through its API (you authorize it once via OAuth in a browser) and handles everything itself — listing, downloading on demand, and uploading changes. And it is not Dropbox-specific: the same rclone binary works against 70+ cloud storage providers (Google Drive, OneDrive, S3, Backblaze B2, Nextcloud/WebDAV, and many more), so the exact approach here transfers to any of them by configuring a different remote.

Prerequisites and environment

• Fedora 44 (tested in May 2026)
• rclone ≥ 1.71 (1.73.4 available at time of writing)
• fuse3 ≥ 3.18
• Dropbox account (Basic, Plus, Family, Professional, or Business)
• Browser access for the initial OAuth

Quick check:

cat /etc/fedora-release
rpm -q rclone fuse3 2>/dev/null
rclone version
fusermount3 --version

Step 1 — Install the packages

sudo dnf install -y rclone fuse3

On Fedora 44, the official packages are up to date. No need for the curl | bash install script offered on rclone.org — prefer the signed Fedora RPM package.

On modern Fedora, the fuse Unix group no longer exists. Mounting under your own UID requires no group membership and no change to /etc/fuse.conf. See the optional --allow-other section at the end if you have a genuine multi-UID need.

Step 2 — Configure the Dropbox remote via OAuth

Launch the interactive wizard:

rclone config

Answers in order:

1. n (new remote)
2. name>: dropbox (the name used everywhere afterward — systemd service, mount, scripts)
3. Storage>: dropbox
4. client_id>: leave empty (Enter)
5. client_secret>: leave empty (Enter)
6. Edit advanced config?: n
7. Use web browser to automatically authenticate?: y
8. A tab opens to Dropbox → authorize rclone-config (with 2FA if enabled) → “Success!” shown in the browser
9. Keep this "dropbox" remote?: y
10. q to exit the menu

Check:

rclone listremotes
rclone about dropbox:

rclone about should return your Dropbox quota (Total / Used / Free). If so, OAuth worked.

Note on client_id

The default client_id is shared across all rclone users. Dropbox may throttle it during periods of global load. For occasional use, this is invisible. For heavy use, create your own Dropbox App (free, dropbox.com/developers, 5 minutes) and paste its app key and app secret in place of the default.

Step 3 — Manual mount test

mkdir -p ~/Dropbox

rclone mount dropbox: ~/Dropbox \
    --vfs-cache-mode full \
    --vfs-cache-max-size 50G \
    --vfs-cache-max-age 7d \
    --vfs-cache-min-free-space 100G \
    --dir-cache-time 5m \
    --poll-interval 1m \
    --umask 0077 \
    --daemon

Wait 5–10 seconds for bootstrap, then check:

ls ~/Dropbox | head -10
df -h ~/Dropbox
findmnt -T ~/Dropbox

The Dropbox content should appear. df shows the total size of the account. findmnt confirms fuse.rclone and shows source, target and mount options in one line.

Functional test

echo "test rclone $(date)" > ~/Dropbox/test-rclone.txt
sleep 5
rclone ls dropbox: | grep test-rclone

The file should appear on the Dropbox API side within a few seconds. Delete it afterward:

rm ~/Dropbox/test-rclone.txt

Clean unmount

fusermount3 -u ~/Dropbox

Step 4 — systemd user service for automatic mounting

The service is a template (rclone@.service), so the same file can later mount other remotes — rclone@gdrive, rclone@onedrive — once they exist in rclone config.

The mount point is exposed as an environment variable (RCLONE_MOUNTPOINT) rather than hard-coded. systemd performs variable substitution in Exec* command lines, so relocating any instance takes a single Environment= line in a drop-in — with no duplication of ExecStart.

The template’s default is ~/Cloud/<remote>, a neutral convention for remotes that have no established path. Dropbox does have one, so we override it to ~/Dropbox right away. Both files are created below; this is the standard installation, not an optional detour.

The template:

mkdir -p ~/.config/systemd/user

cat > ~/.config/systemd/user/rclone@.service << 'EOF'
[Unit]
Description=rclone FUSE mount for %i
Documentation=https://rclone.org/commands/rclone_mount/

[Service]
Type=notify
Environment=RCLONE_MOUNTPOINT=%h/Cloud/%i

ExecStartPre=-/usr/bin/fusermount3 -uz ${RCLONE_MOUNTPOINT}
ExecStartPre=/usr/bin/mkdir -p ${RCLONE_MOUNTPOINT} %h/.cache/rclone %h/.local/state/rclone

ExecStart=/usr/bin/rclone mount %i: ${RCLONE_MOUNTPOINT} \
    --config=%h/.config/rclone/rclone.conf \
    --vfs-cache-mode full \
    --vfs-cache-max-size 50G \
    --vfs-cache-max-age 7d \
    --vfs-cache-min-free-space 100G \
    --dir-cache-time 5m \
    --poll-interval 1m \
    --umask 0077 \
    --default-time 2026-01-01 \
    --log-file %h/.local/state/rclone/rclone-%i.log \
    --log-level INFO

ExecStop=/usr/bin/fusermount3 -u ${RCLONE_MOUNTPOINT}

Restart=always
RestartSec=10

[Install]
WantedBy=default.target
EOF

The Dropbox mount point:

mkdir -p ~/.config/systemd/user/rclone@dropbox.service.d

cat > ~/.config/systemd/user/rclone@dropbox.service.d/mountpoint.conf << 'EOF'
[Service]
Environment=RCLONE_MOUNTPOINT=%h/Dropbox
EOF

That is the whole override. Because ExecStartPre, ExecStart and ExecStop all reference ${RCLONE_MOUNTPOINT}, there is nothing to reset and nothing to duplicate — no risk of the template creating one directory while rclone mounts another, and a future change to the rclone flags is made in exactly one place.

A few notes on the unit:

• Type=notify: rclone signals systemd when the mount is ready, no race condition at startup.
• Environment=RCLONE_MOUNTPOINT=...: the single point of truth for the mount path. Use the braced form ${RCLONE_MOUNTPOINT} in Exec* lines — the unbraced $VAR form is word-split by systemd, which would break any path containing a space.
• ExecStartPre=-/usr/bin/fusermount3 -uz: preemptive lazy unmount before each start. The leading - tells systemd to ignore a possible error (normal on the first start, nothing to unmount). Avoids hangs caused by a zombie mount left behind by a previous rclone crash (see Troubleshooting).
• %h: the user’s home (resolved by systemd). %i: the instance name after the @ (so dropbox).
• XDG paths: cache in ~/.cache/rclone, logs in ~/.local/state/rclone.
• --umask 0077: files created in mode 0600, readable only by you.
• --dir-cache-time 5m and --poll-interval 1m: see Change detection below.
• --default-time 2026-01-01: default date shown for folders (see Why all folders show the same date).
• No KillSignal= is needed. systemd sends SIGTERM by default, and rclone has run its exit handlers on SIGTERM since v1.47 (April 2019). The mount is torn down cleanly.
• Restart=always rather than on-failure: a clean exit code 0 — for example after a manual fusermount3 -u — also brings the mount back. Note that Restart= never applies to a unit stopped explicitly with systemctl --user stop, whatever its value, so this does not fight you during maintenance. If you prefer a manual unmount to really make the mount disappear, Restart=on-failure is equally reasonable.

Activation:

systemctl --user daemon-reload
systemctl --user enable --now rclone@dropbox

Check:

systemctl --user status rclone@dropbox --no-pager
systemctl --user cat rclone@dropbox
findmnt -T ~/Dropbox
ls ~/Dropbox | head -5

Expected state: active (running), mount on ~/Dropbox, content listed.

systemctl --user cat is the command to remember: it prints the original template, every drop-in, and the order in which systemd loads them. For debugging an override it is far more useful than systemctl --user show -p ExecStart.

Step 5 — Secure the rclone configuration

First, confirm which configuration file rclone actually uses — it is not always the path you assume, especially if RCLONE_CONFIG is set or rclone was installed differently:

rclone config file

Then:

chmod 600 ~/.config/rclone/rclone.conf
ls -la ~/.config/rclone/rclone.conf

Must show -rw-------. This is the bare minimum — without it, anyone with read access to your home has your OAuth tokens.

Stronger measures exist — config encryption, disk encryption, 2FA — but they are choices rather than requirements. See Harden the configuration further under Optional extras.

Step 6 — Validate persistence

Log out of GNOME, log back in, then:

findmnt -T ~/Dropbox
systemctl --user status rclone@dropbox --no-pager

Expected: the mount on ~/Dropbox with filesystem fuse.rclone, and the service active (running).

One line in that status output looks alarming and is not. The first ExecStartPre reports status=1/FAILURE with entry for /home/<user>/Dropbox not found in /etc/mtab. That is the preemptive unmount finding nothing to unmount — precisely why the unit prefixes it with -. It appears on every clean start.

The installation is complete at this point. Nothing below is required for the mount to work.

Reference — how the mount behaves

Nothing here needs to be configured. This section explains what the settings from Step 4 actually do, and lists the commands you will use day to day.

Change detection: --poll-interval vs --dir-cache-time

These two flags are frequently confused, and the distinction matters for Dropbox.

• --poll-interval controls how often rclone asks the remote for changes, for backends that support change notification. The Dropbox backend implements ChangeNotify, so rclone is told about files modified from another computer or from dropbox.com. The default is 1 minute.
• --dir-cache-time controls how long directory listings stay valid in memory before rclone re-reads them. It is the fallback, not the mechanism that picks up remote changes.

Practical consequence: setting a very short --dir-cache-time (30s, for instance) does not make remote changes appear faster — polling already handles that — it just multiplies API calls and gets you closer to Dropbox throttling. 5m for the directory cache plus the default 1-minute polling is the sane combination.

VFS cache behavior

With --vfs-cache-mode full and the settings above:

• Browsing: an ls ~/Dropbox/Documents downloads only the metadata, not the files. The cache stays empty.
• Opening a file: downloaded on the fly into ~/.cache/rclone/vfs/dropbox/, presented to the calling application. First open = a few hundred ms to several seconds depending on size.
• Subsequent opens: instant as long as the file remains in the VFS cache. The cache is managed around the configured 50 GB / 7-day limits, though it may temporarily grow beyond the size limit while files are open or still pending upload.
• Saving: written to the local cache, then automatically uploaded to Dropbox in the background.
• Cache eviction: eligible cached files untouched for 7 days are evicted automatically and become online-only again. Files that are currently open, or whose upload has not completed, are not eviction candidates.

Check the cache volume:

du -sh ~/.cache/rclone/vfs/dropbox/ 2>/dev/null || echo "cache not populated yet"

The vfs/<remote>/ tree is created when the mount starts, but stays empty until a file is actually read: browsing the mount fetches metadata only.

Do not manually delete the VFS cache

With --vfs-cache-mode full, the cache directory may contain files whose upload to Dropbox is still pending — after a crash, a logout, or a shutdown while an upload was in flight. rclone resumes those pending uploads the next time the mount starts, provided the cache is intact. An rm -rf ~/.cache/rclone/ to reclaim disk space is therefore a genuine way to lose data you believed was saved.

If you need space, lower --vfs-cache-max-size and let rclone evict what it can safely evict.

Sizing the cache

The VFS cache is disposable data on a local disk. Size it against your working set — the files you actually open in a given week — not against the size of your Dropbox account, and not against the size of your SSD.

Two parameters matter more than the raw size:

• --vfs-cache-max-age is usually the more useful lever. The rclone default is one hour, which is aggressive: it evicts files you will reopen tomorrow and forces a re-download. A week keeps a real working set warm at essentially no cost on a large disk. Age eviction applies only to eligible files, so a pending upload is never dropped because it aged out.
• --vfs-cache-min-free-space is a floor, not a cap. It makes rclone start evicting when the filesystem holding the cache falls below the given free space, regardless of --vfs-cache-max-size. On a large disk this is the flag that actually protects you: the cache grows while there is room and shrinks when there is not.

RAM does not enter this equation — the VFS cache lives on disk. The memory-side levers are --buffer-size (16 MiB per open file by default, so it multiplies across concurrent reads) and --vfs-read-ahead, which only applies with --vfs-cache-mode full and helps sequential reads such as video playback. On a machine with 32 GB or more, --buffer-size 64M --vfs-read-ahead 128M is comfortable.

Why all folders show the same date

In Nautilus / GNOME Files, all Dropbox folders appear with an identical modification date (by default “26 years ago” → January 1, 2000). This is not a bug.

The Dropbox API does not expose folder modification dates, only those of individual files. When rclone has no info, it shows a hard-coded default date: 2000-01-01 00:00:00 UTC. For individual files (PDFs, docs, etc.), the real mtimes are correctly preserved and displayed — only folders are affected.

The --default-time flag (included in the service above with the value 2026-01-01) changes the date shown for entities with no known mtime. It is purely cosmetic but avoids the confusion of having folders permanently tagged “26 years ago”. Possible alternative values:

• --default-time 0s: uses rclone’s startup time (varies on each restart, not very useful)
• --default-time 2026-01-01T00:00:00Z: full RFC3339 format if the short version causes trouble

Note: this behavior is specific to backends that do not provide a folder mtime. On Google Drive or OneDrive, folders have a correct mtime and --default-time has no visible effect.

Honest limitations vs native Smart Sync on Mac/Windows

• No offline access to placeholders: a file not in cache requires Internet to be opened. On Mac/Windows, the icon stays visible and a double-click restores offline access. Here, with no network, open returns an error.
• No real-time bidirectional sync: if you edit simultaneously on two machines, it is last-write-wins based on timestamps. Remote changes surface through polling (about one minute), not instantly. For real-time collaboration, prefer another tool.
• A few apps with atomic rename: some IDEs (IntelliJ, VS Code) that use rename + replace on save can occasionally leave behind a .tmp. In practice, transparent for Word, LibreOffice, and standard text editors.
• No native status icons: no green check marks, no per-file placeholder badges in Nautilus.

Day-to-day commands

systemctl --user status rclone@dropbox
systemctl --user restart rclone@dropbox
systemctl --user stop rclone@dropbox
systemctl --user start rclone@dropbox
systemctl --user cat rclone@dropbox
journalctl --user -u rclone@dropbox -f
tail -f ~/.local/state/rclone/rclone-dropbox.log
findmnt -T ~/Dropbox
rclone about dropbox:
rclone ls dropbox:Documents
du -sh ~/.cache/rclone/vfs/dropbox/

Optional extras

Each of the following is independent and can be skipped. None is needed for a working online-only Dropbox mount.

Put the VFS cache on its own Btrfs subvolume

On a Fedora Btrfs installation with Snapper, this deserves attention before enlarging the cache.

If ~/.cache sits inside a subvolume that Snapper snapshots, every downloaded file is pinned by the next snapshot, and deleting cache entries frees nothing. A 50 GB cache then costs 50 GB per retained snapshot. The cache is also the worst possible workload for copy-on-write: constant random rewrites produce fragmentation and pointless checksum churn.

Give the cache its own subvolume. Btrfs snapshots are not recursive, so a nested subvolume is automatically excluded from any snapshot of its parent:

sudo btrfs subvolume create ~/.cache/rclone-vfs
sudo chown "$USER:$USER" ~/.cache/rclone-vfs
chmod 700 ~/.cache/rclone-vfs
chattr +C ~/.cache/rclone-vfs
sudo restorecon -Rv ~/.cache/rclone-vfs

Three of those lines exist because the subvolume is created by root, and it does not inherit what a normal mkdir in your home would have given it:

• chown and chmod 700: without them the directory is owned by root and world-readable, which contradicts the --umask 0077 used for the mount itself.
• restorecon: a subvolume created through sudo often ends up without a proper SELinux context. In ls -l this shows as a missing trailing dot in the mode field — drwx------. is labelled, drwxr-xr-x is not. On a Fedora system in enforcing mode, that will eventually bite.
• chattr +C disables CoW and must be applied while the directory is still empty; new files then inherit the attribute.

Verify all of it:

sudo btrfs subvolume list /home | grep rclone-vfs
lsattr -d ~/.cache/rclone-vfs
ls -Zd ~/.cache/rclone-vfs

Then point rclone at it by adding to ExecStart in ~/.config/systemd/user/rclone@.service:

--cache-dir=%h/.cache/rclone-vfs \

Stop the service first and check whether the old cache location still holds anything:

systemctl --user stop rclone@dropbox
find ~/.cache/rclone/vfs ~/.cache/rclone/vfsMeta -type f | head

If anything is listed, move it rather than delete it. Entries under vfsMeta/ are per-file cache metadata and do not necessarily mean an upload is pending, but there is no reason to gamble when a move costs nothing:

mv ~/.cache/rclone/vfs ~/.cache/rclone/vfsMeta ~/.cache/rclone-vfs/
rmdir ~/.cache/rclone

A move between two Btrfs subvolumes is a real copy, so the transferred files inherit the nodatacow attribute of their new home.

Reload and restart — daemon-reload alone does not restart a running service — then confirm the flag is actually in effect:

systemctl --user daemon-reload
systemctl --user cat rclone@dropbox | grep cache-dir
systemctl --user start rclone@dropbox
ls -la ~/.cache/rclone-vfs/

The grep must print the flag, and vfs/ and vfsMeta/ must now appear under the new directory. rclone creates that tree when the mount starts; the files inside it arrive only when you actually read something, since browsing the mount fetches metadata only. To see the cache populate, open a real file:

find ~/Dropbox -maxdepth 2 -type f | head -5
cp "$(find ~/Dropbox -maxdepth 2 -type f | head -1)" /tmp/
du -sh ~/.cache/rclone-vfs/vfs/dropbox/

Because the subvolume is excluded from snapshots, a Snapper rollback of /home leaves the cache untouched — which is the correct behavior for data that is, by definition, reconstructible from Dropbox.

GNOME Files creates a trash folder inside the mount

Worth knowing before you delete anything from ~/Dropbox in Nautilus.

GNOME only uses ~/.local/share/Trash for files that live on the same filesystem as your home. For anything else — external drives, network shares, and FUSE mounts like this one — it creates a .Trash-<uid> directory at the root of that filesystem. Deleting a file from ~/Dropbox in GNOME Files therefore moves it to ~/Dropbox/.Trash-1000/, which rclone dutifully uploads to Dropbox. The deleted files consume your Dropbox quota and reappear on every other machine connected to the account.

Check whether it already exists, and how much it holds:

rclone size dropbox:.Trash-1000/
rclone ls dropbox:.Trash-1000/info/ | wc -l
rclone lsd dropbox:.Trash-1000/files/

The counts often surprise. info/ holds one .trashinfo per top-level deleted item, while files/ holds everything recursively — so a handful of trash entries can hide thousands of objects if one of them was a directory. Inspect before purging:

rclone ls dropbox:.Trash-1000/files/ | sort -rn | head -20
rclone cat dropbox:.Trash-1000/info/<name>.trashinfo

Each .trashinfo gives the original path and the deletion date. Note that Path is percent-encoded. To restore something, move it back on the remote rather than through the mount — that is a server-side move with no transfer:

rclone moveto "dropbox:.Trash-1000/files/<name>" "dropbox:<original/path>/<name>"

Three ways to handle it:

• Empty it and delete permanently from now on. rclone purge dropbox:.Trash-1000 clears it, and Shift+Delete in Nautilus bypasses the trash with a confirmation dialog. Simplest, and matches what most people expect from a cloud folder that already has its own server-side recovery.
• Keep it and purge periodically. You retain a local undo at the cost of quota and cross-machine noise. Dropbox keeps deleted files for 30 days server-side anyway, so the added value is limited.
• Exclude it from the mount with --exclude ".Trash-1000/**". Not recommended: Nautilus still tries to write there and fails in ways that are hard to read.

There is no rclone flag to tell GVFS not to offer a trash on a given mount — the behavior is decided by GNOME based on the filesystem, not by the mounting program.

Harden the configuration further

Step 5 covers the minimum. The three levels below are choices, not requirements.

Encrypt the rclone config

rclone config

s (Set configuration password) → strong passphrase twice → q. The config becomes unreadable without the passphrase.

⚠️ Understand what this does and does not buy you. The systemd service can no longer decrypt automatically, so you must either inject RCLONE_CONFIG_PASS through an EnvironmentFile or start rclone manually. Encrypting rclone.conf provides little additional protection for an automatically started mount if the decryption password is itself stored unattended on the same machine — you have moved the secret, not removed it. On a laptop using full-disk LUKS encryption, strict Unix permissions on rclone.conf are usually the cleaner solution.

LUKS disk encryption

Check that your home is encrypted:

sudo cryptsetup status $(findmnt -no SOURCE /home | sed 's|/dev/mapper/||')

If LUKS is active, your home (and therefore rclone.conf) is encrypted at rest when the laptop is off. Combined with level 1, this is more than enough for personal or consultant use. For a laptop likely to be stolen: add a suspend policy → password required.

Dropbox 2FA

On dropbox.com → Settings → Security → Two-step verification. A TOTP app is recommended (Aegis on Android, 1Password). Prevents an attacker who only has your Dropbox password from authenticating elsewhere. It does not protect OAuth tokens already issued on your machine, but it limits the impact of a leak.

Revocation in case of compromise

If you suspect your rclone.conf file has leaked: on dropbox.com → Settings → Security → Connected apps → revoke the rclone app. The token becomes immediately invalid. Then re-run rclone config to re-authenticate.

Allow other users or processes to access the mount

By default a FUSE mount is visible only to the user who created it. This is exactly what you want for a personal desktop mount, and nothing in this guide requires changing it.

You only need --allow-other if the mount must be readable by processes running under another UID — a system service, a container, a command run through sudo. In that case, and only then:

grep ^user_allow_other /etc/fuse.conf || sudo sed -i 's/^# *user_allow_other/user_allow_other/' /etc/fuse.conf
grep user_allow_other /etc/fuse.conf

Then add --allow-other to the ExecStart line of the service and restart it.

This is not the fix for Flatpak applications. A Flatpak app runs under your own UID; what restricts its view of the filesystem is the Flatpak sandbox and its portals, not FUSE permissions. Enabling user_allow_other will not by itself make a mount visible inside a sandbox — grant the application the appropriate filesystem permission instead.

Start the mount without an interactive login

By default this how-to starts the Dropbox mount when your user session starts. That is the desired behavior on a desktop or laptop.

If the mount must also be available before login — for user-level backup jobs, or when you connect over SSH without a graphical session — enable systemd user lingering:

loginctl enable-linger "$USER"

Verify:

loginctl show-user "$USER" -p Linger

This is not required for normal GNOME desktop usage, and it keeps a systemd --user instance running for your account at all times. Enable it deliberately, not by default.

Inspect VFS activity with the rclone RC API

To see what the VFS layer is doing — cache size, files in flight, uploads queued — rclone can expose a local remote-control endpoint. Add to ExecStart:

--rc \
--rc-addr localhost:5572 \
--rc-no-auth

Then:

rclone rc vfs/stats

Useful to answer “is anything still uploading before I shut down?”. Two caveats before enabling it permanently:

• --rc-no-auth exposes an unauthenticated control API to anything that can reach the socket. Keep the address bound to localhost, or set --rc-user / --rc-pass instead.
• The RC API can do far more than report statistics. Treat it as a debugging tool you enable when needed, not as part of the baseline configuration.

Add other clouds (Google Drive, OneDrive, S3, etc.)

The template mounts any configured remote without editing the .service file:

rclone config
systemctl --user enable --now rclone@gdrive

A remote with no drop-in lands on the template default, ~/Cloud/<remote_name> — so the command above gives you ~/Cloud/gdrive. To place it elsewhere, add the same one-line override used for Dropbox:

mkdir -p ~/.config/systemd/user/rclone@gdrive.service.d

cat > ~/.config/systemd/user/rclone@gdrive.service.d/mountpoint.conf << 'EOF'
[Service]
Environment=RCLONE_MOUNTPOINT=%h/GoogleDrive
EOF

systemctl --user daemon-reload
systemctl --user restart rclone@gdrive

The supported remotes (S3, GCS, Azure Blob, Backblaze B2, Mega, pCloud, ProtonDrive, etc.) follow the same flow.

One caveat when reusing these flags: --poll-interval only has an effect on backends that implement change notification. Dropbox, Google Drive and OneDrive do; plain S3 does not, and there --dir-cache-time becomes the only refresh mechanism — so a five-minute directory cache means remote changes can take five minutes to appear.

Troubleshooting

The service does not start after login

journalctl --user -u rclone@dropbox -n 50

Common causes: no network yet at startup (Restart=always retries after 10 s), corrupted config, mount point still mounted by a previous mount that did not unmount cleanly.

Transport endpoint is not connected

The mount is a zombie after an rclone crash. The service in this guide includes an ExecStartPre=-/usr/bin/fusermount3 -uz that prevents this on the next start. If you hit the error during use:

systemctl --user stop rclone@dropbox
fusermount3 -uz ~/Dropbox
findmnt -T ~/Dropbox
systemctl --user start rclone@dropbox

findmnt should return nothing before the start.

The mount landed on ~/Cloud/dropbox instead of ~/Dropbox

The drop-in was not created, was misnamed, or daemon-reload was not run:

systemctl --user cat rclone@dropbox
systemctl --user show rclone@dropbox -p Environment --value

The second command shows the effective value of RCLONE_MOUNTPOINT. The drop-in must live in ~/.config/systemd/user/rclone@dropbox.service.d/ and end in .conf. After any change:

systemctl --user daemon-reload
systemctl --user restart rclone@dropbox
rmdir ~/Cloud/dropbox ~/Cloud 2>/dev/null

A file is not updating on the Dropbox side after save

tail -50 ~/.local/state/rclone/rclone-dropbox.log

Upload errors will be visible. Causes: expired OAuth token (re-run rclone config to refresh), Dropbox quota full, rclone app revoked on the Dropbox side. Remember that a pending upload is not lost when the mount stops — it resumes at the next start, as long as the VFS cache has not been deleted.

Poor performance when opening files

Raise --vfs-cache-max-size and --vfs-cache-max-age so the working set stays warm (see Sizing the cache). For large files, video in particular, add --vfs-read-ahead 128M and --vfs-read-chunk-size 64M --vfs-read-chunk-size-limit 2G to improve streaming.

Remote changes take too long to appear

Check that --poll-interval is not disabled (0 turns polling off). Lowering --dir-cache-time is the wrong lever — see Change detection above.

Quick reference

sudo dnf install -y rclone fuse3

rclone config

mkdir -p ~/.config/systemd/user

cat > ~/.config/systemd/user/rclone@.service << 'EOF'
[Unit]
Description=rclone FUSE mount for %i
Documentation=https://rclone.org/commands/rclone_mount/

[Service]
Type=notify
Environment=RCLONE_MOUNTPOINT=%h/Cloud/%i

ExecStartPre=-/usr/bin/fusermount3 -uz ${RCLONE_MOUNTPOINT}
ExecStartPre=/usr/bin/mkdir -p ${RCLONE_MOUNTPOINT} %h/.cache/rclone %h/.local/state/rclone

ExecStart=/usr/bin/rclone mount %i: ${RCLONE_MOUNTPOINT} \
    --config=%h/.config/rclone/rclone.conf \
    --vfs-cache-mode full \
    --vfs-cache-max-size 50G \
    --vfs-cache-max-age 7d \
    --vfs-cache-min-free-space 100G \
    --dir-cache-time 5m \
    --poll-interval 1m \
    --umask 0077 \
    --default-time 2026-01-01 \
    --log-file %h/.local/state/rclone/rclone-%i.log \
    --log-level INFO

ExecStop=/usr/bin/fusermount3 -u ${RCLONE_MOUNTPOINT}

Restart=always
RestartSec=10

[Install]
WantedBy=default.target
EOF

mkdir -p ~/.config/systemd/user/rclone@dropbox.service.d

cat > ~/.config/systemd/user/rclone@dropbox.service.d/mountpoint.conf << 'EOF'
[Service]
Environment=RCLONE_MOUNTPOINT=%h/Dropbox
EOF

systemctl --user daemon-reload
systemctl --user enable --now rclone@dropbox

chmod 600 ~/.config/rclone/rclone.conf
systemctl --user status rclone@dropbox --no-pager
findmnt -T ~/Dropbox

Replace dropbox with the remote name for other providers, and adjust the drop-in mount point accordingly.

Changelog

2026-08-14 — revision

• Dropbox now mounts on ~/Dropbox from the start, matching the macOS/Windows path. The generic ~/Cloud/<remote> convention remains the template default for additional remotes.
• systemd template refactored around Environment=RCLONE_MOUNTPOINT; the per-instance mount point is a two-line drop-in instead of a duplicated ExecStart.
• --dir-cache-time raised to 5m and --poll-interval 1m made explicit; added a section explaining that Dropbox supports change notification and that directory-cache lifetime is not the change-detection mechanism.
• Restart=on-failure → Restart=always, with an explicit note that Restart= never applies to an explicit systemctl stop.
• user_allow_other moved out of the main path into an optional section; removed the incorrect claim that it addresses Flatpak sandbox restrictions.
• Cache defaults raised to 50G / 7d and --vfs-cache-min-free-space 100G added; new Sizing the cache section with per-machine guidance and the distinction between the size cap, the age limit and the free-space floor.
• New Btrfs and Snapper section: put the VFS cache on a nested subvolume with CoW disabled so it is excluded from snapshots, including the ownership, permission and SELinux relabelling a sudo-created subvolume needs.
• New section on the .Trash-<uid> directory GNOME Files creates inside the mount, and what it costs in Dropbox quota and cross-machine noise.
• Added a warning against manually deleting the VFS cache, and an explanation that pending uploads resume at the next mount.
• Clarified that the VFS cache is managed around its size/age limits rather than capped hard, and that open or pending-upload files are not eviction candidates.
• Added rclone config file, systemctl --user cat, findmnt -T; replaced mount | grep.
• Added optional sections on systemd user lingering and the rclone RC API.
• Restructured the article: the installation is now six explicitly numbered steps ending with a completion checkpoint, followed by a Reference section and an Optional extras section, so that required work is visually separated from background and side quests.
• Reworded “equivalent to Smart Sync” as “similar to”, replaced the claim that nothing saturates bandwidth in the background, and removed unsupported claims about rclone being the only option or the community consensus.