loc bengaluru, ist | local --:-- srijanshukla18@gmail.com →
Srijan Shukla
[post]/tech/rclone-s3-mount-macos

What Happened When I Tried to Use S3 Like Dropbox on macOS

/ 7 min read· infra

I mounted an S3 bucket as a local folder in Finder with rclone and FUSE-T, auto-mounted on login. This is the full setup, the flags that make it behave, and where it falls over.

back to writing→

I wanted a very specific thing: a local folder on macOS that feels close enough to Dropbox for browsing and the occasional open, but backed by S3 instead of a sync client. Full folder tree visible in Finder. Files fetched on demand. A local cache with a hard size limit. Cheap storage underneath. No heavyweight desktop product in the middle.

The obvious tool is rclone mount. The part the guides skip is that the whole thing only works cleanly if you get three decisions right: the FUSE layer, the rclone binary, and the cache flags.

It works now. Here’s the setup, in the order I did it.

The goal

  • browse an S3 bucket like a normal folder in Finder
  • fetch file contents only when needed
  • keep a bounded local cache
  • no downloading big files up front
  • auto-mount on login
  • cheap enough that the bucket can be cold archive, not hot primary storage

I was not building a collaborative filesystem, and I was not trying to make object storage act like a low-latency network share. I wanted an archive mount that’s pleasant to browse. Everything below follows from that.

Two decisions before any flags

Get these wrong and the mount flags don’t matter at all.

1. Use FUSE-T on macOS

The mount needs FUSE-T as the userspace FUSE driver.

brew install --cask fuse-t

Generic guides talk about FUSE on macOS like the options are interchangeable. They are not.

2. Use the official rclone binary, not Homebrew

This was the bigger gotcha. You want the official binary at /usr/local/bin/rclone. The Homebrew build doesn’t ship the mount support you need on macOS.

curl -L https://downloads.rclone.org/rclone-current-osx-arm64.zip -o /tmp/rclone.zip
cd /tmp && unzip -o rclone.zip
sudo cp /tmp/rclone-v*-osx-arm64/rclone /usr/local/bin/rclone
sudo chmod +x /usr/local/bin/rclone

Then verify the build can actually mount:

/usr/local/bin/rclone version

Look for go/tags: cmount in the output. If it’s missing, rclone will look happily installed while the one feature you installed it for isn’t there.

The remote

Plain S3:

[archive]
type = s3
provider = AWS
access_key_id = <YOUR_ACCESS_KEY_ID>
secret_access_key = <YOUR_SECRET_ACCESS_KEY>
region = ap-south-1
storage_class = GLACIER_IR

The storage class matters more than it looks. This is tuned for Glacier Instant Retrieval:

  • storage is cheap
  • retrieval is not free
  • repeated reads should be absorbed by the local cache
  • object churn should stay low

That’s the economic model the mount flags below are built around.

The mount command

/usr/local/bin/rclone mount archive:your-bucket ~/rclone \
  --vfs-cache-mode full \
  --vfs-cache-max-size 5G \
  --vfs-cache-max-age 72h \
  --vfs-read-chunk-size 16M \
  --vfs-read-chunk-size-limit 256M \
  --dir-cache-time 30m \
  --poll-interval 0 \
  --cache-dir /tmp/rclone-cache \
  --volname "rclone" \
  --daemon

Most guides paste something like this and move on. Don’t. The flags are the setup.

What the flags actually do

--vfs-cache-mode full

The flag that makes the mount feel usable. Opened files get cached locally, and Finder stops choking. Without it, reads and writes are far more constrained.

--vfs-cache-max-size 5G

A hard ceiling on how much local disk the cache can eat. Without it, “cheap remote storage” quietly turns into a surprisingly large local cache.

--vfs-cache-max-age 72h

The retention rule for cached files. Untouched for three days, a file can be evicted. Frequently revisited files stay fast, old files fall back to remote. Right shape for an archive.

--vfs-read-chunk-size 16M and --vfs-read-chunk-size-limit 256M

These two control how aggressively reads expand. The first chunk is modest, and sequential access ramps it upward. You don’t fetch a giant object just because something opened it, but sequential reads still get efficient. For media and large PDFs this shape beats eager full downloads.

--dir-cache-time 30m

The innocent-looking flag that changes the whole character of the mount. It caches directory listings for 30 minutes.

Great for browsing. Awful if you need rapid visibility of remote changes. If another writer touches the bucket, you can spend the next half hour staring at yesterday’s directory tree. A mount with --dir-cache-time 30m is not a transport for low-latency coordination.

I ran into exactly this behavior later in a completely different system, which is why I wrote What Happened When I Tried to Coordinate Two AI Agents Over NFS. Fine for archive browsing. Wrong abstraction for a message bus.

--poll-interval 0

Polling is off. Fine when the bucket is effectively single-writer or slow-changing - it keeps the mount quiet. Not fine if you expect the mount to notice remote changes quickly.

--cache-dir /tmp/rclone-cache

Cache lives in /tmp, so the machine gets a clean slate on reboot. The cache is a performance layer, not durable state.

The Finder part

This setup doesn’t stop at “the shell can see it”. I set:

  • mount point: ~/rclone
  • volume name: rclone
  • a LaunchAgent for auto-mount on login

So it shows up under Locations in Finder, browses like a mounted volume, and comes back after login on its own. A mount you have to remember to babysit isn’t part of your workflow. It’s a chore.

The LaunchAgent

The mount runs as a real login service:

  • exact binary path
  • stable mount flags
  • logs to a known file
  • predictable restart on login

Not glamorous. It’s the difference between a neat shell command and a storage surface you actually rely on.

The cost model

The Glacier Instant Retrieval economics, spelled out:

  • cheap storage
  • paid retrieval
  • cheap list requests
  • paid uploads
  • minimum storage duration
  • minimum object billing size

So this is not where active working directories go. It suits stuff with infrequent access, predictable browsing, and a local cache absorbing the repeated reads. Ignore that and the mount still works. It just won’t be the system you thought you built.

What it’s good at

  • a cheap browseable archive
  • Finder-visible access to deep folder trees
  • on-demand fetch instead of full sync
  • a bounded local cache
  • predictable startup via LaunchAgent

If your actual problem is “I want object storage to feel locally explorable without paying the cost of a full sync client”, this is a good answer.

What it’s bad at

  • rapid visibility of remote changes
  • multi-writer coordination
  • filesystem-like consistency guarantees
  • lots of small-file churn
  • anything that depends on directory listings being fresh right now

None of that is a flaw in rclone. It’s what you signed up for with these flags and this storage class. S3 is object storage. The mount can make it feel local. It can’t erase what it is.

The part the guides skip

Mount flags matter more than most setup guides admit.

Anyone can paste a mount command. What decides whether the thing is still useful in three months is the flag set: cache mode, cache ceiling, how stale your listings are allowed to get, whether polling is on. Mine are tuned for one job: browse fast, fetch lazily, keep the cache bounded, accept stale listings.

Treat it like a cold archive with a decent desktop layer and it works. Treat it like shared mutable infrastructure and you’re just maintaining a folder full of lies.